which libraries to link

LiuG3 · January 4, 2002, 6:49pm

If I have two libraries with the same name, which one will the linker pick?

QNX6 comes with /usr/lib/libGL.so and libGLU.so
when I compile xfree86 (which also comes with the libGL.so and libGLU.so),

…
making all in programs/glxinfo…
make[4]: Entering directory /src/xc/programs/glxinfo' gcc -O2 -I../.. -I../../exports/include -DNO_REGEX -DSTRINGS_ALIGNED -D_POSIX_SOURCE -D_QNX_SOURCE -D__i386__ -D__ELF__ -D__QNXNTO__ -D_i386 -DFUNCPROTO=15 -DNARROWPROTO -c -o glxinfo.o glxinfo.c rm -f glxinfo gcc -o glxinfo -O2 -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/opt/X11R6/lib -lm -lsocket /usr/ntox86/bin/ld: warning: libm.so.1, needed by /x86/usr/lib/libGLU.so, may conflict with libm.so.2 /usr/ntox86/bin/ld: warning: libc.so.1, needed by /x86/usr/lib/libGLU.so, may conflict with libc.so.2 /usr/ntox86/bin/ld: warning: libph.so.1, needed by /usr/lib/libphrenderGL.so.1, not found (try using -rpath or -rpath-link) /usr/ntox86/bin/ld: warning: libphrender.so.1, needed by /usr/lib/libphrenderGL.so.1, not found (try using -rpath or -rpath-link) glxinfo.o: In function print_screen_info’:
glxinfo.o(.text+0x160): undefined reference to glXChooseVisual' glxinfo.o(.text+0x17a): undefined reference to glXChooseVisual’
glxinfo.o(.text+0x1f4): undefined reference to glXCreateContext' glxinfo.o(.text+0x23f): undefined reference to glXMakeCurrent’
glxinfo.o(.text+0x259): undefined reference to glXQueryServerString' glxinfo.o(.text+0x26e): undefined reference to glXQueryServerString’
glxinfo.o(.text+0x286): undefined reference to glXQueryServerString' glxinfo.o(.text+0x297): undefined reference to glXGetClientString’
glxinfo.o(.text+0x2ab): undefined reference to glXGetClientString' glxinfo.o(.text+0x2bc): undefined reference to glXGetClientString’
glxinfo.o(.text+0x2d2): undefined reference to glXQueryExtensionsString' glxinfo.o(.text+0x3fb): undefined reference to glXIsDirect’
glxinfo.o(.text+0x585): undefined reference to glXDestroyContext' glxinfo.o: In function get_visual_attribs’:
glxinfo.o(.text+0x653): undefined reference to glXQueryExtensionsString' glxinfo.o(.text+0x6ab): undefined reference to glXGetConfig’
glxinfo.o(.text+0x6c6): undefined reference to glXGetConfig' glxinfo.o(.text+0x6d6): undefined reference to glXGetConfig’
glxinfo.o(.text+0x6e9): undefined reference to glXGetConfig' glxinfo.o(.text+0x6f9): undefined reference to glXGetConfig’
glxinfo.o(.text+0x70c): more undefined references to glXGetConfig' follow glxinfo.o: In function mesa_hack’:
glxinfo.o(.text+0xc51): undefined reference to glXChooseVisual' /x86/usr/lib/libGL.so: undefined reference to PgShmemCreate’
/x86/usr/lib/libGL.so: undefined reference to PhDCInit' /x86/usr/lib/libGL.so: undefined reference to PgGetVideoModeList’
/x86/usr/lib/libGL.so: undefined reference to _Ph_' /x86/usr/lib/libGL.so: undefined reference to PgGetVideoModeInfo’
/x86/usr/lib/libGL.so: undefined reference to PgGetGraphicsHWCaps' /usr/lib/libglide2x.so: undefined reference to PdDirectStart’
/usr/lib/libglide2x.so: undefined reference to PdReleaseDirectContext' /usr/lib/libglide2x.so: undefined reference to PgWaitHWIdle’
/x86/usr/lib/libGL.so: undefined reference to PgDrawPhImagemx' /x86/usr/lib/libGL.so: undefined reference to PgShmemDestroy’
/usr/lib/libglide2x.so: undefined reference to PhDCGetCurrent' /x86/usr/lib/libGL.so: undefined reference to PgSetVideoMode’
/x86/usr/lib/libGL.so: undefined reference to PgFlush' /usr/lib/libglide2x.so: undefined reference to PdCreateDirectContext’
/usr/lib/libglide2x.so: undefined reference to PhDCGetType' collect2: ld returned 1 exit status make[4]: *** [glxinfo] Error 1 make[4]: Target all’ not remade because of errors.
…

Now the question is I already have the libGLU.so and libGL.so in
…/…/exports/lib, how come the linker doesn’t use -L…/…/exports/lib
as specified in the command line? why would it pick the WRONG
libGLU.so and libGL.so from the system /usr/lib directory?

Now instead of
gcc -o glxinfo -O2 -L…/…/exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/opt/X11R6/lib -lm -lsocket
If I force the link to link my libraries, it will work fine:
gcc -o glxinfo -O2 -L…/…/exports/lib glxinfo.o …/…/exports/lib/libGLU.so …/…/exports/lib/libGL.so -lXext -lX11 -L/opt/X11R6/lib -lm -lsocket

Any ideas?

Frank

Tools_Mail_Account · January 4, 2002, 8:59pm

LiuG <liug@mama.indstate.edu> wrote:

Hello,

If I have two libraries with the same name, which one will the linker pick?

Whatever path is resolved first.

QNX6 comes with /usr/lib/libGL.so and libGLU.so
when I compile xfree86 (which also comes with the libGL.so and libGLU.so),

…
making all in programs/glxinfo…
make[4]: Entering directory /src/xc/programs/glxinfo' gcc -O2 -I../.. -I../../exports/include -DNO_REGEX -DSTRINGS_ALIGNED -D_POSIX_SOURCE -D_QNX_SOURCE -D__i386__ -D__ELF__ -D__QNXNTO__ -D_i386 -DFUNCPROTO=15 -DNARROWPROTO -c -o glxinfo.o glxinfo.c rm -f glxinfo gcc -o glxinfo -O2 -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/opt/X11R6/lib -lm -lsocket /usr/ntox86/bin/ld: warning: libm.so.1, needed by /x86/usr/lib/libGLU.so, may conflict with libm.so.2 /usr/ntox86/bin/ld: warning: libc.so.1, needed by /x86/usr/lib/libGLU.so, may conflict with libc.so.2 /usr/ntox86/bin/ld: warning: libph.so.1, needed by /usr/lib/libphrenderGL.so.1, not found (try using -rpath or -rpath-link) /usr/ntox86/bin/ld: warning: libphrender.so.1, needed by /usr/lib/libphrenderGL.so.1, not found (try using -rpath or -rpath-link) glxinfo.o: In function print_screen_info’:
glxinfo.o(.text+0x160): undefined reference to glXChooseVisual' glxinfo.o(.text+0x17a): undefined reference to glXChooseVisual’
glxinfo.o(.text+0x1f4): undefined reference to glXCreateContext' glxinfo.o(.text+0x23f): undefined reference to glXMakeCurrent’
glxinfo.o(.text+0x259): undefined reference to glXQueryServerString' glxinfo.o(.text+0x26e): undefined reference to glXQueryServerString’
glxinfo.o(.text+0x286): undefined reference to glXQueryServerString' glxinfo.o(.text+0x297): undefined reference to glXGetClientString’
glxinfo.o(.text+0x2ab): undefined reference to glXGetClientString' glxinfo.o(.text+0x2bc): undefined reference to glXGetClientString’
glxinfo.o(.text+0x2d2): undefined reference to glXQueryExtensionsString' glxinfo.o(.text+0x3fb): undefined reference to glXIsDirect’
glxinfo.o(.text+0x585): undefined reference to glXDestroyContext' glxinfo.o: In function get_visual_attribs’:
glxinfo.o(.text+0x653): undefined reference to glXQueryExtensionsString' glxinfo.o(.text+0x6ab): undefined reference to glXGetConfig’
glxinfo.o(.text+0x6c6): undefined reference to glXGetConfig' glxinfo.o(.text+0x6d6): undefined reference to glXGetConfig’
glxinfo.o(.text+0x6e9): undefined reference to glXGetConfig' glxinfo.o(.text+0x6f9): undefined reference to glXGetConfig’
glxinfo.o(.text+0x70c): more undefined references to glXGetConfig' follow glxinfo.o: In function mesa_hack’:
glxinfo.o(.text+0xc51): undefined reference to glXChooseVisual' /x86/usr/lib/libGL.so: undefined reference to PgShmemCreate’
/x86/usr/lib/libGL.so: undefined reference to PhDCInit' /x86/usr/lib/libGL.so: undefined reference to PgGetVideoModeList’
/x86/usr/lib/libGL.so: undefined reference to _Ph_' /x86/usr/lib/libGL.so: undefined reference to PgGetVideoModeInfo’
/x86/usr/lib/libGL.so: undefined reference to PgGetGraphicsHWCaps' /usr/lib/libglide2x.so: undefined reference to PdDirectStart’
/usr/lib/libglide2x.so: undefined reference to PdReleaseDirectContext' /usr/lib/libglide2x.so: undefined reference to PgWaitHWIdle’
/x86/usr/lib/libGL.so: undefined reference to PgDrawPhImagemx' /x86/usr/lib/libGL.so: undefined reference to PgShmemDestroy’
/usr/lib/libglide2x.so: undefined reference to PhDCGetCurrent' /x86/usr/lib/libGL.so: undefined reference to PgSetVideoMode’
/x86/usr/lib/libGL.so: undefined reference to PgFlush' /usr/lib/libglide2x.so: undefined reference to PdCreateDirectContext’
/usr/lib/libglide2x.so: undefined reference to PhDCGetType' collect2: ld returned 1 exit status make[4]: *** [glxinfo] Error 1 make[4]: Target all’ not remade because of errors.
…

Now the question is I already have the libGLU.so and libGL.so in
…/…/exports/lib, how come the linker doesn’t use -L…/…/exports/lib
as specified in the command line? why would it pick the WRONG
libGLU.so and libGL.so from the system /usr/lib directory?

Since these libs already exist in /usr/lib directory, the -L… is ignored
Try adding you lib path to your LD_LIBRARY_PATH, before /usr/lib, so it would
look something like this /proc/boot:/lib:YOUR_PATH:/usr/lib…and so on

or you can do something like: export LD_LIBRARY_PATH=YOUR_LIB_PATH:$LD_LIBRARY_PATH
that will ensure that your libs are being used.

I hope this helps.

Best Regards,

Marcin

Now instead of
gcc -o glxinfo -O2 -L…/…/exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/opt/X11R6/lib -lm -lsocket
If I force the link to link my libraries, it will work fine:
gcc -o glxinfo -O2 -L…/…/exports/lib glxinfo.o …/…/exports/lib/libGLU.so …/…/exports/lib/libGL.so -lXext -lX11 -L/opt/X11R6/lib -lm -lsocket

Any ideas?

Frank

LiuG3 · January 6, 2002, 12:02am

Tools Mail Account <tools@qnx.com> wrote:

If I have two libraries with the same name, which one will the linker pick?
Whatever path is resolved first.

when you say “path”, do you know the “-L” (the link path), or do
you the runtime patch LD_LIBRARY_PATH ?
it doesn’t make sense why the runtime loader path would affect
the linker, but your reponse at the bottom seems to imply so.

Since these libs already exist in /usr/lib directory, the -L… is ignored
Try adding you lib path to your LD_LIBRARY_PATH, before /usr/lib, so it would
look something like this /proc/boot:/lib:YOUR_PATH:/usr/lib…and so on

or you can do something like: export LD_LIBRARY_PATH=YOUR_LIB_PATH:$LD_LIBRARY_PATH
that will ensure that your libs are being used.

as I mentioned above, this doesn’t make sense.
to prove this, I changed the command from “gcc” to “qcc”, and leave
everything else the same on the command line. now it works! no errors.
i believe there is a bug somewhere. Colin?

frank

Tools_Mail_Account · January 7, 2002, 5:57pm

LiuG <liug@mama.indstate.edu> wrote:

Tools Mail Account <> tools@qnx.com> > wrote:

Hello Frank,

If I have two libraries with the same name, which one will the linker pick?
Whatever path is resolved first.

when you say “path”, do you know the “-L” (the link path), or do
you the runtime patch LD_LIBRARY_PATH ?
it doesn’t make sense why the runtime loader path would affect
the linker, but your reponse at the bottom seems to imply so.

Since these libs already exist in /usr/lib directory, the -L… is ignored
Try adding you lib path to your LD_LIBRARY_PATH, before /usr/lib, so it would
look something like this /proc/boot:/lib:YOUR_PATH:/usr/lib…and so on

or you can do something like: export LD_LIBRARY_PATH=YOUR_LIB_PATH:$LD_LIBRARY_PATH
that will ensure that your libs are being used.

as I mentioned above, this doesn’t make sense.
to prove this, I changed the command from “gcc” to “qcc”, and leave
everything else the same on the command line. now it works! no errors.
i believe there is a bug somewhere. Colin?

Sorry you’re right, I misunderstood the question. After investigating the issue
a little bit more it looks like qcc wrapper add the -L_YOUR_PATH before the
default linker path, I guess it is a feature of it (qcc). With gcc, the linker
will use the default path and then the path you add with -L option.

gcc -v -L/home/marcin hello.c
…
/usr/lib/gcc-lib/ntox86/2.95.2/collect2 -V -Y P,/x86/lib -L /x86/lib -L /x86/usr/lib -Qy -m i386nto --dynamic-lin
ker /usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o /x86/lib/crtbegin.o -L/home/marcin -L/usr/lib/gcc-lib/ntox86/2.95.2 -L/usr/ntox86
/lib /tmp/cccgDMkc.o -lg
cc -lc -dn -Bstatic -lc -lgcc /x86/lib/crtend.o /x86/lib/crtn.o
…

qcc -v -L/home/marcin hello.c
…
/usr/ntox86/bin/ld -b elf32-i386 --dynamic-linker /usr/lib/ldqnx.so.2 /x86/lib/crt1.o /x86/lib/crti.o /x86/lib/crt
begin.o -L/home/marcin
/tmp/AAA017646_cc.o -o a.out -Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2 -L/usr/ntox86/lib /usr/lib/g
cc-lib/ntox86/2.95.2/lib
gcc.a -lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/libgcc.a /x86/lib/crtend.o /x86/lib/crtn.o
…

for more information you can run it with “Wl,-verbose”

Regards,

Marcin

the default search path

frank

LiuG3 · January 7, 2002, 6:33pm

Tools Mail Account <tools@qnx.com> wrote:

Sorry you’re right, I misunderstood the question. After investigating the issue
a little bit more it looks like qcc wrapper add the -L_YOUR_PATH before the
default linker path, I guess it is a feature of it (qcc). With gcc, the linker
will use the default path and then the path you add with -L option.

gcc -v -L/home/marcin hello.c
…
/usr/lib/gcc-lib/ntox86/2.95.2/collect2 -V -Y P,/x86/lib -L /x86/lib -L /x86/usr/lib -Qy -m i386nto --dynamic-lin
ker /usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o /x86/lib/crtbegin.o -L/home/marcin -L/usr/lib/gcc-lib/ntox86/2.95.2 -L/usr/ntox86
/lib /tmp/cccgDMkc.o -lg
cc -lc -dn -Bstatic -lc -lgcc /x86/lib/crtend.o /x86/lib/crtn.o
…

qcc -v -L/home/marcin hello.c
…
/usr/ntox86/bin/ld -b elf32-i386 --dynamic-linker /usr/lib/ldqnx.so.2 /x86/lib/crt1.o /x86/lib/crti.o /x86/lib/crt
begin.o -L/home/marcin
/tmp/AAA017646_cc.o -o a.out -Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2 -L/usr/ntox86/lib /usr/lib/g
cc-lib/ntox86/2.95.2/lib
gcc.a -lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/libgcc.a /x86/lib/crtend.o /x86/lib/crtn.o
…

I will definitely say this is a bug in qnx6’s gcc by adding the system
default lib path ahead of the lib path specified on the command line.
you can try gcc on other OS and you will see.
Is there a quick fix (modifying the “specs” file)?

thanks!
Frank

Tools_Mail_Account · January 7, 2002, 9:03pm

LiuG <liug@mama.indstate.edu> wrote:

Tools Mail Account <> tools@qnx.com> > wrote:
Sorry you’re right, I misunderstood the question. After investigating the issue
a little bit more it looks like qcc wrapper add the -L_YOUR_PATH before the
default linker path, I guess it is a feature of it (qcc). With gcc, the linker
will use the default path and then the path you add with -L option.

gcc -v -L/home/marcin hello.c
…
/usr/lib/gcc-lib/ntox86/2.95.2/collect2 -V -Y P,/x86/lib -L /x86/lib -L /x86/usr/lib -Qy -m i386nto --dynamic-lin
ker /usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o /x86/lib/crtbegin.o -L/home/marcin -L/usr/lib/gcc-lib/ntox86/2.95.2 -L/usr/ntox86
/lib /tmp/cccgDMkc.o -lg
cc -lc -dn -Bstatic -lc -lgcc /x86/lib/crtend.o /x86/lib/crtn.o
…

qcc -v -L/home/marcin hello.c
…
/usr/ntox86/bin/ld -b elf32-i386 --dynamic-linker /usr/lib/ldqnx.so.2 /x86/lib/crt1.o /x86/lib/crti.o /x86/lib/crt
begin.o -L/home/marcin
/tmp/AAA017646_cc.o -o a.out -Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2 -L/usr/ntox86/lib /usr/lib/g
cc-lib/ntox86/2.95.2/lib
gcc.a -lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/libgcc.a /x86/lib/crtend.o /x86/lib/crtn.o
…

I will definitely say this is a bug in qnx6’s gcc by adding the system
default lib path ahead of the lib path specified on the command line.
you can try gcc on other OS and you will see.
Is there a quick fix (modifying the “specs” file)?

Yes, gcc on other OS (Debian) puts the path you specify before the default
lib, therefore we are investigating (specs file) this issue.

Thanks for pointing this out.

Marcin

thanks!
Frank