This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFC] Adding --skip-mismatch option to ld


> 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)
___________________________________________________________________

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]