Can I link a.out .o with ELF?

Can I link a.out .o with ELF?

[H . J . Lu]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

I believe I used to be able to link a .o file in a.out on an ELF
system. But now I got

# gcc -o aout x.o
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

on Linux/ia32/ELF. Any ideas?

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

[-- Attachment #2: x.o --]
[-- Type: application/octet-stream, Size: 412 bytes --]

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Sun, Jun 04, 2000 at 06:07:39PM -0700, H . J . Lu wrote:
> I believe I used to be able to link a .o file in a.out on an ELF
> system. But now I got
> 
> # gcc -o aout x.o
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> 
> on Linux/ia32/ELF. Any ideas?
> 

It seems that it has something to do with symbol versioning. If
the a.out .o calls an unversioned symbol, it works.


H.J.

Re: Can I link a.out .o with ELF?

[Alan Modra]

On Sun, 4 Jun 2000, H . J . Lu wrote:

> I believe I used to be able to link a .o file in a.out on an ELF
> system. But now I got
> 
> # gcc -o aout x.o
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped

gcc -v output?  It's not clear to me whether you're using an elf linker to
link a.out objects with a.out start-up and libraries, or with elf startup
and libraries.  I'm guessing it's elf from looking at x.o

-- 
Linuxcare.  Support for the Revolution.

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Mon, Jun 05, 2000 at 11:30:08AM +1000, Alan Modra wrote:
> On Sun, 4 Jun 2000, H . J . Lu wrote:
> 
> > I believe I used to be able to link a .o file in a.out on an ELF
> > system. But now I got
> > 
> > # gcc -o aout x.o
> > collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> 
> gcc -v output?  It's not clear to me whether you're using an elf linker to
> link a.out objects with a.out start-up and libraries, or with elf startup
> and libraries.  I'm guessing it's elf from looking at x.o
> 

# gcc -v x.o
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/specs
gcc version 2.95.3 20000503/Linux (prerelease)
 /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/2.95.3 -L/usr/i386-redhat-linux/lib x.o -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/crtend.o /usr/lib/crtn.o
collect2: ld terminated with signal 11 [Segmentation fault], core dumped

It works with glibc 2.0, but not 2.1.

-- 
H.J. Lu (hjl@gnu.org)

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Sun, Jun 04, 2000 at 06:38:00PM -0700, H . J . Lu wrote:
> On Mon, Jun 05, 2000 at 11:30:08AM +1000, Alan Modra wrote:
> > On Sun, 4 Jun 2000, H . J . Lu wrote:
> > 
> > > I believe I used to be able to link a .o file in a.out on an ELF
> > > system. But now I got
> > > 
> > > # gcc -o aout x.o
> > > collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> > 
> > gcc -v output?  It's not clear to me whether you're using an elf linker to
> > link a.out objects with a.out start-up and libraries, or with elf startup
> > and libraries.  I'm guessing it's elf from looking at x.o
> > 
> 
> # gcc -v x.o
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/specs
> gcc version 2.95.3 20000503/Linux (prerelease)
>  /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/2.95.3 -L/usr/i386-redhat-linux/lib x.o -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/crtend.o /usr/lib/crtn.o
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> 
> It works with glibc 2.0, but not 2.1.
> 

It seems that ELF_LINK_NON_ELF doesn't work too well with symbol
versioning. As the result, when a verioned symbol is referenced
in an a.out .o file, the ELF_LINK_NON_ELF bit on the default symbol
is not set. I am not sure what else is not working right.


H.J.

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Sun, Jun 04, 2000 at 09:31:30PM -0700, H . J . Lu wrote:
> 
> It seems that ELF_LINK_NON_ELF doesn't work too well with symbol
> versioning. As the result, when a verioned symbol is referenced
> in an a.out .o file, the ELF_LINK_NON_ELF bit on the default symbol
> is not set. I am not sure what else is not working right.
> 

I have a patch to stop ld from dumping core. But it still doesn't
work right. On Linux/ia32/glibc 2.1 or glibc 2.2:

# make
gcc -o ok dummy.c x.o
gcc -o not x.o dummy.c
./ok || true
hello
./not
make: *** [all] Interrupt

I had to use Ctrl-C to stop it. The problem is ld sees printf
in x.o first.


H.J.
----
begin 644 aout.tar.gz
M'XL(```W.SD``^V72V_30!"`70$"KX2HQ*47I)$5I`0UV_4C3@E"0O*AEY9;
M;PCDVIO$Q+$C/Z)0RBDG;OPG>N&'('&`&V?*;.)`*B1R2E#+?,IZ9W9GL]9X
M9C5[Y`]D-XJEMD:$*83K.)H0*+GF<C_#<EU-M$W3=6W;;MO*WK5=#<0Z7VI!
MF1=^!J#U7\=_M5LU?T7QO*>](&#,C^,.I`-(TH+I?`^ELS,HLE(J30TR?'1@
MPE,(R^'P#0^87JM[7@.:*=2>0>TE8^F@LYA4AG\:!+'TDP[3LR$TNXO=&/H?
MQ]17"+JGX*=EP5'AO5,XJH)S^5^QY>Q?>^WZ4'EVK7NLRG_AM'_EOV4+9>^X
M%N7_)ABG4<AF00#UH(^>>)0WV%L&,,JBI.A"/6\\8>\HX:XK>**N?8]5^>_:
M3I7_PA)."\?;KNE0_F^"VUNAMK/U6U_X?+OJ^S*.4Z9]^%\Y?O]Y^O7.]/Q[
M7WGCR[<?%Q?3\^U/'QGZ[";^[F%_0]/NHJST&?>7Y!ULMY2`=@_FW8P:-BR\
MK%=!.AQAB1-RC1]Z0AOZ4:+-S]YU??)+8#6U]CU6Y;]CM9?RWY[G/]7_&T'G
MJL#6C0D/#"SUQS++HS31#6%R81KL<HAV&"_DI&`J4K%DYWF!@=K3C=DA\2(Q
MJFF=^W'42V"?\5Z<GL2@@IJI!RX:E7D_AH?R9,3T83I68C[:G>MYB<:U_5TU
MQ'0_#%%KFE:ESU?6U.9,#_#"4M4H"TO3K0SQEC'&>TLFU:M$H4P*W3CPO`[4
M#YX?-\#BCUO<!DN%7DO8>X=14DZ@/LID)G%I+AL&U3L$01`$01`$01`$01`$
001`$05Q=?@(H\\^``"@`````
`
end

Re: Can I link a.out .o with ELF?

[Alan Modra]

On Sun, 4 Jun 2000, H . J . Lu wrote:

> On Sun, Jun 04, 2000 at 09:31:30PM -0700, H . J . Lu wrote:
> > 
> > It seems that ELF_LINK_NON_ELF doesn't work too well with symbol
> > versioning. As the result, when a verioned symbol is referenced
> > in an a.out .o file, the ELF_LINK_NON_ELF bit on the default symbol
> > is not set. I am not sure what else is not working right.
> > 
> 
> I have a patch to stop ld from dumping core. But it still doesn't
> work right. On Linux/ia32/glibc 2.1 or glibc 2.2:

This patch seems to cure your testcase.  Warning: I have no idea whether
it's the ideal solution, or even correct.  Ian may be able to give a
better solution.

Regards, Alan Modra.
--
Linuxcare.  Support for the Revolution.


	* elflink.h (elf_link_add_object_symbols): Set hash flags for
	NON_ELF short name references of versioned symbols.
	(elf_fix_symbol_flags): Follow the link for indirect symbols.


Index: elflink.h
===================================================================
RCS file: /cvs/src/src/bfd/elflink.h,v
retrieving revision 1.58
diff -u -p -r1.58 elflink.h
--- elflink.h	2000/05/30 20:51:36	1.58
+++ elflink.h	2000/06/05 14:23:33
@@ -1741,6 +1741,20 @@ elf_link_add_object_symbols (abfd, info)
 		      ht = (struct elf_link_hash_entry *) hi->root.u.i.link;
 		      (*bed->elf_backend_copy_indirect_symbol) (ht, hi);
 
+		      if ((hi->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
+			{
+			  if (dynamic)
+			    hi->elf_link_hash_flags |=
+			      ELF_LINK_HASH_DEF_DYNAMIC;
+			  else
+			    hi->elf_link_hash_flags |=
+			      ELF_LINK_HASH_DEF_REGULAR;
+
+			  ht->elf_link_hash_flags |=
+			    (ELF_LINK_HASH_REF_REGULAR
+			     | ELF_LINK_HASH_REF_REGULAR_NONWEAK);
+			}
+
 		      /* See if the new flags lead us to realize that
 			 the symbol must be dynamic.  */
 		      if (! dynsym)
@@ -3283,11 +3297,15 @@ elf_fix_symbol_flags (h, eif)
      struct elf_link_hash_entry *h;
      struct elf_info_failed *eif;
 {
+  struct elf_link_hash_entry *ho = h;
+  while (h->root.type == bfd_link_hash_indirect)
+    h = (struct elf_link_hash_entry *) h->root.u.i.link;
+
   /* If this symbol was mentioned in a non-ELF file, try to set
      DEF_REGULAR and REF_REGULAR correctly.  This is the only way to
      permit a non-ELF file to correctly refer to a symbol defined in
      an ELF dynamic object.  */
-  if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
+  if ((ho->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
     {
       if (h->root.type != bfd_link_hash_defined
 	  && h->root.type != bfd_link_hash_defweak)

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Mon, Jun 05, 2000 at 11:30:08AM +1000, Alan Modra wrote:
> On Sun, 4 Jun 2000, H . J . Lu wrote:
> 
> > I believe I used to be able to link a .o file in a.out on an ELF
> > system. But now I got
> > 
> > # gcc -o aout x.o
> > collect2: ld terminated with signal 11 [Segmentation fault], core dumped
> 
> 

This patch seems to work for me. Any comments?

BTW, ld still got core dump when it tried to use a .o file in a.out
to created an ELF DSO, i.e.

# gcc -shared -o libaout.so aout.o

where aout.o is a non-PIC a.out .o file. I assume that is not supported
at all.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
2000-06-05  H.J. Lu  <hjl@gnu.org>

	* elflink.h (elf_fix_symbol_flags): Handle the ELF_LINK_NON_ELF
	bit set on the indirect symbol.
	(elf_link_output_extsym): Don't output the indirect symbol even
	if the ELF_LINK_NON_ELF bit is set.

Index: elflink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.30
diff -u -p -r1.30 elflink.h
--- elflink.h	2000/05/30 21:05:11	1.30
+++ elflink.h	2000/06/05 14:27:42
@@ -3287,6 +3287,36 @@ elf_fix_symbol_flags (h, eif)
      DEF_REGULAR and REF_REGULAR correctly.  This is the only way to
      permit a non-ELF file to correctly refer to a symbol defined in
      an ELF dynamic object.  */
+
+  if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) == 0)
+    {
+      const char *p;
+      char *def;
+      struct elf_link_hash_entry *d;
+
+      /* If this is a default version (the name contains @@),
+	 look up the symbol without the version. We have to set
+	 the ELF_LINK_NON_ELF bit on the default version if the
+	 indirect symbol has the bit set.  */
+
+      p = strchr (h->root.root.string, ELF_VER_CHR);
+      if (p != NULL && p[1] == ELF_VER_CHR)
+	{
+	  def = alloca (p - h->root.root.string + 1);
+	  memcpy (def, h->root.root.string, p - h->root.root.string);
+	  def[p - h->root.root.string] = '\0';
+
+	  d = elf_link_hash_lookup (elf_hash_table (eif->info), def,
+				    false, false, false);
+	} 
+      else
+	d = NULL;
+
+      if (d && (d->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0
+	  && d->root.type == bfd_link_hash_indirect)
+	h->elf_link_hash_flags |= ELF_LINK_NON_ELF;
+    }
+
   if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
     {
       if (h->root.type != bfd_link_hash_defined
@@ -5031,9 +5061,9 @@ elf_link_output_extsym (h, data)
          foo is used with no version, then we add an indirect symbol
          foo which points to foo@@GNU_1.2.  We ignore these symbols,
          since the indirected symbol is already in the hash table.  If
-         the indirect symbol is non-ELF, fall through and output it.  */
-      if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) == 0)
-	return true;
+         the indirect symbol is non-ELF, we don't fall through and
+	 output it since it is handled in elf_fix_symbol_flags ().  */
+      return true;
 
       /* Fall through.  */
     case bfd_link_hash_warning:

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Tue, Jun 06, 2000 at 12:28:01AM +1000, Alan Modra wrote:
> 
> This patch seems to cure your testcase.  Warning: I have no idea whether
> it's the ideal solution, or even correct.  Ian may be able to give a
> better solution.
> 

Your patch doesn't work with my second testcase in a tar file. It
failed to generating the working binary with

# gcc -o not x.o dummy.c

The part of my patch fixes it. I don't know which patch is correct.
I like yours better than mine :-(. BTW, can you get

# gcc -shared -o libaout.so aout.o

working?


H.J.
----
2000-06-05  H.J. Lu  <hjl@gnu.org>

	* elflink.h (elf_link_output_extsym): Don't output the indirect
	symbol even if the ELF_LINK_NON_ELF bit is set.

Index: elflink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.30
diff -u -p -r1.30 elflink.h
--- elflink.h	2000/05/30 21:05:11	1.30
+++ elflink.h	2000/06/05 14:52:34
@@ -5030,10 +5048,8 @@ elf_link_output_extsym (h, data)
          symbol foo@@GNU_1.2 is the default, which should be used when
          foo is used with no version, then we add an indirect symbol
          foo which points to foo@@GNU_1.2.  We ignore these symbols,
-         since the indirected symbol is already in the hash table.  If
-         the indirect symbol is non-ELF, fall through and output it.  */
-      if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) == 0)
-	return true;
+         since the indirected symbol is already in the hash table.  */
+      return true;
 
       /* Fall through.  */
     case bfd_link_hash_warning:

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Tue, Jun 06, 2000 at 12:28:01AM +1000, Alan Modra wrote:
> On Sun, 4 Jun 2000, H . J . Lu wrote:
> 
> > On Sun, Jun 04, 2000 at 09:31:30PM -0700, H . J . Lu wrote:
> > > 
> > > It seems that ELF_LINK_NON_ELF doesn't work too well with symbol
> > > versioning. As the result, when a verioned symbol is referenced
> > > in an a.out .o file, the ELF_LINK_NON_ELF bit on the default symbol
> > > is not set. I am not sure what else is not working right.
> > > 
> > 
> > I have a patch to stop ld from dumping core. But it still doesn't
> > work right. On Linux/ia32/glibc 2.1 or glibc 2.2:
> 
> This patch seems to cure your testcase.  Warning: I have no idea whether
> it's the ideal solution, or even correct.  Ian may be able to give a
> better solution.
> 
> Regards, Alan Modra.
> --
> Linuxcare.  Support for the Revolution.
> 
> 
> 	* elflink.h (elf_link_add_object_symbols): Set hash flags for
> 	NON_ELF short name references of versioned symbols.
> 	(elf_fix_symbol_flags): Follow the link for indirect symbols.
> 
> 

How about this patch? It works for my testcases except for building
ELF DSO.


H.J.
---
2000-06-05  Alan Modra  <alan@linuxcare.com.au>

	* elflink.h (elf_fix_symbol_flags): Follow the link for
	indirect symbols.

2000-06-05  H.J. Lu  <hjl@gnu.org>

	* elflink.h (elf_link_output_extsym): Don't output the indirect
	symbol even if the ELF_LINK_NON_ELF bit is set.

Index: elflink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.30
diff -u -p -r1.30 elflink.h
--- elflink.h	2000/05/30 21:05:11	1.30
+++ elflink.h	2000/06/05 15:53:44
@@ -3283,11 +3283,15 @@ elf_fix_symbol_flags (h, eif)
      struct elf_link_hash_entry *h;
      struct elf_info_failed *eif;
 {
+  struct elf_link_hash_entry *ho = h;
+  while (h->root.type == bfd_link_hash_indirect)
+    h = (struct elf_link_hash_entry *) h->root.u.i.link;
+
   /* If this symbol was mentioned in a non-ELF file, try to set
      DEF_REGULAR and REF_REGULAR correctly.  This is the only way to
      permit a non-ELF file to correctly refer to a symbol defined in
      an ELF dynamic object.  */
-  if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
+  if ((ho->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
     {
       if (h->root.type != bfd_link_hash_defined
 	  && h->root.type != bfd_link_hash_defweak)
@@ -5030,10 +5034,8 @@ elf_link_output_extsym (h, data)
          symbol foo@@GNU_1.2 is the default, which should be used when
          foo is used with no version, then we add an indirect symbol
          foo which points to foo@@GNU_1.2.  We ignore these symbols,
-         since the indirected symbol is already in the hash table.  If
-         the indirect symbol is non-ELF, fall through and output it.  */
-      if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) == 0)
-	return true;
+         since the indirected symbol is already in the hash table.  */
+      return true;
 
       /* Fall through.  */
     case bfd_link_hash_warning:

Re: Can I link a.out .o with ELF?

[Ian Lance Taylor]

   Date: Tue, 6 Jun 2000 00:28:01 +1000 (EST)
   From: Alan Modra <alan@linuxcare.com.au>

   Index: elflink.h
   ===================================================================
   RCS file: /cvs/src/src/bfd/elflink.h,v
   retrieving revision 1.58
   diff -u -p -r1.58 elflink.h
   --- elflink.h	2000/05/30 20:51:36	1.58
   +++ elflink.h	2000/06/05 14:23:33
   @@ -1741,6 +1741,20 @@ elf_link_add_object_symbols (abfd, info)
			 ht = (struct elf_link_hash_entry *) hi->root.u.i.link;
			 (*bed->elf_backend_copy_indirect_symbol) (ht, hi);

   +		      if ((hi->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
   +			{
   +			  if (dynamic)
   +			    hi->elf_link_hash_flags |=
   +			      ELF_LINK_HASH_DEF_DYNAMIC;
   +			  else
   +			    hi->elf_link_hash_flags |=
   +			      ELF_LINK_HASH_DEF_REGULAR;
   +
   +			  ht->elf_link_hash_flags |=
   +			    (ELF_LINK_HASH_REF_REGULAR
   +			     | ELF_LINK_HASH_REF_REGULAR_NONWEAK);
   +			}
   +
			 /* See if the new flags lead us to realize that
			    the symbol must be dynamic.  */
			 if (! dynsym)

I don't understand why you would ever want to set DEF_DYNAMIC here.
You should only get ELF_LINK_NON_ELF when the symbol appears in a
non-ELF file.  The ELF linker does not support linking against a
non-ELF dynamic library.

It should only be necessary to set DEF_REGULAR if the symbol is in
fact defined in a non-ELF file.  Similarly, it should only be
necessary to set REF_REGULAR and REF_REGULAR_NONWEAK if the symbol is
referenced in a non-ELF file.  The code above may well be correct on
this, although I don't really understand why we need to set them here
as opposed to various other places.

   @@ -3283,11 +3297,15 @@ elf_fix_symbol_flags (h, eif)
	 struct elf_link_hash_entry *h;
	 struct elf_info_failed *eif;
    {
   +  struct elf_link_hash_entry *ho = h;
   +  while (h->root.type == bfd_link_hash_indirect)
   +    h = (struct elf_link_hash_entry *) h->root.u.i.link;
   +
      /* If this symbol was mentioned in a non-ELF file, try to set
	 DEF_REGULAR and REF_REGULAR correctly.  This is the only way to
	 permit a non-ELF file to correctly refer to a symbol defined in
	 an ELF dynamic object.  */
   -  if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
   +  if ((ho->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
	{
	  if (h->root.type != bfd_link_hash_defined
	     && h->root.type != bfd_link_hash_defweak)

I don't think it is right to change h here.  elf_fix_symbol_flags
should get called for every h.

I don't quite see why you are doing this.  I assume it has something
to do with the call from elf_link_assign_sym_version.  But I don't see
why it works.

What happens if you just patch elf_link_assign_sym_version to work on
NON_ELF symbols as well as DEF_REGULAR symbols?

Ian

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Mon, Jun 05, 2000 at 08:39:06AM -0700, Ian Lance Taylor wrote:
>    Date: Tue, 6 Jun 2000 00:28:01 +1000 (EST)
>    From: Alan Modra <alan@linuxcare.com.au>
> 
>    Index: elflink.h
>    ===================================================================
>    RCS file: /cvs/src/src/bfd/elflink.h,v
>    retrieving revision 1.58
>    diff -u -p -r1.58 elflink.h
>    --- elflink.h	2000/05/30 20:51:36	1.58
>    +++ elflink.h	2000/06/05 14:23:33
>    @@ -1741,6 +1741,20 @@ elf_link_add_object_symbols (abfd, info)
> 			 ht = (struct elf_link_hash_entry *) hi->root.u.i.link;
> 			 (*bed->elf_backend_copy_indirect_symbol) (ht, hi);
> 
>    +		      if ((hi->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
>    +			{
>    +			  if (dynamic)
>    +			    hi->elf_link_hash_flags |=
>    +			      ELF_LINK_HASH_DEF_DYNAMIC;
>    +			  else
>    +			    hi->elf_link_hash_flags |=
>    +			      ELF_LINK_HASH_DEF_REGULAR;
>    +
>    +			  ht->elf_link_hash_flags |=
>    +			    (ELF_LINK_HASH_REF_REGULAR
>    +			     | ELF_LINK_HASH_REF_REGULAR_NONWEAK);
>    +			}
>    +
> 			 /* See if the new flags lead us to realize that
> 			    the symbol must be dynamic.  */
> 			 if (! dynsym)
> 
> I don't understand why you would ever want to set DEF_DYNAMIC here.
> You should only get ELF_LINK_NON_ELF when the symbol appears in a
> non-ELF file.  The ELF linker does not support linking against a
> non-ELF dynamic library.
> 
> It should only be necessary to set DEF_REGULAR if the symbol is in
> fact defined in a non-ELF file.  Similarly, it should only be
> necessary to set REF_REGULAR and REF_REGULAR_NONWEAK if the symbol is
> referenced in a non-ELF file.  The code above may well be correct on
> this, although I don't really understand why we need to set them here
> as opposed to various other places.

It is not needed.

> 
>    @@ -3283,11 +3297,15 @@ elf_fix_symbol_flags (h, eif)
> 	 struct elf_link_hash_entry *h;
> 	 struct elf_info_failed *eif;
>     {
>    +  struct elf_link_hash_entry *ho = h;
>    +  while (h->root.type == bfd_link_hash_indirect)
>    +    h = (struct elf_link_hash_entry *) h->root.u.i.link;
>    +
>       /* If this symbol was mentioned in a non-ELF file, try to set
> 	 DEF_REGULAR and REF_REGULAR correctly.  This is the only way to
> 	 permit a non-ELF file to correctly refer to a symbol defined in
> 	 an ELF dynamic object.  */
>    -  if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
>    +  if ((ho->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
> 	{
> 	  if (h->root.type != bfd_link_hash_defined
> 	     && h->root.type != bfd_link_hash_defweak)
> 
> I don't think it is right to change h here.  elf_fix_symbol_flags
> should get called for every h.
> 

How about the patch enclosed here? It will only follow the indirect
symbol with the ELF_LINK_NON_ELF bit set.

> 
> What happens if you just patch elf_link_assign_sym_version to work on
> NON_ELF symbols as well as DEF_REGULAR symbols?
> 

The problem is we have to call _bfd_elf_link_record_dynamic_symbol on
the default symbol. Follow the indirect symbol will do it.


H.J.
----
Index: elflink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.30
diff -u -p -r1.30 elflink.h
--- elflink.h	2000/05/30 21:05:11	1.30
+++ elflink.h	2000/06/05 17:05:07
@@ -3289,6 +3289,9 @@ elf_fix_symbol_flags (h, eif)
      an ELF dynamic object.  */
   if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) != 0)
     {
+      while (h->root.type == bfd_link_hash_indirect)
+	h = (struct elf_link_hash_entry *) h->root.u.i.link;
+
       if (h->root.type != bfd_link_hash_defined
 	  && h->root.type != bfd_link_hash_defweak)
 	h->elf_link_hash_flags |= (ELF_LINK_HASH_REF_REGULAR
@@ -5030,10 +5033,8 @@ elf_link_output_extsym (h, data)
          symbol foo@@GNU_1.2 is the default, which should be used when
          foo is used with no version, then we add an indirect symbol
          foo which points to foo@@GNU_1.2.  We ignore these symbols,
-         since the indirected symbol is already in the hash table.  If
-         the indirect symbol is non-ELF, fall through and output it.  */
-      if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) == 0)
-	return true;
+         since the indirected symbol is already in the hash table.  */
+      return true;
 
       /* Fall through.  */
     case bfd_link_hash_warning:

Re: Can I link a.out .o with ELF?

[Ian Lance Taylor]

   Date: Mon, 5 Jun 2000 10:14:48 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   How about the patch enclosed here? It will only follow the indirect
   symbol with the ELF_LINK_NON_ELF bit set.

This patch looks reasonable to me.

Ian

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Mon, Jun 05, 2000 at 10:16:09AM -0700, Ian Lance Taylor wrote:
>    Date: Mon, 5 Jun 2000 10:14:48 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    How about the patch enclosed here? It will only follow the indirect
>    symbol with the ELF_LINK_NON_ELF bit set.
> 
> This patch looks reasonable to me.
> 


Thanks. It passed all my testcases. I checked it in.


H.J.

Re: Can I link a.out .o with ELF?

[H . J . Lu]

On Mon, Jun 05, 2000 at 07:53:51PM +0200, Mark Kettenis wrote:
> 
> 	  /* Fall through.  */
> 	case bfd_link_hash_warning:
> 
> ... I find the "Fall through" just after `return true' rather
> intriguing.
> 

Ooops. Removed.


H.J.

Re: Can I link a.out .o with ELF?

[Mark Kettenis]

Hmm ...

   @@ -5030,10 +5033,8 @@ elf_link_output_extsym (h, data)
	     symbol foo@@GNU_1.2 is the default, which should be used when
	     foo is used with no version, then we add an indirect symbol
	     foo which points to foo@@GNU_1.2.  We ignore these symbols,
   -         since the indirected symbol is already in the hash table.  If
   -         the indirect symbol is non-ELF, fall through and output it.  */
   -      if ((h->elf_link_hash_flags & ELF_LINK_NON_ELF) == 0)
   -       return true;
   +         since the indirected symbol is already in the hash table.  */
   +      return true;

	  /* Fall through.  */
	case bfd_link_hash_warning:

... I find the "Fall through" just after `return true' rather
intriguing.

Mark