Re: another 1.5 release?

[Daniel Reed]

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?




) - 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.


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.




) - 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 ~ =) #




) 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 ~ =) #

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
It is so easy to miss pretty trivial solutions to problems deemed
complicated. The goal of a scientist is to find an interesting problem,
and live off it for a while. The goal of an engineer is to evade
interesting problems :) -- Vadim Antonov <address@hidden> on NANOG