From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: jj@sunsite.ms.mff.cuni.cz Cc: rth@cygnus.com, binutils@sourceware.cygnus.com Subject: Re: [RFC] Adding --skip-mismatch option to ld Date: Thu, 01 Jul 1999 00:00:00 -0000 Message-id: <19990609151538.2567.qmail@daffy.airs.com> References: <19990604171207.W949@mff.cuni.cz> <19990607120530.A13793@cygnus.com> <19990608213144.561.qmail@daffy.airs.com> <19990608204932.E7246@cygnus.com> <19990609041411.1632.qmail@daffy.airs.com> <19990609163754.V949@mff.cuni.cz> <19990609163754.V949@mff.cuni.cz> X-SW-Source: 1999-q2/msg00196.html Date: Wed, 9 Jun 1999 16:37:54 +0200 From: Jakub Jelinek on sparc64, say the distribution will give the users the choice to install all libraries in both ABIs, so the installer will nicely polulate both */lib and */lib64 trees. But then a user will compile his own package in 64bit and install it, its library will go say into /usr/lib. Why would a user install a library in /usr/lib? I think of that as a system destination. It shouldn't be used for user-installed packages. Say he compiles yet another package (again 64bit) whose configure will look for that library, find it in /usr/lib and add /usr/lib to the list to be passed as -L into LDFLAGS. Why would a configure script add a -L option for /usr/lib? /usr/lib is on the default search path anyhow. If a configure script can find a library using a -l option, it shouldn't add a -L option. And now you have problem, because the -L/usr/lib will come before the system libraries which include /usr/lib64, so the link will not succeed. Yes, it can be solved e.g. by adding -L/usr/lib64 before -L/usr/lib, but I suppose many people will be horribly confused by that. I agree that this scenario is possible. But I think the user made a mistake and I think the configure script make a mistake. How much should the linker try to compensate for mistakes in other packages? On the other hand, do you see the potential confusion if --skip-mismatch becomes the default? The user will accidentally update libfoo.a in some directory with the wrong version. The user will link against -lfoo. The linker will report that there is no such library, or much worse will find an older version of -lfoo which matches. The user will pull his or her hair out trying to get the linker to see the newly updated library. This is also due to a mistake. Isn't it just as bad as the one you describe? Ian