binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[Alexandre Oliva]

Bootstrapping GCC 3.0's latest snapshot on alphaev6-unknown-linux-gnu
(Red Hat Linux 7 for alpha) using binutils 2.11's CVS tree failed to
link libobjc.so as follows:

/tmp/egcs/gcc/xgcc -B/tmp/egcs/gcc/ -B/home/lsd/oliva/test/egcs/alpha-Linux-2.2.17-14smp/alphaev6-unknown-linux-gnu/bin/ -B/home/lsd/oliva/test/egcs/alpha-Linux-2.2.17-14smp/alphaev6-unknown-linux-gnu/lib/ -isystem /home/lsd/oliva/test/egcs/alpha-Linux-2.2.17-14smp/alphaev6-unknown-linux-gnu/include -L/tmp/egcs/ld -shared  .libs/archive.o .libs/class.o .libs/encoding.o .libs/gc.o .libs/hash.o .libs/init.o .libs/linking.o .libs/misc.o .libs/nil_method.o .libs/NXConstStr.o .libs/Object.o .libs/objects.o .libs/Protocol.o .libs/sarray.o .libs/selector.o .libs/sendmsg.o .libs/thr.o .libs/thr-objc.o  -L/tmp/egcs/ld -lc  -Wl,-soname -Wl,libobjc.so.1 -o .libs/libobjc.so.1.0.0
lt-ld-new: .libs/libobjc.so.1.0.0: Not enough room for program headers (allocated 3, need 4)
lt-ld-new: final link failed: Bad value
collect2: ld returned 1 exit status

This also happened last week.  Unfortunately, I haven't bootstrapped
GCC+binutils for 2 or 3 weeks before that, so I can't tell for how
long the problem has been there.  I'm sure it wasn't there at the time
of GCC 3.0, though, which is odd.  I guess it's something in GCC that
exposes a problem in binutils, since the problem is already present in
GNU binutils 2.11, but not in Red Hat Linux 7 for alpha's
binutils-2.10.0.18-3.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[H . J . Lu]

On Tue, Jul 10, 2001 at 07:28:27PM -0300, Alexandre Oliva wrote:
> Bootstrapping GCC 3.0's latest snapshot on alphaev6-unknown-linux-gnu
> (Red Hat Linux 7 for alpha) using binutils 2.11's CVS tree failed to
> link libobjc.so as follows:
> 
> /tmp/egcs/gcc/xgcc -B/tmp/egcs/gcc/ -B/home/lsd/oliva/test/egcs/alpha-Linux-2.2.17-14smp/alphaev6-unknown-linux-gnu/bin/ -B/home/lsd/oliva/test/egcs/alpha-Linux-2.2.17-14smp/alphaev6-unknown-linux-gnu/lib/ -isystem /home/lsd/oliva/test/egcs/alpha-Linux-2.2.17-14smp/alphaev6-unknown-linux-gnu/include -L/tmp/egcs/ld -shared  .libs/archive.o .libs/class.o .libs/encoding.o .libs/gc.o .libs/hash.o .libs/init.o .libs/linking.o .libs/misc.o .libs/nil_method.o .libs/NXConstStr.o .libs/Object.o .libs/objects.o .libs/Protocol.o .libs/sarray.o .libs/selector.o .libs/sendmsg.o .libs/thr.o .libs/thr-objc.o  -L/tmp/egcs/ld -lc  -Wl,-soname -Wl,libobjc.so.1 -o .libs/libobjc.so.1.0.0
> lt-ld-new: .libs/libobjc.so.1.0.0: Not enough room for program headers (allocated 3, need 4)
> lt-ld-new: final link failed: Bad value
> collect2: ld returned 1 exit status
> 
> This also happened last week.  Unfortunately, I haven't bootstrapped
> GCC+binutils for 2 or 3 weeks before that, so I can't tell for how
> long the problem has been there.  I'm sure it wasn't there at the time
> of GCC 3.0, though, which is odd.  I guess it's something in GCC that
> exposes a problem in binutils, since the problem is already present in
> GNU binutils 2.11, but not in Red Hat Linux 7 for alpha's
> binutils-2.10.0.18-3.
> 

Try this patch.


H.J.
----
2001-07-10  H.J. Lu  <hjl@gnu.org>

	* elf64-alpha.c (elf64_alpha_check_relocs): Only use the same
	ALLOC|LOAD flags as the source section when creating the reloc
	section for debugging sections.

Index: elf64-alpha.c
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elf64-alpha.c,v
retrieving revision 1.28
diff -u -p -r1.28 elf64-alpha.c
--- elf64-alpha.c	2001/05/23 18:36:03	1.28
+++ elf64-alpha.c	2001/07/11 04:36:14
@@ -2589,8 +2589,13 @@ elf64_alpha_check_relocs (abfd, info, se
 		  sreloc = bfd_make_section (dynobj, rel_sec_name);
 		  if (sreloc == NULL
 		      || !bfd_set_section_flags (dynobj, sreloc,
-						 ((sec->flags & (SEC_ALLOC
-								 | SEC_LOAD))
+						 (((sec->flags
+						    & SEC_DEBUGGING)
+						   ? (sec->flags
+						      & (SEC_ALLOC
+							 | SEC_LOAD))
+						   : (SEC_ALLOC
+						      | SEC_LOAD))
 						  | SEC_HAS_CONTENTS
 						  | SEC_IN_MEMORY
 						  | SEC_LINKER_CREATED

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[Alexandre Oliva]

On Jul 11, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

>> lt-ld-new: .libs/libobjc.so.1.0.0: Not enough room for program headers (allocated 3, need 4)
>> lt-ld-new: final link failed: Bad value
>> collect2: ld returned 1 exit status

> Try this patch.

> 	* elf64-alpha.c (elf64_alpha_check_relocs): Only use the same
> 	ALLOC|LOAD flags as the source section when creating the reloc
> 	section for debugging sections.

Thanks, it does fix the problem, indeed.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[Rainer Orth]

Alexandre Oliva <aoliva@redhat.com> writes:

> Bootstrapping GCC 3.0's latest snapshot on alphaev6-unknown-linux-gnu
> (Red Hat Linux 7 for alpha) using binutils 2.11's CVS tree failed to
> link libobjc.so as follows:

I suppose you configured GCC with --enable-shared?  The only effect of
this, on most platforms, is to build a shared libobjc which is disabled by
default.

> lt-ld-new: .libs/libobjc.so.1.0.0: Not enough room for program headers (allocated 3, need 4)
> lt-ld-new: final link failed: Bad value
> collect2: ld returned 1 exit status

The same problem happened on alpha-*-freebsd5.0 after I checked in

	http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01880.html

After some discussion with Loren Rittle and checking the ld manual, it
became clear that the use of SIZEOF_HEADERS in the elf64alpha linker script
is the culprit, and one of the hints in the ld manual about how to fix this
should be implemented.  Loren agreed to leave the patch in and check with
the FreeBSD binutils maintainers how to fix this.  Loren, did you come to a
conclusion yet?

I suppose this clearly indicates that we need an even stronger warning
about not to use --enable-shared unless you know *exactly* what you're
doing in install.texi?

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[H . J . Lu]

On Wed, Jul 11, 2001 at 03:46:38AM -0300, Alexandre Oliva wrote:
> On Jul 11, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> >> lt-ld-new: .libs/libobjc.so.1.0.0: Not enough room for program headers (allocated 3, need 4)
> >> lt-ld-new: final link failed: Bad value
> >> collect2: ld returned 1 exit status
> 
> > Try this patch.
> 
> > 	* elf64-alpha.c (elf64_alpha_check_relocs): Only use the same
> > 	ALLOC|LOAD flags as the source section when creating the reloc
> > 	section for debugging sections.
> 
> Thanks, it does fix the problem, indeed.
> 

The problem is introduced by this patch:

http://sources.redhat.com/ml/binutils/2000-11/msg00246.html

In linking.o from libobjc, there are

Relocation section '.rela.sbss' at offset 0x3938 contains 2 entries:
  Offset    Info  Type            Symbol's Value  Symbol's Name          Addend
  00000000  1a00000002 R_ALPHA_REFQUAD       0000000000000000
__objc_class_name_Object  + 0
  00000008  1b00000002 R_ALPHA_REFQUAD       0000000000000000
__objc_class_name_NXConst + 0

and

  8 .sbss         00000010  0000000000000000  0000000000000000  00002820  2**3
                  ALLOC, RELOC

There is no SEC_LOAD on .sbss. But .rela.sbss has to have SEC_LOAD.
Otherwise, you will get that error. Richard's patch fixed debugging
sections, but brake the linker. I will check in my patch if I don't
hear any objections soon.


H.J.

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[H . J . Lu]

On Wed, Jul 11, 2001 at 02:04:16PM +0200, Rainer Orth wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
> 
> > Bootstrapping GCC 3.0's latest snapshot on alphaev6-unknown-linux-gnu
> > (Red Hat Linux 7 for alpha) using binutils 2.11's CVS tree failed to
> > link libobjc.so as follows:
> 
> I suppose you configured GCC with --enable-shared?  The only effect of
> this, on most platforms, is to build a shared libobjc which is disabled by
> default.
> 
> > lt-ld-new: .libs/libobjc.so.1.0.0: Not enough room for program headers (allocated 3, need 4)
> > lt-ld-new: final link failed: Bad value
> > collect2: ld returned 1 exit status
> 
> The same problem happened on alpha-*-freebsd5.0 after I checked in
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01880.html
> 
> After some discussion with Loren Rittle and checking the ld manual, it
> became clear that the use of SIZEOF_HEADERS in the elf64alpha linker script
> is the culprit, and one of the hints in the ld manual about how to fix this
> should be implemented.  Loren agreed to leave the patch in and check with
> the FreeBSD binutils maintainers how to fix this.  Loren, did you come to a
> conclusion yet?
> 

Don't bother. It is a linker bug. I am going to check in a patch to
fix it.


H.J.

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[Alexandre Oliva]

On Jul 11, 2001, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> Bootstrapping GCC 3.0's latest snapshot on alphaev6-unknown-linux-gnu
>> (Red Hat Linux 7 for alpha) using binutils 2.11's CVS tree failed to
>> link libobjc.so as follows:

> I suppose you configured GCC with --enable-shared?  The only effect of
> this, on most platforms, is to build a shared libobjc which is disabled by
> default.

Indeed.  But why are libobjc shared libraries disabled by default?
--enable-shared is supposed to be the default these days.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[Richard Henderson]

On Tue, Jul 10, 2001 at 09:39:50PM -0700, H . J . Lu wrote:
> -						 ((sec->flags & (SEC_ALLOC
> -								 | SEC_LOAD))
> +						 (((sec->flags
> +						    & SEC_DEBUGGING)
> +						   ? (sec->flags
> +						      & (SEC_ALLOC
> +							 | SEC_LOAD))
> +						   : (SEC_ALLOC
> +						      | SEC_LOAD))

Why should SEC_DEBUGGING be involved?  Why not

	sec->flags & SEC_ALLOC ? SEC_ALLOC | SEC_LOAD : 0


r~

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[H . J . Lu]

On Wed, Jul 11, 2001 at 02:15:53PM -0700, Richard Henderson wrote:
> On Tue, Jul 10, 2001 at 09:39:50PM -0700, H . J . Lu wrote:
> > -						 ((sec->flags & (SEC_ALLOC
> > -								 | SEC_LOAD))
> > +						 (((sec->flags
> > +						    & SEC_DEBUGGING)
> > +						   ? (sec->flags
> > +						      & (SEC_ALLOC
> > +							 | SEC_LOAD))
> > +						   : (SEC_ALLOC
> > +						      | SEC_LOAD))
> 
> Why should SEC_DEBUGGING be involved?  Why not
> 
> 	sec->flags & SEC_ALLOC ? SEC_ALLOC | SEC_LOAD : 0

That should work.


H.J.

Re: binutils 2.11-CVS won't link GCC 3.0-snap's libobjc.so on Red Hat

[David O'Brien]

On Wed, Jul 11, 2001 at 02:04:16PM +0200, Rainer Orth wrote:
> The same problem happened on alpha-*-freebsd5.0 after I checked in
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01880.html
> 
> After some discussion with Loren Rittle and checking the ld manual, it
> became clear that the use of SIZEOF_HEADERS in the elf64alpha linker script
> is the culprit, and one of the hints in the ld manual about how to fix this
> should be implemented.  Loren agreed to leave the patch in and check with
> the FreeBSD binutils maintainers how to fix this.  Loren, did you come to a
> conclusion yet?

I haven't had time to look into this yet.  FreeBSD AXP-5-CURRENT
(in-development version) has been *very* rocky for the past 3 mo.  So I
haven't had a really stable Alpha to test things on.  Loren is using an
outdated box for his testing.

> I suppose this clearly indicates that we need an even stronger warning
> about not to use --enable-shared unless you know *exactly* what you're
> doing in install.texi?

Works for me.  *Personally*, I do not support people trying to use a
shared libstdc++ built from GCC sources.  Mostly because people forget to
supply the shared lib with their binaries, and I've seen recipients try
to symlink the base system's libstdc++ to the sh name the binary wants.
And of course the libs could be very different.

-- 
-- David  (obrien@FreeBSD.org)