Re: Woody: What's the proper name of the C++ lib?
Hi Colin!
On Thu, 19 Sep 2002, Colin Watson wrote:
> [...]
> I was assuming that it was possible to trigger the error with a single
> file.
I did some further investigation and it is finally possible for me to
reproduce the error with only two C++ file which are however linked
against various static and shared libs. Moreover, I added
"-Wl,--verbose" to the CFLAGS to get verbose output from the linker. The
call for linking the program is as follows (you can ignore the
"-D" flags; they are only used to disable some parts in the sources):
g++ -Wall -DNOT_ARCHIV_ASYNC -DNOT_BATCH_SERVER -DNOT_EXT_SERVER
-DNOT_DOCUMENT_SERVER -DNOT_ADMIN_SERVER -DNOT_CONFIG_SERVER
-DNOT_CLIENT_SERVER -DNOT_CONVERT_SERVER -Wl,--verbose -g -o
debug/SaraAppS debug/SARAAppServer.o debug/SARABaseServer.o
-L../servframe/ -lservframe -L../saradb/lib/ -lsaradbD -L../transsrv/
-lsocklib -L../servframe/wrapper -lstuff -lncurses -lpthread
Of these libs, the following are static ones (.a files):
- servframe
- saradbD
- socklib
- stuff
The others (ncurses, pthread) are shared ones:
>From ld's verbose output I conclude that these libs are found
(unsuccessful tries to look for the corresponding lib omitted in
order to keep the output as concise as possible).
[...]
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/usr/i386-linux/lib);
[...]
attempt to open /usr/lib/crt1.o succeeded
/usr/lib/crt1.o
attempt to open /usr/lib/crti.o succeeded
/usr/lib/crti.o
attempt to open /usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o succeeded
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o
attempt to open debug/SARAAppServer.o succeeded
debug/SARAAppServer.o
attempt to open debug/SARABaseServer.o succeeded
debug/SARABaseServer.o
[<failures for libservframe omitted>]
attempt to open ../servframe//libservframe.a succeeded
[...]
[<failures for libsaradbD omitted>]
attempt to open ../servframe//libservframe.a succeeded
[<failures for libsocklib omitted>]
attempt to open ../transsrv//libsocklib.a succeeded
[<failures for libstuff omitted>]
attempt to open ../servframe/wrapper/libstuff.a succeeded
[<failures for libncurses omitted>]
attempt to open /usr/lib/libncurses.so succeeded
-lncurses (/usr/lib/libncurses.so)
[<failures for libpthread omitted>]
attempt to open /usr/lib/libpthread.so succeeded
-lpthread (/usr/lib/libpthread.so)
[<failures for libstdc++ omitted>]
attempt to open /usr/lib/gcc-lib/i386-linux/2.95.4/libstdc++.so succeeded
-lstdc++ (/usr/lib/gcc-lib/i386-linux/2.95.4/libstdc++.so)
[<failures for libm omitted>]
attempt to open /usr/lib/libm.so succeeded
-lm (/usr/lib/libm.so)
[<failures for libgcc omitted>]
attempt to open /usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a succeeded
(/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a)_eprintf.o
(/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a)_pure.o
Now comes the interesting part ;-)
When trying the various paths to find libc, in the middle of the failures,
the error message is printed. Strangely enough, the linker seems to
continue to open all required libs (and even finds them!) before it exits:
[<unsuccessful tries to look for libc skipped>]
attempt to open ../servframe//libc.so failed
attempt to open ../servframe//libc.a failed
attempt to open ../saradb/lib//libc.so failed
attempt to open ../saradb/lib//libc.a failed
attempt to open ../transsrv//libc.so failed
attempt to open ../transsrv//libc.a failed
attempt to open ../servframe/wrapper/libc/usr/bin/ld: BFD 2.12.90.0.1
20020307 Debian/GNU Linux internal error, aborting at
../../bfd/elf32-i386.c line 1887 in elf_i386_relocate_section
/usr/bin/ld: Please report this bug.
.so failed
[<other failures to look for libc omitted>]
opened script file /usr/lib/libc.so
attempt to open /lib/libc.so.6 succeeded
/lib/libc.so.6
attempt to open /usr/lib/libc_nonshared.a succeeded
(/usr/lib/libc_nonshared.a)atexit.oS
[<failures to look for libgcc omitted>]
attempt to open /usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a succeeded
attempt to open /usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o succeeded
/usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o
attempt to open /usr/lib/crtn.o succeeded
/usr/lib/crtn.o
ld-linux.so.2 needed by /lib/libc.so.6
found ld-linux.so.2 at /lib/ld-linux.so.2
collect2: ld returned 1 exit status
make: *** [debug/SaraAppS.exe] Error 1
Is it perhaps the order of the libs that is wrong? I didn't run
"ranlib" on the static libs. Could it be possible that this makes a
difference?
Now I'm not sure how to report this bug and which information to
supply. Is is better to
a) contact the maintainer directly
b) use the Debian bug tracking system
In case it's b) which information should I include? Just the two
preprocessed C++ files and the verbose output of the linker or also the
static libs?
Thanks in advance for any advice!
Kind regards,
Holger
Reply to: