From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zmcc-3-mx.zmailcloud.com (zmcc-3-mx.zmailcloud.com [34.200.143.36]) by sourceware.org (Postfix) with ESMTPS id DDC6B3858D34 for ; Wed, 21 Feb 2024 20:55:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DDC6B3858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=symas.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=symas.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DDC6B3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=34.200.143.36 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708548961; cv=none; b=kQPzIjP/qMaL/+7csfYKjjyawcn699W34TJ75v7gqGSRiz+18FQAM0nb9yOhGj3Ksymf902smjHlY4iTeRPAw+b7c/LQr6SKDNuHUCFSmEUwoyChCNvjx7rOSRNcWEFM1/5wCL/WOxjAILzSUcazK9lNTrajG8yp0TKgDs+fSsg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708548961; c=relaxed/simple; bh=+UZ7UNMKaFtWlx7qVyQbMHihuove8luUPCvwaRJOXTY=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=UoRvUQgX2PclLCyYbkBN6azonzz8bIZyzo6gcSDAapLMr5N9+I31H9LE+hjwCilFFVhl7zRYcRrttKrNmMj56c5HmZgLKPkNHzzi7AoAoWNCqJ/Qw6kXOwEjyH3NnxWuRKoR+L32z1AdK0ArR7b0Mi2/gkVqqyAPQl+3tK9pv+A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from zmcc-3.zmailcloud.com (ec2-3-15-255-223.us-east-2.compute.amazonaws.com [3.15.255.223]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by zmcc-3-mx.zmailcloud.com (Postfix) with ESMTPS id 5701EE5C73; Wed, 21 Feb 2024 14:55:58 -0600 (CST) Received: from zmcc-3.zmailcloud.com (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTPS id 3EB2C3BCA0; Wed, 21 Feb 2024 14:55:58 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 301EA3BCA1; Wed, 21 Feb 2024 14:55:58 -0600 (CST) Received: from zmcc-3.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-3-mta-1.zmailcloud.com [127.0.0.1]) (amavis, port 10026) with ESMTP id xP2puTDlY-b6; Wed, 21 Feb 2024 14:55:58 -0600 (CST) Received: from [192.168.1.107] (ip-84-203-31-221.broadband.digiweb.ie [84.203.31.221]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTPSA id BF6803BCA0; Wed, 21 Feb 2024 14:55:57 -0600 (CST) Subject: Re: ld: document static libraries when performing static linking To: Christian Tramnitz , binutils@sourceware.org References: From: Howard Chu Openpgp: preference=signencrypt Autocrypt: addr=hyc@symas.com; prefer-encrypt=mutual; keydata= mQGiBERuNuERBACY9KGBcxSvy6D9Sxk51L59/7ACWQf/Mk2B5jWCxcadEZHokKf4mYBBH963 B1v04S8QKsm1avt4amS3dEEfxJ920RWtg5XkVCW0HfErsZ58XobIcPLDpd7u3btGHObQfJ5f zyRuIaWpBg59gGJAw13Rz/ILuDpXHBP0ppI9OOq6nwCgnG+IB56YTz9oGLiVXFsa8LItTI0D /jBTd5UWQ+BYCU8HdHq+fRm6l/N921yrFO4hF1jU4Mi6t9srHkQVW5ro9cxVhAWKCbVum5og ylcfH1WK//R2HkSdKJXNVxZdBieGD/tLYYSJj3qU7UA9ZTH5QGUkNqcHH7bV+o+5oZdhIhpc MuG1TFudGkQcnTWW0X69S6bRuBa1A/9Zg6Hk2uL0ytbHtASWKZHr80f1hhe6catT314nqJNU 5rufYHHHCvQJVDPsNWkj4OfkBE5xG1VxMPulvMTJIKm1FdXK+1B9OfcXUk/+zyCiYLGbrAju UlHDmVDHP1YQEn+a8S8QowXl+tAL62lO3mDCiPny6ohuIJiTfLLPrE1+bLQaSG93YXJkIENo dSA8aHljQHN5bWFzLmNvbT6IXgQTEQIAHgIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAUCVpAQ GAAKCRD9KnC0SrEbp+3XAJwNjg2sFjNTwzf5LaTT/wl2sWwqbgCgiX9jv1OS+pzJHH4OpjTt 5+lHuUO5Ag0EVpAQNBAIAJkPNT4l6iZpOO+eOvcyi1ssY67xv7rT08xOI4GoeyG9yOfdSenB pqaDlnjPW3Wi3NgxsVqqY3GXf+nRaOAsiBSzD17ILyR9IsIeYFLf2AVB5M95FaTflKqBPuXf ui1aCUK4qP5RwFKRQbaZ68dgXqJVkZhuprk0MDpMjV1GxYEiMKSrjda6ntlOCrrxRAU19UAg sxiDhGLW5rQXRrYPxS8Lf/qSBUB2OLUHv28pF/ly2MiwgoaKuSpKvimb9BG2n4N75vsVDMG3 qkMFDRSz4yBaR3niop0JPATzbxY3/jJmf8v7W7AP9eelnzJXR7Fzlf5w+iVpNhz7/PwS+xc+ G78AAwUH/jPuhgyFlKWRX4se3gwWYbcjW3oUOrKkhrvey5YymV29EsTjOY05AILrlZozjPG4 uHFbPSybdZxQ/j5jUS7o7uLXWuMZOtX77nqr9U9HOfXxWpOUk3o866VoQ3hCWZiTMBMEr+Ht DkxbCpZliUr36Dmrz4W8Pk7oYM2tVhS43naqPkUJwkJlzDZXG5Q+qLYElV9bmnWQVjg5h1/5 wZoMg80iC2bMt5iZLKQCMf2x/eaEzGhkAJFR/vliyxlJo6+rW7q7t3vPpglL6RKbWmgXCKvJ op6Fb35CGSlICEin+GIs3tT6BLgkG5xE3H3pGcmPeJv0cJnbswcDF8zIpDzskcGITwQYEQIA DwUCVpAQNAIbDAUJEswDAAAKCRD9KnC0SrEbp6klAJ0XpzVjkb800UctKphecVRZQyFBqQCe KVGYJBO2Eco0s3YcXGkQTowEGhk= Message-ID: Date: Wed, 21 Feb 2024 20:55:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_RED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Christian Tramnitz wrote: > Hello, Hi - a linker plugin to handle static library dependencies already exists, it's been around nearly 4 years. https://sourceware.org/pipermail/binutils/2020-September/113188.html There was a bit of a push to make it an integral feature of ld instead of a plugin, but that has stalled. https://sourceware.org/pipermail/binutils/2023-February/126155.html I guess it's worth asking again, what help is needed to move integration forward? > > For statically linked binaries one wants to keep track of external > libraries that were pulled in at link time. I haven't found any > initiatives or standards trying to achieve this yet, so I would like > to make a proposal. > > ld already supports the `--depedency-file=` option to create a > depfile, to some degree, documenting dependencies in Makefile format. > While it's a good starting point, it's not sufficient. > > Would it be feasible to create another option, that > a) just records dependencies to external, static-libs (within the > depfile this could be achieved by looking for path names outside the > build dir and having an .a file extension - but this is not > neccessarily exhaustive). This doesn't need to be unique, > post-processing is expected to take place anyway. > b) documents the actual objects (enhanced: down to function level if > information exists from compiling with -ffunction-sections and > -fdata-sections) that were pulled in from the library archive, similar > to the output from `--verbose` > "(/usr/lib/gcc/x86_64-pc-linux > -gnu/13/../../../../lib64/libc.a)stpcpy-avx2.o" > c) outputs this in some sort of structured format for later > processing, e.g. as simple as > ,, > my-obj,/usr/lib64/libc.a,stpcpy-avx2.o > my-obj,/usr/lib64/libc.a,stpcpy-avx2-rtm.o > my-obj,/usr/lib64/libc.a,getsrvbynm.o > my-obj,/usr/lib64/libc.a,stpcpy-evex.o > d) - if ld doesn't support this already (couldn't find looking through > man) - ld had some sort of no-op/pretend option that doesn't actually > produce a linked output but only pretends it would? > > > Purpose: > The consumer of this information might be a distributor, keeping track > of things in the distribution specific packaging database format. Or > it could even be embedded into the resulting binary itself. > > > Background: > This output can be used to > I) validate license compliance (it would make it possible to discover > conflicting licenses of derived work) > II) allow vulnerability tracking, when vulnerabilities existed in > included static libraries (at build/link time) > > The latter would be further supported by b) as a vulnerability may not > even exist in the resulting object if the vulnerable function wasn't > included by linking. > > > > Best regards, > Christian > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/