From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@airs.com>
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: <19990609225246.2849.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> <19990609151538.2567.qmail@daffy.airs.com> <19990609205538.B949@mff.cuni.cz> <19990609205538.B949@mff.cuni.cz>
X-SW-Source: 1999-q2/msg00200.html

   Date: Wed, 9 Jun 1999 20:55:38 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

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

   I don't think we need to ask why, it is a matter of fact that many users do
   that and many configure scripts do that (I've seen /usr/lib many times as -L
   argument while I was porting RedHat 5.0 distribution to SPARC).

That's rather discouraging.  Why is this happening?  What packages are
doing it?  Proper use of autoconf should not cause this to happen; are
people using autoconf improperly?

   > 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?

   If --no-warn-mismatch is not specified, then this will not bring any
   confusion, because 
   a) if the library put somewhere in the search path was for the correct
   architecture, it will make no difference
   b) if it is for some other incompatible architecture, then the link would
   fail anyway, unless it just printed warning and tried to link it anyway.
   In such a case, --skip-mismatch could be replaced by --error-mismatch, which
   would cause fatal error instead of warning and have the --skip-mismatch
   behaviour for incompatible libraries in the search path.

I don't think you understand what I am driving at.  I'm a user.  I
write libfoo.a.  I put it in some directory.  I link against it using
-lfoo.  Unfortunately, I made a mistake, and it's the wrong
architecture.

If --skip-mismatch is not the default, I get a meaningful error
message, and I correct my mistake.

If --skip-mismatch is the default, the linker finds an entirely
different libfoo.a later in the search path.  The link succeeds, but
I'm using the wrong code.  My changes aren't in there, and I can't
figure out why.  I have a serious debugging problem ahead of me.

Ian