Re: another 1.5 release?

[Ralf Wildenhues]

* Daniel Reed wrote on Fri, Jan 28, 2005 at 08:08:44PM CET:
> On 2005-01-28T08:08+0100, Ralf Wildenhues wrote:
> ) * Daniel Reed wrote on Thu, Jan 27, 2005 at 10:11:25PM CET:
> ) > As far as I know, the multilib2 patch (based on gcc's -print-file-name) 
> is in
> ) > limbo rather than being rejected; is there any way it can go in for 
> 1.5.12?
> ) It has a couple of issues:
> ) - Platform-dependent stuff should go in libtool.m4, not in ltmain.in.
> )   This is not hard to do, just a bit of work.
> 
> What does this target? Just the checking to see whether gcc -print-file-name
> actually works?

Have a compiler_libsearch_cmd(s) _LT_TAGDECL that is filled with
  $CC -print-file-name
if on gcc and false otherwise.  After checking whether it works.
Invoke $compiler_libsearch_cmd(s) from ltmain.
Maybe choose a better name than this one.

> ) - The patch exposes the need for normalized paths.  I posted a
> 
> I'm not sure why it would. I don't think the paths are used as keys, so
> having non-normalized paths should be fine.

Well, we do ask ourselves whether two paths are the same or not.
So, when -print-file-name outputs
  /usr/lib/../lib64,
and
  /usr/lib64
is in the default compiler search path, then the former would be added
as rpath entry, while the latter would not.  This is a bug, and it will
annoy Debian people without end (it just happens that I know of their
"rpath is forbidden in proper Debian" policy;  this is not the only
incarnation of this problem).

> Additionally, a weird situation where gcc -print-file-name=libstdc++.la
> gives /path/to/gcc/../libstdc++/lib/libstdc++.la:
> 
> address@hidden:~# ls path/to/gcc/../libstdc++/lib/libstdc++.la
> path/to/gcc/../libstdc++/lib/libstdc++.la
> 
> address@hidden:~# ls path/to/libstdc++/lib/libstdc++.la
> ls: path/to/libstdc++/lib/libstdc++.la: No such file or directory
> 
> address@hidden:~# readlink -f path/to/gcc/../libstdc++/lib/libstdc++.la
> .../path/opt/libstdc++/lib/libstdc++.la
> 
> (path/to/gcc is a symlink to path/opt/gcc, and path/to/libstdc++ does not
> exist while path/opt/libtsdc++ does)
> 
> I'm not sure this could happen in practice, but if it is possible, it could
> cause some pretty odd/hard-to-track problem situations.

D*mn, you're right.  This sucks.

I hoped I could write it so that it would also work in case of DESTDIR
installs, where we might not know the directory structure in advance.
Guess I was wrong.

Thank you for pointing this example out to me.

I think this probably means that, for DESTDIR installs, we will have to
relink at `make install' time.  Not only libraries (and them in the
correct order), but also programs (and them after the libs).  See e.g.
the recently reported DESTDIR failure.

But we also cannot do
  `cd $libdir && pwd -L`
, at least not on every system: pwd might not have -L, the system might
not support logical paths even.  OTOH, I know it'd be an administrative
nightmare if libtool put in physical paths (that then might not exist on
the other hosts which NFS-mount our logical $prefix).

We might have to use normalize_paths on those systems.  I think the
trick Daniel showed above should not work there (have to go check..).


> ) - For gcc specifically: Even your modified search algo will not work
> )   with a custom gcc-4 installation.  Why?  If both lib{,64}/libstdc++.la
> )   are installed, libtool will find the first and then bail if you
> 
> address@hidden ~ =) # ls -l /usr/lib/libsnmp.la /usr/lib64/libsnmp.la
> -rw-r--r--  1 root root 702 Dec 27 08:37 /usr/lib64/libsnmp.la
> -rw-r--r--  1 root root 700 Dec 27 08:41 /usr/lib/libsnmp.la
> address@hidden ~ =) # gcc -print-file-name=libsnmp.la
> /usr/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../lib64/libsnmp.la
> address@hidden ~ =) # readlink -f `gcc -print-file-name=libsnmp.la`
> /usr/lib64/libsnmp.la
> address@hidden ~ =) # readlink -f `gcc -m64 -print-file-name=libsnmp.la`
> /usr/lib64/libsnmp.la
> address@hidden ~ =) # readlink -f `gcc -m32 -print-file-name=libsnmp.la`
> /usr/lib/libsnmp.la
> address@hidden ~ =) #

This is a misunderstanding.  Think libstdc++.la in a custom gcc
installation, say, in $HOME/local.

If your patch was applied, the following happens:
Libtool finds it in the search paths that are checked _before_
  gcc -print-file-name
will even be tried for finding it.

For one of -m32/-m64, things will break.

I have such a setup at work, BTW.

> ) Using stuff like pkg-config breaks very nicely if they add both
> )   -L/foo/lib  and -L/foo/lib64
> ) to the command line (because we search that before -print-file-name as
> ) well).  I do not know the extent of such possible breakage.
> 
> We already lose in that situation:
> 
> address@hidden ~ =) # gcc -shared -o test -lsnmp
> address@hidden ~ =) # gcc -shared -o test -L/usr/lib -lsnmp
> /usr/bin/ld: skipping incompatible /usr/lib/libsnmp.a when searching for 
> -lsnmp
> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
> address@hidden ~ =) #

So now we know why FC ships only one ABI version of these -devel packages :)
No, to be serious:  What can we do to solve this?

Thank you for your response.  Please keep bugging us, we really need to
solve this mess.

Regards,
Ralf