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

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

[Jakub Jelinek]

Hi!

I'm trying to get elf32_sparc and elf64_sparc environments running on the
same machine on Linux, but Solaris has apparently the same issues but
different paths.
Basically, elf64_sparc is incompatible architecture with elf32_sparc and I'd
like to make things easier for people to link the right thing and not to
crash on incompatible architectures for every link.
The first hunk just sets the default search dirs for the elf64_sparc
emulations, both when it is the default target and when the default is
elf32_sparc. Solaris linker first tries paths ending with /lib/sparcv9
and for Linux I'd like to use paths ending with /lib64.
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.

1999-06-04  Jakub Jelinek  <jj@ultra.linux.cz>

	* emulparams/elf64_sparc.sh: Set up default
	LIB_PATH for elf64_sparc on linux and solaris.

	* lexsup.c: Added new option --skip-mismatch.
	* ld.h: Declare variable for it.
	* ldmain.c (main): Initialize it.
	* ldfile.c (ldfile_open_file_search): Use it.
	* ld.texinfo: Document it.

--- ./emulparams/elf64_sparc.sh.jj	Thu Apr 22 10:15:45 1999
+++ ./emulparams/elf64_sparc.sh	Fri Jun  4 15:54:28 1999
@@ -10,3 +10,31 @@ MACHINE=
 DATA_PLT=
 GENERATE_SHLIB_SCRIPT=yes
 NOP=0x01000000
+if [ "x${host}" = "x${target}" ] ; then
+  # Native
+  case "$target" in
+    sparc*-linux*)
+      SPARC_ELF64_SUFFIX=64 ;;
+    sparc*-solaris*)
+      SPARC_ELF64_SUFFIX=/sparcv9 ;;
+  esac
+fi
+if [ -n "${SPARC_ELF64_SUFFIX}" ]; then
+  LIB_PATH=/lib${SPARC_ELF64_SUFFIX}:/lib:/usr/lib${SPARC_ELF64_SUFFIX}:/usr/lib
+  if [ "x${DEFAULT_EMULATION}" = "x${EMULATION_NAME}" ] ; then
+    if [ -n "${NATIVE_LIB_DIRS}" ]; then
+      LIB_PATH=${LIB_PATH}:`echo ${NATIVE_LIB_DIRS} | sed 's_/lib\(\|/\)$_/lib'${SPARC_ELF64_SUFFIX}_`
+    fi
+    if [ "${libdir}" != /usr/lib -a "${libdir}" != /usr/lib${SPARC_ELF64_SUFFIX} ]; then
+      LIB_PATH=${LIB_PATH}:`echo ${libdir} | sed 's_/lib\(\|/\)$_/lib'${SPARC_ELF64_SUFFIX}_`
+    fi
+    if [ "${libdir}" != /usr/local/lib -a "${libdir}" != /usr/local/lib${SPARC_ELF64_SUFFIX} ]; then
+      LIB_PATH=${LIB_PATH}:/usr/local/lib${SPARC_ELF64_SUFFIX}:/usr/local/lib
+    fi
+  else
+    LIB_PATH=${LIB_PATH}:/usr/local/lib${SPARC_ELF64_SUFFIX}:/usr/local/lib
+  fi
+  if [ "x${DEFAULT_EMULATION}" = "xelf32_sparc" ]; then
+    COMPILE_IN=true
+  fi
+fi
--- ./lexsup.c.jj	Thu Apr 22 10:15:35 1999
+++ ./lexsup.c	Fri Jun  4 15:15:53 1999
@@ -120,6 +120,7 @@ int parsing_defsym = 0;
 #define OPTION_NO_CHECK_SECTIONS	(OPTION_CHECK_SECTIONS + 1)
 #define OPTION_MPC860C0                 (OPTION_NO_CHECK_SECTIONS + 1)
 #define OPTION_NO_UNDEFINED		(OPTION_MPC860C0 + 1)
+#define OPTION_SKIP_MISMATCH		(OPTION_NO_UNDEFINED + 1)
 
 /* The long options.  This structure is used for both the option
    parsing and the help text.  */
@@ -313,6 +314,8 @@ static const struct ld_option ld_options
       '\0', NULL, N_("Create a shared library"), ONE_DASH },
   { {"Bshareable", no_argument, NULL, OPTION_SHARED }, /* FreeBSD.  */
       '\0', NULL, NULL, ONE_DASH },
+  { {"skip-mismatch", no_argument, NULL, OPTION_SKIP_MISMATCH},
+      '\0', NULL, N_("Keep searching if mismatched input file is found in the path"), TWO_DASHES},
   { {"sort-common", no_argument, NULL, OPTION_SORT_COMMON},
       '\0', NULL, N_("Sort common symbols by size"), TWO_DASHES },
   { {"sort_common", no_argument, NULL, OPTION_SORT_COMMON},
@@ -799,6 +802,9 @@ parse_args (argc, argv)
 	    link_info.shared = true;
 	  else
 	    einfo (_("%P%F: -shared not supported\n"));
+	  break;
+	case OPTION_SKIP_MISMATCH:
+	  command_line.skip_mismatch = true;
 	  break;
 	case 'h':		/* Used on Solaris.  */
 	case OPTION_SONAME:
--- ./ldmain.c.jj	Thu Apr 22 10:15:33 1999
+++ ./ldmain.c	Fri Jun  4 15:14:36 1999
@@ -203,6 +203,7 @@ main (argc, argv)
   command_line.interpreter = NULL;
   command_line.rpath = NULL;
   command_line.warn_mismatch = true;
+  command_line.skip_mismatch = false;
   command_line.check_section_addresses = true;
 
   /* We initialize DEMANGLING based on the environment variable
--- ./ld.h.jj	Thu Apr 22 10:15:30 1999
+++ ./ld.h	Fri Jun  4 15:12:55 1999
@@ -128,6 +128,10 @@ typedef struct
   /* If true (which is the default), warn about mismatched input
      files.  */
   boolean warn_mismatch;
+  
+  /* If true, keep searching if a library mismatching output is
+     found in the search path.  */
+  boolean skip_mismatch;
 
   /* Remove unreferenced sections?  */
   boolean gc_sections;
--- ./ldfile.c.jj	Thu Apr 22 10:15:32 1999
+++ ./ldfile.c	Fri Jun  4 16:50:53 1999
@@ -177,8 +177,41 @@ ldfile_open_file_search (arch, entry, li
 
       if (ldfile_try_open_bfd (string, entry))
 	{
-	  entry->filename = string;
-	  return true;
+	  bfd * arfile = NULL;
+
+	  if (! command_line.skip_mismatch)
+	    {
+	      entry->filename = string;
+	      return true;
+	    }
+	    
+	  if (bfd_check_format (entry->the_bfd, bfd_archive))
+	    {
+	      /* We treat an archive as compatible if it empty
+	         or has at least one compatible object.  */
+	      arfile = bfd_openr_next_archived_file (entry->the_bfd, NULL);
+
+	      if (!arfile)
+		arfile = output_bfd;
+	      else
+		while (arfile
+		       && !(bfd_check_format (arfile, bfd_object)
+			    && bfd_arch_get_compatible (arfile, output_bfd)))
+	          arfile = bfd_openr_next_archived_file (entry->the_bfd, arfile);
+	    }
+	  else if (bfd_arch_get_compatible (entry->the_bfd, output_bfd))
+	    arfile = output_bfd;
+	    
+	  if (arfile)
+	    {
+	      entry->filename = string;
+	      return true;
+	    }
+
+	  info_msg (_("skipping %s because it has incompatible architecture\n"), string);
+	  bfd_close(entry->the_bfd);
+	  entry->the_bfd = NULL;
+	                                              
 	}
 
       free (string);
--- ./ld.texinfo.jj	Thu Apr 22 10:15:31 1999
+++ ./ld.texinfo	Fri Jun  4 16:24:12 1999
@@ -1053,6 +1053,16 @@ and SunOS platforms.  On SunOS, the link
 shared library if the @code{-e} option is not used and there are
 undefined symbols in the link.
 
+@kindex --skip-mismatch
+@item --skip-mismatch
+If a library with incompatible architecture is found in the search path,
+just skip it as it was not there and keep searching with the next search
+path element.  Normally, the first library found in the search path is
+chosen, and if the architecture is incompatible, it will either not link
+or might give unexpected results.  An @code{ar} library is considered
+incompatible if it is not empty and contains no object with architecture
+compatible to the output architecture.
+
 @item --sort-common
 @kindex --sort-common
 This option tells @code{ld} to sort the common symbols by size when it


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.2.9 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

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

[Ian Lance Taylor]

   Date: Tue, 8 Jun 1999 20:49:32 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Tue, Jun 08, 1999 at 05:31:44PM -0400, Ian Lance Taylor wrote:
   > 2) I don't understand why it's needed.  Changing the default search
   >    path, as is done by the first half of the patch, sounds like the
   >    right approach to me.  Irix faces these exact issues with its
   >    multiple ABIs, yet it does not need this option.

   That works for system directories, but not /usr/local/lib and other
   such places under user control.  One could argue that we simply need
   to teach old users new tricks.

I don't see how it works for /usr/local/lib anyhow.  If you expect to
find the library in /usr/local/lib, but the wrong library is there,
then as far as I can see you won't find the library at all.  If you
need to find it in some other directory, you will need to add a -L
option, and if you do that it will work anyhow.

Perhaps we can make gcc's multilib feature handle this somehow?

   > I don't think the option name --skip-mismatch is quite right.  That
   > seems too general for this.  How about something like
   > --skip-incompatible-archives?

   We already have --[no-]warn-mismatch that's tangentially related.
   That's presumably where Jakub got the name.

That makes sense.  I was thinking that --skip-mismatch was just for
archives, but technically it is for any file for which the linker
searches, so I suppose it is reasonable.

Ian

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

[Ian Lance Taylor]

   Date: Wed, 9 Jun 1999 16:37:54 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   on sparc64, say the distribution will give the users the choice to install
   all libraries in both ABIs, so the installer will nicely polulate both */lib
   and */lib64 trees. But then a user will compile his own package in 64bit and
   install it, its library will go say into /usr/lib.

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.

   Say he compiles yet
   another package (again 64bit) whose configure will look for that library,
   find it in /usr/lib and add /usr/lib to the list to be passed as -L into
   LDFLAGS.

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.

   And now you have problem, because the -L/usr/lib will come before
   the system libraries which include /usr/lib64, so the link will not succeed.
   Yes, it can be solved e.g. by adding -L/usr/lib64 before -L/usr/lib, but I
   suppose many people will be horribly confused by that.

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?

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?

Ian

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

[Richard Henderson]

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.

Other comments?


r~

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

[H.J. Lu]

> 
> I'm trying to get elf32_sparc and elf64_sparc environments running on the
> same machine on Linux, but Solaris has apparently the same issues but
> different paths.
> Basically, elf64_sparc is incompatible architecture with elf32_sparc and I'd
> like to make things easier for people to link the right thing and not to
> crash on incompatible architectures for every link.
> The first hunk just sets the default search dirs for the elf64_sparc
> emulations, both when it is the default target and when the default is
> elf32_sparc. Solaris linker first tries paths ending with /lib/sparcv9
> and for Linux I'd like to use paths ending with /lib64.
> 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.
> 

The IA64 ABI group is dealing with the similar issue. Can we agree on
something?


H.J.

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

[Richard Henderson]

On Tue, Jun 08, 1999 at 12:14:52AM +0200, Jakub Jelinek wrote:
> 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?

My thinking is that the only way to link against an incompatible
library is to include it explicitly instead of by `-l'.

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

The only thing that even remotely comes to mind is a hetrogenous
multi-cpu embedded system thing, wherein you're linking code for
each of the processors into a single rom image.  I have no idea
whether this would actually work or not with just --no-warn-mismatch.

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

I have no problem with it.  I'm interested in hearing Ian's thoughts.


r~

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

[Richard Henderson]

On Tue, Jun 08, 1999 at 05:31:44PM -0400, Ian Lance Taylor wrote:
> 2) I don't understand why it's needed.  Changing the default search
>    path, as is done by the first half of the patch, sounds like the
>    right approach to me.  Irix faces these exact issues with its
>    multiple ABIs, yet it does not need this option.

That works for system directories, but not /usr/local/lib and other
such places under user control.  One could argue that we simply need
to teach old users new tricks.

> I don't think the option name --skip-mismatch is quite right.  That
> seems too general for this.  How about something like
> --skip-incompatible-archives?

We already have --[no-]warn-mismatch that's tangentially related.
That's presumably where Jakub got the name.


r~

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

[Richard Henderson]

On Wed, Jun 09, 1999 at 06:52:46PM -0400, Ian Lance Taylor wrote:
> 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.

Perhaps --skip-mismatch, while the default, also warns by default,
to be supressed by --no-warn-mismatch (for masochists)?

This whole multiple architecture configure+install issue wrt extant
packages is so horrible it makes me nauseous.



r~

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

[Ian Lance Taylor]

   Date: Tue, 8 Jun 1999 00:14:52 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   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?

--no-warn-mismatch is more likely to be used for object files rather
than archives.  Even if we make --skip-mismatch the default behaviour,
I don't see any need to change the behaviour of --no-warn-mismatch.

So I would pick your second choice if --skip-mismatch were to become
the default.  However, requiring things like specifying the full
pathname is exactly why I think it would be unwise to make
--skip-mismatch the default.  It becomes harder to predict the
linker's behaviour.

   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.

People use --no-warn-mismatch mainly for things like -mips2 vs. -mips3
object files.  C code compiled with -mips2 and -mips3 use different
calling conventions, so the linker prevents you from linking them
together.  However, in certain specific cases, such as when building a
kernel, it is desirable to link them together; the --no-warn-mismatch
option permits such cases.

Ian

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

[Ian Lance Taylor]

   Date: Mon, 7 Jun 1999 12:05:30 -0700
   From: Richard Henderson <rth@cygnus.com>

   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.

   Other comments?

I think it should be optional.

1) I think it's surprising.  You can predict which files the linker is
   going to happen based exclusively on the file name.  Anything which
   changes that can lead to confusion (e.g., the great confusion
   surrounding the GNU/Linux /etc/ld.so.cache file).

2) I don't understand why it's needed.  Changing the default search
   path, as is done by the first half of the patch, sounds like the
   right approach to me.  Irix faces these exact issues with its
   multiple ABIs, yet it does not need this option.

I don't think the option name --skip-mismatch is quite right.  That
seems too general for this.  How about something like
--skip-incompatible-archives?

Note that the patch changes ldfile_open_file_search.  That routine is
used for anything which appears in an INPUT statement in a linker
script, which includes files which are not archives.  I believe the
patch code in the case where the file is not an archive, because it
expects the architecture to be set before bfd_check_format is called
successfully.

Ian

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

[Jakub Jelinek]

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

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

[Jakub Jelinek]

On Wed, Jun 09, 1999 at 12:14:11AM -0400, Ian Lance Taylor wrote:
>    Date: Tue, 8 Jun 1999 20:49:32 -0700
>    From: Richard Henderson <rth@cygnus.com>
> 
>    On Tue, Jun 08, 1999 at 05:31:44PM -0400, Ian Lance Taylor wrote:
>    > 2) I don't understand why it's needed.  Changing the default search
>    >    path, as is done by the first half of the patch, sounds like the
>    >    right approach to me.  Irix faces these exact issues with its
>    >    multiple ABIs, yet it does not need this option.
> 
>    That works for system directories, but not /usr/local/lib and other
>    such places under user control.  One could argue that we simply need
>    to teach old users new tricks.
> 
> I don't see how it works for /usr/local/lib anyhow.  If you expect to
> find the library in /usr/local/lib, but the wrong library is there,
> then as far as I can see you won't find the library at all.  If you
> need to find it in some other directory, you will need to add a -L
> option, and if you do that it will work anyhow.

I don't claim the users can link their programs as they want even without
that patch (with the exception of the elf64_sparc.sh hunk which is needed),
but I wanted to make it convenient for the users so that we don't have to
fix zillions of configure scripts and Makefiles to teach them about
different ABIs.
One example: 
on sparc64, say the distribution will give the users the choice to install
all libraries in both ABIs, so the installer will nicely polulate both */lib
and */lib64 trees. But then a user will compile his own package in 64bit and
install it, its library will go say into /usr/lib. Say he compiles yet
another package (again 64bit) whose configure will look for that library,
find it in /usr/lib and add /usr/lib to the list to be passed as -L into
LDFLAGS. And now you have problem, because the -L/usr/lib will come before
the system libraries which include /usr/lib64, so the link will not succeed.
Yes, it can be solved e.g. by adding -L/usr/lib64 before -L/usr/lib, but I
suppose many people will be horribly confused by that.

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

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

[Jakub Jelinek]

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

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

[Ian Lance Taylor]

   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

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

[Ian Lance Taylor]

   Date: Wed, 9 Jun 1999 16:20:34 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Wed, Jun 09, 1999 at 06:52:46PM -0400, Ian Lance Taylor wrote:
   > 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.

   Perhaps --skip-mismatch, while the default, also warns by default,
   to be supressed by --no-warn-mismatch (for masochists)?

I could accept such a patch.

However, I continue to believe that it is better to avoid increasing
the confusion.  Making the linker smarter often seems like a sensible
approach, but my experience is that it tends to lead to unanticipated
trouble.  It's always better to have simple tools with transparent
behaviour.  There is a place for smart programs that try to guess what
you mean, but not in the binutils.

Ian