From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
To: Ian Lance Taylor <ian@airs.com>
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: <19990609205538.B949@mff.cuni.cz> (raw)
In-Reply-To: <19990609151538.2567.qmail@daffy.airs.com>
> 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).
Also, even porting all packages to 64bit will be awful lot of work, so if
the linker could help with it for free, it would be very good (this is not
only SPARC problem, IA64 vs. IA32 will have to go through similar problems
as I expect it will provide all libraries in both native ABIs).
> 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?
I came with this patch because I saw this behaviour in the Solaris linker
and it makes sense to me. If anyone wants to link a elf32_sparc object with
elf64_sparc object, he will not succeed no matter whether --no-warn-mismatch
was specified or not.
>
> 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.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.3.4 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
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 ` Jakub Jelinek
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 ` 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 [this message]
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 ` 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=19990609205538.B949@mff.cuni.cz \
--to=jj@sunsite.ms.mff.cuni.cz \
--cc=binutils@sourceware.cygnus.com \
--cc=ian@airs.com \
--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).