Re: GCC4, new package soon?

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Dave Korn wrote:
>   That is soooooo wrong.  Nobody has any business sticking their nose into the
> compiler's private directory.  Gah!

That's not exactly what's happening.

>   If it really /has/ to know, it ought to be doing dependency_lib=`g++-4
> --print-file-name=libstdc++.la` or something like that.  Really it should
> leave well alone things that are part of the operating environment.  When it
> comes to language runtime, all it should want to know is whether or not and
> where to add "-lc" or "-lstdc++" or whatever.  Oh well, one more item on the
> to-do list.

libtool drives the link process manually (I know, I know. But it does.)
So, during configure, it figures out what deplibs the compiler adds when
linking, in $LANG mode, and stores all that information.  Then, when
`libtool --mode=link --tag=$LANG ...`, it retrieves that information and
uses it to call ld directly.

This is the issue that leads to the "static vs. dynamic" $LANG runtime
problem we discussed earlier.

But that's not what Yaakov is talking about (well, not entirely).  When
you link ANY library with libtool, and that library itself depends on
other libraries, those other libraries get recorded in the new library's
.la file as dependency_libs.  I'm not entirely sure why or what triggers
this, but *SOMETIMES* the path to the library (whether .a, .dll.a, or
.la) gets fully resolved to an absolute path, rather than being left as
"-lfoo". Other times, -L/path/to gets stuck into dependency_libs, as well.

Add that behavior to the fact that the runtime libs (a) have .la files
(b) and ARE in fact deplibs for every library compiled in $LANG, and you
have: a bunch of .la files whose dependency_libs='...' contains the full
path to the compiler's .la file.

There are a ton of things wrong with this behavior, but it is what it is
-- and somehow we need to work around it, until libtool is "fixed".
Whatever "fixed" means.

FYI, here's a *really* bad example:

/usr/lib/lib-org-w3c-dom.la:dependency_libs='
-L/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/.build/i686-pc-cygwin/libjava/.libs
/usr/lib/libgcj.la
-L/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/.build/i686-pc-cygwin/libstdc++-v3/src
-L/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/.build/i686-pc-cygwin/libstdc++-v3/src/.libs
-L/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/.build/i686-pc-cygwin/libjava
-ldl -lz
-L/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/.build/gcc
-L/usr/i686-pc-cygwin/bin -L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lgcc -lcygwin -luser32
-lkernel32 -ladvapi32 -lshell32 -lgcc'

Oops.

>> However unlike Gentoo, as a binary distro we need to handle the case
>> where a package built for 4.3.2 isn't rebuilt for a while and is
>> installed *after* a newer GCC.  Perhaps this should be a separate script
>> shipped with gcc4 in /usr/sbin which can be called by both gcc4
>> postinstalls and by the user as necessary?
> 
>   Yeah, I reckon so.  Thanks for the heads-up.

That's probably the best solution -- until libtool gets its act together.

--
Chuck