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 [thread overview]
Message-ID: <19990609225246.2849.qmail@daffy.airs.com> (raw)
In-Reply-To: <19990609205538.B949@mff.cuni.cz>
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
next prev parent reply other threads:[~1999-07-01 0:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-07-01 0:00 Jakub Jelinek
1999-07-01 0:00 ` Richard Henderson
1999-07-01 0:00 ` Ian Lance Taylor
1999-07-01 0:00 ` Richard Henderson
1999-07-01 0:00 ` Ian Lance Taylor
1999-07-01 0:00 ` Jakub Jelinek
1999-07-01 0:00 ` Ian Lance Taylor
1999-07-01 0:00 ` Jakub Jelinek
1999-07-01 0:00 ` Ian Lance Taylor [this message]
1999-07-01 0:00 ` Richard Henderson
1999-07-01 0:00 ` Ian Lance Taylor
1999-07-01 0:00 ` Jakub Jelinek
1999-07-01 0:00 ` Richard Henderson
1999-07-01 0:00 ` Ian Lance Taylor
1999-07-01 0:00 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990609225246.2849.qmail@daffy.airs.com \
--to=ian@airs.com \
--cc=binutils@sourceware.cygnus.com \
--cc=jj@sunsite.ms.mff.cuni.cz \
--cc=rth@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).