Hi Peter, * Peter O'Gorman wrote on Mon, Jun 18, 2007 at 05:14:19AM CEST: > > checking for the default library search path... /lib /usr/lib hwcap 0 > nosegneg hwcap 0 nosegneg /usr/lib/mysql /usr/lib/qt-3.3/lib > > Looks like we need to deal with that. For an explanation, see: > http://lkml.org/lkml/2007/4/24/3 ... in the generated libtool, I see > this: [...] > We could "fix" it by ignoring the hwcap lines, or only taking lines that > start with a '/', but that does not seem like a good fix to me. Any > other good ideas?
This has two aspects: First, *what* we should do. Possibilities: 0) Do nothing. Except ugly output and marginally slower execution there is little to lose, as those names are not absolute directories, so do not change semantics compared to when they are not present in sys_lib_dlsearch_path_spec. 1) Ignore those lines in the input file. Nicer as (0), but semantically equivalent. 2) Try to interpret the lines, or whereever else the set of subdirectory suffixes comes from. Consider all those subdirectory suffixes and their allowed combinations as contained in the default loader search path. AIUI a library in, say, /.../lib/tls usually has a counterpart in /.../lib (can somebody confirm this?) so by (1) we wouldn't be compromising portable applications' linking step: they should -L/.../lib and magic at runtime would do the rest, no? If my above reasoning is right, then remains the question *how* to implement (1). I don't see what regression the sed command /^[ ]*hwcap[ ]/d could cause, given that we've ignored /lib/tls and the like until now. I suppose in the long run we could modify the sys_lib_dlsearch_path_spec testing to take all the suffixes into account. For non-cross compiling cases, parsing LD_DEBUG output (as in the message you're referring to) could be an option. Hard-coding `tls' could also be an option, if that's the most troublesome candidate. Cheers, and yes that's all very much IMVHO and I'd love to be corrected by somebody that actually works on distributions, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
