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.
--Chuck
(*) 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.