Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <3BFBE824.6000007@ece.gatech.edu> Date: Wed, 21 Nov 2001 12:45:08 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin-apps AT cygwin DOT com Subject: Re: ld ---export--all --exclude-libs,? References: <20011121084158 DOT 22945 DOT qmail AT web14501 DOT mail DOT yahoo DOT com> <20011121110829 DOT B24327 AT cygbert DOT vinschen DOT de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Corinna Vinschen wrote: > On Wed, Nov 21, 2001 at 07:41:58PM +1100, Danny Smith wrote: > >>Hello, I'm after some criticism, before submitting this to binutils. >> >>IMO, the auto-export feature of ld needs (at least) an option to exclude >>whole libs from export. The following patch does that. It also adds a few >>more default lib excludes and scans for backward compat implib symbols >>(__imp_) >> >>I think this patch doesn't do enough. >> >>My preference would be to exclude *all* libs by default, with a command >>line option to explicity *include* named libs. Why? It is too easy for >>licensed library code to sneak into dll's using --export-all. This affects >>distributability (sic) of the dll and apps dependent on the dll. >>The user may be unaware of this infection because its automatic. >>At least make the user think about what she/he is exporting. >> >>I will gladly throw away the following to work on a patch to exclude all >>libs by default if given encouragement. >> >>Any comments. >> > > Yes, a question. First note that I'm a binutils (l)user, not a > developer so I apologize for being thick. Now the question: > > Isn't the functionality you're searching for already in ld given by > the --no-whole-archive options? > > gcc -shared -o cygfoo.dll $(OBJ) > -Wl,--out-implib,libfoo.dll.a > -Wl,--no-whole-archive -lbar -lbaz > > Or am I missing the point? the problem is, --no-whole-archive applies to EVERY library, even convenience libraries. For instance, a common autotools idiom is to create various convenience libraries libsubunit1.a and libsubunit2.a. These archives are intended to be included in the eventual .so (.dll) and the internal symbols of libsubunit*.a are INTENDED to be exported from that .so. --no-whole-archive makes this idiom impossible; it is not granular enough. Ralf's solution removes the whole purpose of the idiom -- what's the use of a "convenience" library if you use --no-whole-archive and must then explicitly export every .o contained within the "convenience" library? You're better off not creating the "convenience" library at all, and just explicitly adding the various .o files to your link command line. I don't really care whether "export symbols from static libraries" defaults to yes or no -- but whatever choice is made, there must be a way to override it on a library-by-library basis. So, Danny's patch in its current form is fine. The inverse form (where .a's are excluded by default, and you can explicitly add specific static libraries whose symbols ARE exported) is also good. --Chuck