Switching between Dinkum and GNU libraries on 6.1.0A

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
#1

I was wondering if anyone knew how to switch between the 6.0 libraries (GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database. The
problem is, I have been experiencing problems with the serial card drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I was no
longer able to compile my programs as the Empress libraries were compiled on
the 6.0 platform and they do not distribute the source. Now, I contacted
Empress and they told me that they would be producing a new release on QNX
6.1 within the next few months. I can’t wait that long. Either I have to
fall back to 6.0C or I have to figure out a way to revert back to the GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command line.
Being one never afraid to use a sledgehammer to fix a problem, I took the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions, which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
<raeberhardt@tantalus-systems.com>
<www.tantalus-systems.com>

#2

Put the 6.1 libc on a 6.0 system for now, so you can run your
new serial drivers.

Add libc.so.2 and a proc symlink (/usr/lib/ldqnx.so.2 → …/…/lib/libc.so.2)
to your boot image, and the 6.1 serial stuff should run.

Randy Aeberhardt <raeberhardt@tantalus-systems.com> wrote:

I was wondering if anyone knew how to switch between the 6.0 libraries (GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database. The
problem is, I have been experiencing problems with the serial card drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I was no
longer able to compile my programs as the Empress libraries were compiled on
the 6.0 platform and they do not distribute the source. Now, I contacted
Empress and they told me that they would be producing a new release on QNX
6.1 within the next few months. I can’t wait that long. Either I have to
fall back to 6.0C or I have to figure out a way to revert back to the GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command line.
Being one never afraid to use a sledgehammer to fix a problem, I took the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions, which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
raeberhardt@tantalus-systems.com
www.tantalus-systems.com

–
cburgess@qnx.com

#3

Thanks Colin, but I was hoping to move forward, rather than backwards.

Are you saying there is no way that I can compile my programs on a 6.1
platform, using the Empress libraries which were compiled on a 6.0 platform?
If so, then I will simply abandon 6.1 and revert to 6.0C until Empress comes
out with a new release. The problem with the serial port was not solved by
going to 6.1 anyways (I tested the 6.0C executables on the 6.1A platform
with the same results). I will generate a separate post for the peculiar
readcond() behaviour once I have verified the results.

Randy Aeberhardt
<raeberhardt@tantalus-systems.com>
<www.tantalus-systems.com>


“Colin Burgess” <cburgess@qnx.com> wrote in message
news:9qn917$8d6$2@nntp.qnx.com…

Put the 6.1 libc on a 6.0 system for now, so you can run your
new serial drivers.

Add libc.so.2 and a proc symlink (/usr/lib/ldqnx.so.2 -
…/…/lib/libc.so.2)
to your boot image, and the 6.1 serial stuff should run.

Randy Aeberhardt <> raeberhardt@tantalus-systems.com> > wrote:
I was wondering if anyone knew how to switch between the 6.0 libraries
(GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database.
The
problem is, I have been experiencing problems with the serial card
drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I
was no
longer able to compile my programs as the Empress libraries were
compiled on
the 6.0 platform and they do not distribute the source. Now, I
contacted
Empress and they told me that they would be producing a new release on
QNX
6.1 within the next few months. I can’t wait that long. Either I have
to
fall back to 6.0C or I have to figure out a way to revert back to the
GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command
line.
Being one never afraid to use a sledgehammer to fix a problem, I took
the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I
read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions,
which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
raeberhardt@tantalus-systems.com
www.tantalus-systems.com



\

cburgess@qnx.com

#4

I was trying to link an executable that included some shared libs which were
6.0 and had some problems as well. The solution that Colin pointed me
toward was to include these lines in the Makefile when I link my app.

-Wl,–dynamic-linker=/usr/lib/ldqnx.so.1 /lib/libc.so.1

I think this forces the app to use only the libc.so.1 Maybe this is
helpful…

–
Jerry Kirk
Nexware Corp. (http://www.nexwarecorp.com)
Software Development for the Embedded World
865.546.9998 x203


“Randy Aeberhardt” <raeberhardt@tantalus-systems.com> wrote in message
news:9qn8j4$8co$1@nntp.qnx.com…

I was wondering if anyone knew how to switch between the 6.0 libraries
(GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database.
The
problem is, I have been experiencing problems with the serial card drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I was
no
longer able to compile my programs as the Empress libraries were compiled
on
the 6.0 platform and they do not distribute the source. Now, I contacted
Empress and they told me that they would be producing a new release on QNX
6.1 within the next few months. I can’t wait that long. Either I have to
fall back to 6.0C or I have to figure out a way to revert back to the GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command
line.
Being one never afraid to use a sledgehammer to fix a problem, I took the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I
read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions,
which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
raeberhardt@tantalus-systems.com
www.tantalus-systems.com

#5

Thanks Jerry,

I reverted to the original 6.1A library setup and tried your suggestion.
The -W1 switch does not work with “ld”. I already had the “–dynamic-linker”
and “/usr/lib/ldqnx.so.1” entries. I added “/lib/libc.so.1” and the
“-lbessel” and was able to compile and link. I now get the following linker
warning:

“ld: warning: libc.so.2, needed by /x86/lib/libbessel.so, may conflict with
libc.so.1”

This makes sense as the bessel library was added as part of 6.1 and
therefore would require libc.so.2. I wonder what kind of problems I can run
into with this warning. I ran a standalone program which accesses the
database and it appears to work just fine. I need to do some further
testing, but it appears that I may have a solution here. Thank you.

For anyone interested (especially those using Empress), my makefile now
reads as follows (please note that my empress home directory is
/home/empress):

PROC=empesql
PROCFLAGS= -ptr

CC=gcc
CCFLAGS= -c -ansi -g -O0 -I/home/empress/include

AR=ar
ARFLAGS=

LINK=ld
LINKFLAGS1= -b elf32-i386 --dynamic-linker /usr/lib/ldqnx.so.1
/lib/libc.so.1 /x86/lib/crt1.o
/x86/lib/crti.o /x86/lib/crtbegin.o -E
LINKFLAGS2= -Bstatic /home/empress/rdbms/lib/globmain.a -Bdynamic
-lbessel -lms -lmscfg -lbasic -lbasic_os -lnlscstab -lnlsmsgtab -lm -lsock
et -lrpc
/usr/lib/gcc-lib/ntox86/2.95.2/libgcc.a -lc -dn -Bstatic -lc
/x86/lib/crtend.o /x86/lib/crtn.o

LIBRARIES= -L/x86/usr/lib -L/x86/lib -L/usr/lib/gcc-lib/ntox86/2.95.2
-L/usr/ntox86/lib -L/home/empress/shlib

OBJECTS= test.o

…SUFFIXES: .pc .c .o

…pc.c:
$(PROC) $(PROCFLAGS) $.pc $.c

…c.o:
$(CC) $(CCFLAGS) $*.c

test: $(OBJECTS)
$(LINK) $(LINKFLAGS1) $(OBJECTS) $(LINKFLAGS2) $(LIBRARIES) -o $@

Note that the above makefile is quite cumbersome, as it attempts to create a
linker command that emulates that generated by Empress’ empecc utility (this
utility is provided by Empress and invokes the standard compiler and linker
using its libraries).


“Jerry Kirk” <Jerry.Kirk@Nexwarecorp.com> wrote in message
news:9qnao1$qi0$1@inn.qnx.com…

I was trying to link an executable that included some shared libs which
were
6.0 and had some problems as well. The solution that Colin pointed me
toward was to include these lines in the Makefile when I link my app.

-Wl,–dynamic-linker=/usr/lib/ldqnx.so.1 /lib/libc.so.1

I think this forces the app to use only the libc.so.1 Maybe this is
helpful…

–
Jerry Kirk
Nexware Corp. (> http://www.nexwarecorp.com> )
Software Development for the Embedded World
865.546.9998 x203


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9qn8j4$8co$> 1@nntp.qnx.com> …
I was wondering if anyone knew how to switch between the 6.0 libraries
(GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database.
The
problem is, I have been experiencing problems with the serial card
drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I
was
no
longer able to compile my programs as the Empress libraries were
compiled
on
the 6.0 platform and they do not distribute the source. Now, I
contacted
Empress and they told me that they would be producing a new release on
QNX
6.1 within the next few months. I can’t wait that long. Either I have
to
fall back to 6.0C or I have to figure out a way to revert back to the
GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command
line.
Being one never afraid to use a sledgehammer to fix a problem, I took
the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I
read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions,
which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
raeberhardt@tantalus-systems.com
www.tantalus-systems.com

\

#6

That’s a -Wl (l, as in larry)

You can compile apps targetting 6.0 (with a little setup), but you
can’t mix objects/libs from 6.0 and 6.1


Randy Aeberhardt <raeberhardt@tantalus-systems.com> wrote:

Thanks Jerry,

I reverted to the original 6.1A library setup and tried your suggestion.
The -W1 switch does not work with “ld”. I already had the “–dynamic-linker”
and “/usr/lib/ldqnx.so.1” entries. I added “/lib/libc.so.1” and the
“-lbessel” and was able to compile and link. I now get the following linker
warning:

“ld: warning: libc.so.2, needed by /x86/lib/libbessel.so, may conflict with
libc.so.1”

This makes sense as the bessel library was added as part of 6.1 and
therefore would require libc.so.2. I wonder what kind of problems I can run
into with this warning. I ran a standalone program which accesses the
database and it appears to work just fine. I need to do some further
testing, but it appears that I may have a solution here. Thank you.

For anyone interested (especially those using Empress), my makefile now
reads as follows (please note that my empress home directory is
/home/empress):

PROC=empesql
PROCFLAGS= -ptr

CC=gcc
CCFLAGS= -c -ansi -g -O0 -I/home/empress/include

AR=ar
ARFLAGS=

LINK=ld
LINKFLAGS1= -b elf32-i386 --dynamic-linker /usr/lib/ldqnx.so.1
/lib/libc.so.1 /x86/lib/crt1.o
/x86/lib/crti.o /x86/lib/crtbegin.o -E
LINKFLAGS2= -Bstatic /home/empress/rdbms/lib/globmain.a -Bdynamic
-lbessel -lms -lmscfg -lbasic -lbasic_os -lnlscstab -lnlsmsgtab -lm -lsock
et -lrpc
/usr/lib/gcc-lib/ntox86/2.95.2/libgcc.a -lc -dn -Bstatic -lc
/x86/lib/crtend.o /x86/lib/crtn.o

LIBRARIES= -L/x86/usr/lib -L/x86/lib -L/usr/lib/gcc-lib/ntox86/2.95.2
-L/usr/ntox86/lib -L/home/empress/shlib

OBJECTS= test.o

.SUFFIXES: .pc .c .o

.pc.c:
$(PROC) $(PROCFLAGS) $.pc $.c

.c.o:
$(CC) $(CCFLAGS) $*.c

test: $(OBJECTS)
$(LINK) $(LINKFLAGS1) $(OBJECTS) $(LINKFLAGS2) $(LIBRARIES) -o $@

Note that the above makefile is quite cumbersome, as it attempts to create a
linker command that emulates that generated by Empress’ empecc utility (this
utility is provided by Empress and invokes the standard compiler and linker
using its libraries).



“Jerry Kirk” <> Jerry.Kirk@Nexwarecorp.com> > wrote in message
news:9qnao1$qi0$> 1@inn.qnx.com> …
I was trying to link an executable that included some shared libs which
were
6.0 and had some problems as well. The solution that Colin pointed me
toward was to include these lines in the Makefile when I link my app.

-Wl,–dynamic-linker=/usr/lib/ldqnx.so.1 /lib/libc.so.1

I think this forces the app to use only the libc.so.1 Maybe this is
helpful…

–
Jerry Kirk
Nexware Corp. (> http://www.nexwarecorp.com> )
Software Development for the Embedded World
865.546.9998 x203


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9qn8j4$8co$> 1@nntp.qnx.com> …
I was wondering if anyone knew how to switch between the 6.0 libraries
(GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database.
The
problem is, I have been experiencing problems with the serial card
drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I
was
no
longer able to compile my programs as the Empress libraries were
compiled
on
the 6.0 platform and they do not distribute the source. Now, I
contacted
Empress and they told me that they would be producing a new release on
QNX
6.1 within the next few months. I can’t wait that long. Either I have
to
fall back to 6.0C or I have to figure out a way to revert back to the
GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command
line.
Being one never afraid to use a sledgehammer to fix a problem, I took
the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I
read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions,
which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
raeberhardt@tantalus-systems.com
www.tantalus-systems.com


\

–
cburgess@qnx.com

#7

Super User <root@qnx.com> wrote:

That’s a -Wl (l, as in larry)

You can compile apps targetting 6.0 (with a little setup), but you
can’t mix objects/libs from 6.0 and 6.1

Sorry about posting as root. That was me (Colin)


Randy Aeberhardt <> raeberhardt@tantalus-systems.com> > wrote:
Thanks Jerry,

I reverted to the original 6.1A library setup and tried your suggestion.
The -W1 switch does not work with “ld”. I already had the “–dynamic-linker”
and “/usr/lib/ldqnx.so.1” entries. I added “/lib/libc.so.1” and the
“-lbessel” and was able to compile and link. I now get the following linker
warning:

“ld: warning: libc.so.2, needed by /x86/lib/libbessel.so, may conflict with
libc.so.1”

This makes sense as the bessel library was added as part of 6.1 and
therefore would require libc.so.2. I wonder what kind of problems I can run
into with this warning. I ran a standalone program which accesses the
database and it appears to work just fine. I need to do some further
testing, but it appears that I may have a solution here. Thank you.

For anyone interested (especially those using Empress), my makefile now
reads as follows (please note that my empress home directory is
/home/empress):

PROC=empesql
PROCFLAGS= -ptr

CC=gcc
CCFLAGS= -c -ansi -g -O0 -I/home/empress/include

AR=ar
ARFLAGS=

LINK=ld
LINKFLAGS1= -b elf32-i386 --dynamic-linker /usr/lib/ldqnx.so.1
/lib/libc.so.1 /x86/lib/crt1.o
/x86/lib/crti.o /x86/lib/crtbegin.o -E
LINKFLAGS2= -Bstatic /home/empress/rdbms/lib/globmain.a -Bdynamic
-lbessel -lms -lmscfg -lbasic -lbasic_os -lnlscstab -lnlsmsgtab -lm -lsock
et -lrpc
/usr/lib/gcc-lib/ntox86/2.95.2/libgcc.a -lc -dn -Bstatic -lc
/x86/lib/crtend.o /x86/lib/crtn.o

LIBRARIES= -L/x86/usr/lib -L/x86/lib -L/usr/lib/gcc-lib/ntox86/2.95.2
-L/usr/ntox86/lib -L/home/empress/shlib

OBJECTS= test.o

.SUFFIXES: .pc .c .o

.pc.c:
$(PROC) $(PROCFLAGS) $.pc $.c

.c.o:
$(CC) $(CCFLAGS) $*.c

test: $(OBJECTS)
$(LINK) $(LINKFLAGS1) $(OBJECTS) $(LINKFLAGS2) $(LIBRARIES) -o $@

Note that the above makefile is quite cumbersome, as it attempts to create a
linker command that emulates that generated by Empress’ empecc utility (this
utility is provided by Empress and invokes the standard compiler and linker
using its libraries).



“Jerry Kirk” <> Jerry.Kirk@Nexwarecorp.com> > wrote in message
news:9qnao1$qi0$> 1@inn.qnx.com> …
I was trying to link an executable that included some shared libs which
were
6.0 and had some problems as well. The solution that Colin pointed me
toward was to include these lines in the Makefile when I link my app.

-Wl,–dynamic-linker=/usr/lib/ldqnx.so.1 /lib/libc.so.1

I think this forces the app to use only the libc.so.1 Maybe this is
helpful…

–
Jerry Kirk
Nexware Corp. (> http://www.nexwarecorp.com> )
Software Development for the Embedded World
865.546.9998 x203


“Randy Aeberhardt” <> raeberhardt@tantalus-systems.com> > wrote in message
news:9qn8j4$8co$> 1@nntp.qnx.com> …
I was wondering if anyone knew how to switch between the 6.0 libraries
(GNU,
I believe) and the 6.1 Dinkum libraries. I am a commercial developer
targeting an application for QNX using the Empress relational database.
The
problem is, I have been experiencing problems with the serial card
drivers
and I was told to upgrade to 6.1 by QNX. However, after upgrading, I
was
no
longer able to compile my programs as the Empress libraries were
compiled
on
the 6.0 platform and they do not distribute the source. Now, I
contacted
Empress and they told me that they would be producing a new release on
QNX
6.1 within the next few months. I can’t wait that long. Either I have
to
fall back to 6.0C or I have to figure out a way to revert back to the
GNU
libraries on 6.1.

Initially, when I compile, I get the following unresolved references:

/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
j1' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to y0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
yn' /home/empress/Empress/v8.60.beta/shlib/libms.so: undefined reference to _multi_threaded’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
jn' /home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference to j0’
/home/empress/Empress/v8.60.beta/shlib/libmscfg.so: undefined reference
to
`y1’

I was informed that the `_multi_threaded’ reference is in libc.so.1, as
opposed to libc.so.2 which is automatically linked in from the command
line.
Being one never afraid to use a sledgehammer to fix a problem, I took
the
brute force method and executed the following commands in an attempt to
unlink the Dinkum libraries and revert to the GNU libraries:

cd \lib
unlink libasound.so
ln -sf libasound.so.1 libasound.so
unlink libc.so
ln -sf libc.so.1 libc.so
unlink libcam.so
ln -sf libcam.so.1 libcam.so
unlink libm.so
ln -sf libm.so.1 libm.so
unlink libsocket.so
ln -sf libsocket.so.1 libsocket.so

Nothing really changed, I still had the unresolved references. Next, I
read
on QNXstart.com (a really good source of information besides this
newsgroup), that some of the unresolved references are math functions,
which
are located in the bessel library. So I added “-lbessel” to my linker
command and now I get the following unresolved references:

/x86/lib/libbessel.so: undefined reference to _FLog' /x86/lib/libbessel.so: undefined reference to sqrtf’
/x86/lib/libbessel.so: undefined reference to _FSin' /home/empress/shlib/libms.so: undefined reference to _multi_threaded’

Can anyone help?

Randy Aeberhardt
raeberhardt@tantalus-systems.com
www.tantalus-systems.com


\



–
cburgess@qnx.com

–
cburgess@qnx.com