[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix for 'Cygwin List O' Issues' #1: static runtime libs

From: Charles Wilson
Subject: Re: Fix for 'Cygwin List O' Issues' #1: static runtime libs
Date: Fri, 08 Nov 2002 14:48:12 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

Any comments on this patch -- on its specifics or its general approach?


Charles Wilson wrote:

Here's an attempt to address this problem. Right now, (with one exception) it directly affects only cygwin/mingw/ but could be extended in the future.

I've pulled the "determine what extra libs are added by the compiler" code out of the AC_LIBTOOL_LANG_CXX_CONFIG and made it into its own function AC_LIBTOOL_POSTDEP_PREDEP. I've attempted to make that function multi-tag compliant -- but right now it is only called by the CXX_CONFIG. (Hopefully that will change later, but one step at a time).

I've added a new libtool variable (that gets added to each tag in the generated libtool script) "allow_libtool_libs_with_static runtimes" (generated by _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1) ). It's set to "no" for all tags and architectures except cygwin/mingw right now -- which means that the *existing* behavior is unchanged for all but cygwin/mingw.

When allow_libtool_libs_with_static runtimes = yes, then we skip $postdeps, $predeps when checking for "dynamicness".

Eventually, even the "C" tag should call AC_LIBTOOL_POSTDEP_PREDEP, so that the behavior in all tags is the same (e.g. if NOT allow_libtool_libs_with_static_runtimes, then the C tag should check libgcc for "dynamicness" -- existing behavior is to allow static libgcc.a when creating C shared libs, but disallow in C++. ???) But, again, one thing at a time.

Now, this last part of the patch affects all platforms (the "exception" I mentioned earlier). It removes the postdeps, predeps, and compiler_lib_search_path from dependency_libs.

Why should the .la libtool library list something like this:
dependency_libs=' -L/usr/lib -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-9 -lstdc++-2
 -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc'

...when libtool itself will *re-determine* all of these dependencies when it's linking a project that depends on this libtool library? And do we really want to include compiler specific paths like -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-9 in it? (*)

I've done the following tests on a libtool patched as described:
  built on cygwin, ran the testsuite (no regressions), and used
    it to successfully build ImageMagick on cygwin.  (Of course,
    it also successfully builds the demo project attached to the first
    message in this thread.)
  built on linux, ran the testsuite (no regressions), and used
    it to successfully build ImageMagic on linux.

I'd expect that this patch would need some testing on lots of other platforms before inclusion...but it does solve the problem on cygwin, and doesn't break linux.


(*) This can sometimes lead to counterintuitive -- but still pedantically correct -- results. For instance, suppose allow_libtool_libs_with_static_runtimes = no, but the platform's runtime libraries ARE static, and we try to build a shared library (in C++, since only the C++ tag currently checks this).

libtool will complain
*** Warning: linker path does not have real file for library -lstdc++.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

But because the dependencies at fault are stdlibs, they are NOT explicitly added to the "dependency_libs" variable in the libtool library (because the last part of my patch removes such stdlibs from that variable). But that IS correct behavior -- the compiler/libtool WILL automatically add **standard runtime libs** to the link command whenever you link to this libtool library -- there's no reason to list them in the .la file.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]