Bug 2607 - linker doesn't recognize an ELF library.
Summary: linker doesn't recognize an ELF library.
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.16
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-26 13:59 UTC by Pawel Sikora
Modified: 2006-05-10 22:31 UTC (History)
2 users (show)

See Also:
Host:
Target: sparc-sun-solaris2.9
Build: x86_64-gnu-linux
Last reconfirmed:


Attachments
libbug.so.cc from example in previous comment (1.12 KB, application/octet-stream)
2006-05-09 19:45 UTC, Stephen Pope
Details
libbug.so.CC from previous example (1.70 KB, application/octet-stream)
2006-05-09 19:46 UTC, Stephen Pope
Details
libbug.so.ld from previous example (1.70 KB, application/octet-stream)
2006-05-09 19:47 UTC, Stephen Pope
Details
Fix determination of valid section indicies (1.04 KB, patch)
2006-05-10 12:24 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Sikora 2006-04-26 13:59:02 UTC
$ file libcmodel.so
libcmodel.so: ELF 32-bit MSB shared object, SPARC, version 1 (SYSV), stripped

$ hexdump -n 256 libcmodel.so -C
00000000  7f 45 4c 46 01 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  00 03 00 02 00 00 00 01  00 00 00 94 00 00 00 34  |...............4|
00000020  00 05 27 04 00 00 00 00  00 34 00 20 00 03 00 28  |..'......4. ...(|
00000030  00 19 00 17 00 00 00 01  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 05 04 e9  00 05 04 e9 00 00 00 05  |................|
00000050  00 01 00 00 00 00 00 01  00 05 04 ec 00 06 04 ec  |................|
00000060  00 00 00 00 00 00 20 f8  00 00 20 f8 00 00 00 07  |...... ... .....|
00000070  00 01 00 00 00 00 00 02  00 05 17 48 00 06 17 48  |...........H...H|
00000080  00 00 00 00 00 00 00 e0  00 00 00 00 00 00 00 07  |................|
00000090  00 00 00 00 00 00 02 a1  00 00 02 99 00 00 00 00  |................|
000000a0  00 00 00 01 00 00 00 03  00 00 00 04 00 00 00 06  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 07 00 00 00 09  |................|
000000c0  00 00 00 00 00 00 00 0a  00 00 00 00 00 00 00 0b  |................|
000000d0  00 00 00 0c 00 00 00 0e  00 00 00 00 00 00 00 0f  |................|
000000e0  00 00 00 11 00 00 00 13  00 00 00 14 00 00 00 17  |................|
000000f0  00 00 00 00 00 00 00 19  00 00 00 1a 00 00 00 1c  |................|

$ sparc-sun-solaris2.9-ld libcmodel.so -o /dev/null --verbose
GNU ld version 2.16.91.0.7 20060317
  Supported emulations:
   elf32_sparc
   elf64_sparc
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-sparc", "elf32-sparc",
              "elf32-sparc")
OUTPUT_ARCH(sparc)
ENTRY(_start)
SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/usr/ccs/lib"); 
SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = 0x10000); . = 0x10000 + SIZEOF_HEADERS;
  .interp         : { *(.interp) }
  .hash           : { *(.hash) }
  .dynsym         : { *(.dynsym) }
  .dynstr         : { *(.dynstr) }
  .gnu.version    : { *(.gnu.version) }
  .gnu.version_d  : { *(.gnu.version_d) }
  .gnu.version_r  : { *(.gnu.version_r) }
  .rel.dyn        :
    {
      *(.rel.init)
      *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
      *(.rel.fini)
      *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
      *(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*)
      *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
      *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
      *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
      *(.rel.ctors)
      *(.rel.dtors)
      *(.rel.got)
      *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
    }
  .rela.dyn       :
    {
      *(.rela.init)
      *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
      *(.rela.fini)
      *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
      *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
      *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
      *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
      *(.rela.ctors)
      *(.rela.dtors)
      *(.rela.got)
      *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
    }
  .rel.plt        : { *(.rel.plt) }
  .rela.plt       : { *(.rela.plt) }
  .init           :
  {
    KEEP (*(.init))
  } =0
  .text           :
  {
    *(.text .stub .text.* .gnu.linkonce.t.*)
    KEEP (*(.text.*personality*))
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
  } =0
  .fini           :
  {
    KEEP (*(.fini))
  } =0
  PROVIDE (__etext = .);
  PROVIDE (_etext = .);
  PROVIDE (etext = .);
  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
  .rodata1        : { *(.rodata1) }
  .eh_frame_hdr : { *(.eh_frame_hdr) }
  .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) }
  .gcc_except_table   : ONLY_IF_RO { 
*(.gcc_except_table .gcc_except_table.*) }
  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  . = ALIGN (0x10000) - ((0x10000 - .) & (0x10000 - 1)); . = 
DATA_SEGMENT_ALIGN (0x10000, 0x2000);
  /* Exception handling  */
  .eh_frame       : ONLY_IF_RW { KEEP (*(.eh_frame)) }
  .gcc_except_table   : ONLY_IF_RW { 
*(.gcc_except_table .gcc_except_table.*) }
  /* Thread Local Storage sections  */
  .tdata          : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
  .tbss           : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  }
  .init_array     :
  {
     PROVIDE_HIDDEN (__init_array_start = .);
     KEEP (*(SORT(.init_array.*)))
     KEEP (*(.init_array))
     PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array     :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(.fini_array))
    KEEP (*(SORT(.fini_array.*)))
    PROVIDE_HIDDEN (__fini_array_end = .);
  }
  .ctors          :
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter wh directory crtbegin.o
       is in.  */
    KEEP (*crtbegin*.o(.ctors))
    /* We don't want to include the .ctor section from
       the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  }
  .dtors          :
  {
    KEEP (*crtbegin*.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }
  .jcr            : { KEEP (*(.jcr)) }
  .data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) 
*(.data.rel.ro* .gnu.linkonce.d.rel.ro.*) }
  .dynamic        : { *(.dynamic) }
  . = DATA_SEGMENT_RELRO_END (0, .);
  .got            : { *(.got.plt) *(.got) }
  .plt            : { *(.plt) }
  .data           :
  {
    *(.data .data.* .gnu.linkonce.d.*)
    KEEP (*(.gnu.linkonce.d.*personality*))
    SORT(CONSTRUCTORS)
  }
  .data1          : { *(.data1) }
  _edata = .; PROVIDE (edata = .);
  __bss_start = .;
  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.
      FIXME: Why do we need it? When there is no .bss section, we don't
      pad the .data section.  */
   . = ALIGN(. != 0 ? 8 : 1);
  }
  . = ALIGN(8);
  . = ALIGN(8);
  _end = .; PROVIDE (end = .);
  . = DATA_SEGMENT_END (.);
  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /DISCARD/ : { *(.note.GNU-stack) }
}


==================================================
attempt to open libcmodel.so succeeded
opened script file libcmodel.so
libcmodel.so: file not recognized: File format not recognized
Comment 1 Pawel Sikora 2006-04-26 14:03:26 UTC
$ eu-readelf -h libcmodel.so
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           SPARC
  Version:                           1 (current)
  Entry point address:               0x94
  Start of program headers:          52 (bytes into file)
  Start of section headers:          337668 (bytes into file)
  Flags:
  Size of this header:               52 (bytes)
  Size of program header entries:    32 (bytes)
  Number of program headers entries: 3
  Size of section header entries:    40 (bytes)
  Number of section headers entries: 25
  Section header string table index: 23
Comment 2 Pawel Sikora 2006-04-26 14:17:16 UTC
strip also can't handle this precompiled external library.

$ sparc-sun-solaris2.9-strip -g libcmodel.so --verbose
sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized

in general binutils works.

$ :> dummy.cpp
$ sparc-sun-solaris2.9-g++ dummy.cpp -shared -o libdummy.so
$ sparc-sun-solaris2.9-strip -g libdummy.so --verbose
copy from `libdummy.so' [elf32-sparc] to `stTTbQEv' [elf32-sparc]
Comment 3 Nick Clifton 2006-05-05 17:15:07 UTC
Subject: Re:  linker doesn't recognize an ELF library.

Hi Pawel,

> strip also can't handle this precompiled external library.
> 
> $ sparc-sun-solaris2.9-strip -g libcmodel.so --verbose
> sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized

How was this libcmodel.so file created ?

Are you able to create a small test case that builds an unrecognizable 
file so that we can test binutils locally ?

Cheers
   Nick

Comment 4 Pawel Sikora 2006-05-05 21:07:34 UTC
(In reply to comment #3)
> Subject: Re:  linker doesn't recognize an ELF library.
> 
> Hi Pawel,
> 
> > strip also can't handle this precompiled external library.
> > 
> > $ sparc-sun-solaris2.9-strip -g libcmodel.so --verbose
> > sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized
> 
> How was this libcmodel.so file created ?

I don't know. It's a commercial closed source library
which works perfectly with native solaris linker/stripper
and doesn't work with gnu/crossbinutils-2.16.91.0.7
On monday I will check our NDAs and try to attach
this weird ELF library to this bug report for future tests.
Comment 5 Nick Clifton 2006-05-08 16:40:36 UTC
Subject: Re:  linker doesn't recognize an ELF library.

Hi Pawel,

> I don't know. It's a commercial closed source library
> which works perfectly with native solaris linker/stripper
> and doesn't work with gnu/crossbinutils-2.16.91.0.7
> On monday I will check our NDAs and try to attach
> this weird ELF library to this bug report for future tests.

If the NDA does not allow you to supply a test file, then there is not 
much that we will able to do.  One thing you could try though is to run 
"readelf -a -w libcmodel.so" and see if readelf reports any errors or 
problems in the file.  (I am assuming that the file is somehow not quite 
conformant to the ELF standard and this is why it is not being recognised).

Is the supplier of the file Cisco by any chance ?  We had another bug 
report recently about binutils not being able to handle some files made 
by Cisco and a patch was developed to solve the problem.

Cheers
   Nick


Comment 6 Pawel Sikora 2006-05-09 09:25:42 UTC
(In reply to comment #5)

> If the NDA does not allow you to supply a test file, then there is not 
> much that we will able to do.  One thing you could try though is to run 
> "readelf -a -w libcmodel.so" and see if readelf reports any errors or 
> problems in the file.  (I am assuming that the file is somehow not quite 
> conformant to the ELF standard and this is why it is not being recognised).

readelf -a -w doesn't report any warnings/errors.

> Is the supplier of the file Cisco by any chance ?

i'm sure it's not a cisco product.
it was compiled with sun workshop studio.

i've checked an older version (2.15) of binutils and it works.

current 2.16 fails...

$ sparc-sun-solaris2.9-strip libcmodel.so -v --strip-unneeded
sparc-sun-solaris2.9-strip: libcmodel.so: File format not recognized

so, strip with older (2.15) version...

$ /usr/local/solaris-cross/bin/sparc-sun-solaris2.8-strip libcmodel.so \
  -v --strip-unneeded
copy from libcmodel.so(elf32-sparc) to stCGYfYS(elf32-sparc)

...and test again with 2.16...

$ sparc-sun-solaris2.9-strip libcmodel.so -v --strip-unneeded
copy from `libcmodel.so' [elf32-sparc] to `stopZxTe' [elf32-sparc]
BFD: stopZxTe: warning: allocated section `.bss' not in segment

library stripped by 2.15 doesn't contain some information:

--- libcmodel.so.orig.txt       2006-05-09 11:10:37.000000000 +0200
+++ libcmodel.so.txt    2006-05-09 11:22:22.000000000 +0200
@@ -1,6 +1,6 @@

-libcmodel.so.orig:     file format elf32-sparc
-libcmodel.so.orig
+libcmodel.so:     file format elf32-sparc
+libcmodel.so
 architecture: sparc, flags 0x00000150:
 HAS_SYMS, DYNAMIC, D_PAGED
 start address 0x00000094
@@ -8,10 +8,10 @@
 Program Header:
     LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
          filesz 0x000504e9 memsz 0x000504e9 flags r-x
-    LOAD off    0x000504ec vaddr 0x000604ec paddr 0x00000000 align 2**16
+    LOAD off    0x000504ec vaddr 0x000604ec paddr 0x000604ec align 2**16
          filesz 0x000020f8 memsz 0x000020f8 flags rwx
- DYNAMIC off    0x00051748 vaddr 0x00061748 paddr 0x00000000 align 2**0
-         filesz 0x000000e0 memsz 0x00000000 flags rwx
+ DYNAMIC off    0x00051748 vaddr 0x00061748 paddr 0x00061748 align 2**2
+         filesz 0x000000e0 memsz 0x000000e0 flags rwx

 Dynamic Section:
   NEEDED      libCstd.so.1
@@ -42,15 +42,6 @@
   FLAGS_1     0x8000
   PLTGOT      0x60a6c

-Version References:
-  required from libCstd.so.1:
-    0x0d279a21 0x02 00 SUNW_1.1.1
-    0x0a3d2791 0x00 00 SUNW_1.1
-  required from libCrun.so.1:
-    0x0a3d2791 0x00 00 SUNW_1.1
-  required from libdl.so.1:
-    0x077a74f3 0x00 00 SISCD_2.3
-
 Sections:
 Idx Name          Size      VMA       LMA       File off  Algn
   0 .hash         000014f0  00000094  00000094  00000094  2**2
@@ -97,7 +88,7 @@
                   CONTENTS, ALLOC, LOAD, DATA
  21 .bss          00000000  000625e4  000625e4  000525e4  2**0
                   ALLOC
- 22 .comment      0000002c  00000000  00000000  000526d5  2**0
+ 22 .comment      0000002c  00000000  00000000  000525e4  2**0
                   CONTENTS, READONLY
 SYMBOL TABLE:
 no symbols
Comment 7 Stephen Pope 2006-05-09 19:39:43 UTC
I have just run into what I believe is the same problem. It appears to be due to
a new version of the Sun ld (/usr/ccs/bin/ld) which was installed recently on
our Solaris8 systems as part of trying to patch up the Sun ONE Studio 8 and Sun
Studio 10 compiler suites. Sun's ld will happily recognize the shared objects
produced by the new ld, but binutil 2.16 (and 2.16.1)'s bfd library will not.

Further investigation showed that the shared library in question was the only
one in our codebase with this problem, and it happens to be the only shared
library in our codebase in which the source files (i.e. *.o object files going
in) were compiled with the Sun C compiler), but the shared library was created
using the Sun C++ driver (i.e. CC -G ...). Furthermore, the problem occurs
because /usr/ccs/bin/ld is invoked with the option
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1, which
contains exception handling support. Invoking the equivalent /usr/ccs/bin/ld
command minus that command line option, the resulting library is handled without
problem by binutils.

The workaround for us has been to create the shared library using cc -G instead
of CC -G in the case where there are no C++ sources in the shared library.

I should emphasize that /usr/ccs/bin/ld is perfectly happy with the resulting
shared objects no matter how they were created.

Here's a few more details:

% ls -l /usr/ccs/bin/ld
-rwxr-xr-x  1 root bin 7824 Oct 27  2005 /usr/ccs/bin/ld*
% cksum /usr/ccs/bin/ld
3259439703 7824 /usr/ccs/bin/ld

% ls -l /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
-rwxrwxr-x  1 root sys 12320 Mar 13  2003
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1*
% cksum /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
4099598650 12320 /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1

And an example which will reproduce the problem (assuming you have the right
versions of Sun stuff...)

First create a simple object for a shared lib:

% cat bug.c
int foo()
{
   return 1;
}
% cc -KPIC -c bug.c

Make a shared library using the cc driver

% cc -# -G -o libbug.so.cc bug.o
### Note: NLSPATH =
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
###     command line files and options (expanded):
### -G bug.o -o libbug.so.cc
### Note: LD_LIBRARY_PATH = /home/scp/lib
### Note: LD_RUN_PATH = <null>
/usr/ccs/bin/ld /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crti.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/values-xa.o -o libbug.so.cc -G
bug.o -Y
"P,/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib" -Qy
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crtn.o

Check and see that binutils likes the file

% /usr/local/pkg/binutils-2.16.1/bin/nm libbug.so.cc
000102e8 b Bbss.bss
...


Now do the same using the CC (C++) driver. First a dryrun to see the ld command,
and then the real command.

% CC -dryrun -G -o libbug.so.CC bug.o
###     command line files and options (expanded):
### -dryrun -G -o libbug.so.CC bug.o -xcode=pic13 
### CC: Note: NLSPATH =
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### CC: Note: LD_LIBRARY_PATH = /home/scp/lib
### CC: Note: LD_RUN_PATH     = (null)
### CC: Note: LD_OPTIONS = (null)
/usr/ccs/bin/ld
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libCCexcept.so.1
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libCCexcept.so.1
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libldstab_ws.so
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libldstab_ws.so -dy
-G
-R/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib
-o libbug.so.CC /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crti.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrti.o bug.o -Y
P,/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrtn.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crtn.o >&/tmp/ld.24218.0.err
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/c++filt -filt=no%stdlib
</tmp/ld.24218.0.err >>/tmp/c++filt.24218.1.err
rm /tmp/ld.24218.0.err
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/bin/stdlibfilt -stderr
</tmp/c++filt.24218.1.err
rm /tmp/c++filt.24218.1.err

% CC -G -o libbug.so.CC bug.o

And now check that binutils doesn't like this shared object

% /usr/local/pkg/binutils-2.16.1/bin/nm libbug.so.CC
/usr/local/pkg/binutils-2.16.1/bin/nm: libbug.so.CC: File format not recognized


Finally, cut and paste from dryrun above, removing the
-zld32=-S.../libCCexcept.so.1 ...

% /usr/ccs/bin/ld
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libCCexcept.so.1
-zld32=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/libldstab_ws.so
-zld64=-S/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/v9/libldstab_ws.so -dy
-G
-R/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib
-o libbug.so.ld /usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crti.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrti.o bug.o -Y
P,/usr/local/pkg/SunONEStudio8/SUNWspro/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/lib:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/rw7:/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/CCrtn.o
/usr/local/pkg/SunONEStudio8/SUNWspro/prod/lib/crtn.o

And this time binutils likes it

% /usr/local/pkg/binutils-2.16.1/bin/nm libbug.so.ld
000106f0 b Bbss.bss
...

I will attach the three different shared objects, in the event that some
maintainer has access to an appropriate Solaris/Sparc system and can determine
what the issue is.

Hope that helps.
Comment 8 Stephen Pope 2006-05-09 19:45:45 UTC
Created attachment 1013 [details]
libbug.so.cc from example in previous comment
Comment 9 Stephen Pope 2006-05-09 19:46:46 UTC
Created attachment 1014 [details]
libbug.so.CC from previous example
Comment 10 Stephen Pope 2006-05-09 19:47:49 UTC
Created attachment 1015 [details]
libbug.so.ld from previous example
Comment 11 Nick Clifton 2006-05-10 12:23:19 UTC
Subject: Re:  linker doesn't recognize an ELF library.

Hi Pawel,

> I will attach the three different shared objects, in the event that some
> maintainer has access to an appropriate Solaris/Sparc system and can determine
> what the issue is.

Thanks.  That has allowed me to locate the problem.  The libbug.so.CC 
file has a section named .exception_ranges which has an link value of 
0xFF00.  Normally the link value should be a valid index into the 
section table in the ELF binary, and the BFD library was detecting this 
discrepancy and treating the file as invalid.  The bug however was that 
certain other special values are allowed in the index field.  Namely 
values in the range of SHN_LOPROC (0xFF00) to SHN_HIOS (0xFF3F).

So please could you try out the uploaded patch which I hope will correct 
the problem.  It certainly works for me using libbug.so.CC file that you 
supplied.

Cheers
   Nick

bfd/ChangeLog
2006-05-10  Nick Clifton  <nickc@redhat.com>

	PR ld/2607
	* elfcode.h (valid_section_index_p): New function: Checks for a
	valid section index.  Allows indicies in the range SHN_LOPROC to
	SHN_HIOS.
	(elf_object_p): Use valid_section_index_p.

Comment 12 Nick Clifton 2006-05-10 12:24:56 UTC
Created attachment 1016 [details]
Fix determination of valid section indicies
Comment 13 Pawel Sikora 2006-05-10 13:49:23 UTC
(In reply to comment #12)
> Created an attachment (id=1016)
> Fix determination of valid section indicies

works for me :)
Comment 14 Stephen Pope 2006-05-10 22:26:26 UTC
Nick,

That patch, applied against the 2.16.1 release source (with a little syntactic
fudge by hand on the last hunk) seems to do the trick perfectly.

Thank you!

(I'll leave it to you or others to change the status of the this bug.
Comment 15 Stephen Pope 2006-05-10 22:27:35 UTC
Uh, duh, I should point out that it solves my problem. I cannot speak for Pawel...
Comment 16 Pawel Sikora 2006-05-10 22:31:32 UTC
patch fixes all testcases.
Comment 17 Nick Clifton 2006-05-11 09:04:10 UTC
Subject: Re:  linker doesn't recognize an ELF library.

Hi Pawel,

 > pluto at agmk dot net wrote:
> works for me :)

Excellent - I have applied the patch to the mainline and the 2.17 branch 
as well.

Cheers
   Nick