This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
"BFD 2.13.2.1 assertion fail" on Solaris
- From: Dimitri Papadopoulos-Orfanos <papadopo at shfj dot cea dot fr>
- To: binutils at sources dot redhat dot com
- Date: Tue, 27 May 2003 17:05:28 +0200
- Subject: "BFD 2.13.2.1 assertion fail" on Solaris
Hi,
I get GNU ld assertion failures when linking with libGLU from Sun OpenGL
1.3 on Solaris 8.
To reproduce the problem on a machine with Sun OpenGL 1.3 installed:
$ cat > foo.c
#include <GL/glu.h>
void foo()
{
gluCheckExtension(0, 0);
}
$
$ gcc -shared foo.c \
-I/usr/openwin/include -L/usr/openwin/lib -lGLU
/usr/local/binutils/bin/ld: BFD 2.13.2.1 assertion fail elf32-sparc.c:1490
/usr/local/binutils/bin/ld: BFD 2.13.2.1 assertion fail elf32-sparc.c:1764
$
Linking with Sun OpenGL 1.2.3 or earlier works just fine. The problem
happens only with Sun OpenGL 1.3.
What are the differences between libGLU from Sun OpenGL 1.2.3 and libGLU
from Sun OpenGL 1.3?
On a machine with Sun OpenGL 1.2.3 installed:
$ /usr/ccs/bin/nm /usr/openwin/lib/libGLU.so | fgrep '|1 '
[2] | 148| 0|SECT |LOCL |0 |1 |
[102] | 0| 0|OBJT |LOCL |0 |1 |_START_
$
On a machine with Sun OpenGL 1.3 installed:
$ /usr/ccs/bin/nm /usr/openwin/lib/libGLU.so | fgrep '|1 '
[2] | 148| 0|SECT |LOCL |0 |1 |
[1833] | 673804| 0|OBJT |GLOB |1 |14 |_GLOBAL_OFFSET_TABLE_
[102] | 0| 0|OBJT |LOCL |0 |1 |_START_
[1939] | 602172| 192|FUNC |GLOB |1 |11 |gluCheckExtension
[1885] | 589708| 4728|FUNC |GLOB |1 |11 |gluPartialDisk
[1893] | 400764| 788|FUNC |GLOB |1 |11 |gluTessEndPolygon
$
As you can see the "Other" field is set to 1 for 3 functions of the Sun
OpenGL 1.3 libGLU library. The 'nm' manual page reads:
A field reserved for future use, currently containing 0.
See:
http://docs.sun.com/db/doc/816-0210/6m6nb7mg9?a=view#OUTPUT
So there is a problem with Sun OpenGL 1.3 here. The "Other" field is set
to 1 although it should be set to 0 according to the Sun manuals.
That said, the Sun linker is able to link libGLU, and GNU ld should fail
in such cases. There are libraries with the "Other" field set on
Solaris, whether we want it or not, we have to live with it?
Has anyone any more clues about it? Will this bug report be taken into
account, or should I rather send it to the bug-binutils list?
Regards,
--
Dimitri Papadopoulos