[ please forgive the webmailer messing up the lines ]

Peter O'Gorman writes:

I'm not really too knowledgable of the problem space. What are the problems with multilib? Is it just that libtool searches the wrong libdirs?

That's one of them.
Libtool aims out to do the same thing the linker does.
However, GNU ld skips over 32bit libraries (without erroring out)
when searching or a 64bit one. (This is just one example.)


/usr/lib64 should come before /usr/lib? If that is the case, then surely it can be fixed fairly simply by changing our reliance on 'gcc -print-search-dirs' to something else (as gcc -print-search-dirs currently tells lies in the multilib case).

Yes, to a certain extent.


For example, I have the following script (no code comments please, this is just messing about):
*snip*
realdir="`cd $realdir && pwd`"
*snip*

And when I run it (on a sourceforge FC3 compile farm host):
$ sh ./testscript.sh
/usr/lib/gcc/x86_64-redhat-linux/3.4.2 /usr/lib64
$ env CC='gcc -m32' sh ./testscript.sh
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/32 /usr/lib/gcc/x86_64-redhat-linux/3.4.2 /usr/lib /lib

Now try to do the same thing with intended DESTDIR.
(This might in fact work.)


But now try to do the same thing with /opt/lib in gcc's search path
and /opt being a symlink to a path which is not constant on all hosts
on which the NFS volume is mounted.
(This might work if you use `pwd -L'. That is not portable, however.
We might say that we do not care about preserving logical paths with
such systems.)


Couldn't we simply replace occurences of 'gcc -print-search-dirs' with some code like the above in libtool.m4 to get a more reasonable value for sys_lib_search_path_spec. As I said, I have not got a true understanding of the problem. So please help me to understand it more :)

Well, maybe we really should not try to solve the several problems at once.
I don't know. But I have a kind of bad feeling committing to new solutions
which do not work well with cross-compiling, for example.


Cheers,
Ralf (doing only sparse email reading ATM)


_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool

Reply via email to