public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
To: Richard Henderson <rth@cygnus.com>
Cc: 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: <19990608001452.O949@mff.cuni.cz> (raw)
In-Reply-To: <19990607120530.A13793@cygnus.com>

On Mon, Jun 07, 1999 at 12:05:30PM -0700, Richard Henderson wrote:
> On Fri, Jun 04, 1999 at 05:12:07PM +0200, Jakub Jelinek wrote:
> > Now Solaris linker apparently skips a library in the search path if it is
> > for the wrong architecture (=emulation) which makes a lot of sense to me,
> > that's why I wrote the second part of this patch. I've made it optional and
> > not default because it differs from the standard library path searching, on
> > the other side without this any compilation with some wrong arch library in
> > the search path before the correct arch one would die in error.
> 
> I don't see any need to make this optional.  My preferred solution
> would be to skip the library with a note written to the map file
> to aid diagnosing user's problems.

In such a case, what would it do if --no-warn-mismatch is specified?
Should it stop skipping the libraries and choose the first one in the search
path, or should it continue skipping incompatible libraries, in which case
if the user wanted to link against an incompatible library, he'd have to
specify its full name including path?
I don't know much about what are people using --no-warn-mismatch for and
what tasks are they solving by it, so I cannot come to conclusion about the
above question easily myself.
I'd be very happy if this skipping on mismatch was the default mode of
operation, just thought it would have lower chance of getting accepted.

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

  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
1999-07-01  0:00                 ` Richard Henderson
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 ` 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=19990608001452.O949@mff.cuni.cz \
    --to=jj@sunsite.ms.mff.cuni.cz \
    --cc=binutils@sourceware.cygnus.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).