More Adventures in Linking

Hello Again,

I am still having some significant linking problems and can’t quite seem
to resolve them.

I have a number of libraries that i am trying to statically link into a
QNX Filter driver (shared object). I have linked these libraries in the
following way:

I compiled the source library files into object files with the “-shared”
compiler flag set. I then created archives using the “ar -r” command.
This produces a “.a” file that i attempt to statically link into my
filter. The link succeeds and all of the symbols are present in the .so
file, but io-net crashes when i attempt to load the driver (never even
calls my init function).

For some additional investigation, i tried to compile all of these
libraries into static libraries and link them into an executable. In
this case i used the -static flag when compiling the libraries, and the
-static flag when linking the executable. The executable builds
correctly, but “cores” when i try to run it.

I feel that i am missing something when it comes to linking libraries
statically on QNX. These are libraries and executables that build and
link correctly on Linux as well as Solaris.

If anyone has any insight into my problem, i would greatly appreciate
it.

Steven Erickson <sojg@mediaone.net> wrote:

Hello Again,

I am still having some significant linking problems and can’t quite seem
to resolve them.

Here is a sample compile line from a devn driver I have that has a support
library built as a shared archive.

qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -DNDEBUG -shared
-DVARIANT_a -DVARIANT_shared hcf.c

and the archiving line…

ntox86-ar -r libhcfS.a hcf.o hcfio.o


Perhaps this will shed some light on your situation.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I have the executables building and linking properly, but i’m still having
some trouble with my filter. The problem with the executables was that one of
my libs is using exception handling, and i needed to turn that on in the
linker. I am trying to link in the libraries one by one into my filter, and
seem to be having difficulty with the same lib that uses exception handling. I
am building the lib with the -lang-c++ LD flag set. I am also setting this
flag when building my filter. Is exception handling allowed for filter
drivers?

Another possible problem could be the crypto lib i am using from SSL. I built
a “-shared” version of the lib manually, so i’m not absolutely positive that
it was built correctly.

Thanks for your continued help.

Steve/

Chris McKillop wrote:

Steven Erickson <> sojg@mediaone.net> > wrote:

Hello Again,

I am still having some significant linking problems and can’t quite seem
to resolve them.


Here is a sample compile line from a devn driver I have that has a support
library built as a shared archive.

qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -DNDEBUG -shared
-DVARIANT_a -DVARIANT_shared hcf.c

and the archiving line…

ntox86-ar -r libhcfS.a hcf.o hcfio.o

Perhaps this will shed some light on your situation.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

I think -lang-c++ is not what you should pass to the linker. The linker sees
only the -l and assumes it should link against lib’ang-c++’.so. And it gives
no error message since all symbols are properly resolved. But the target
contains a reference to that imaginary library. Try without this linker
option.

Exception handling should work fine because the compiler-library ‘libgcc’,
which contains all builtin functions as well as the RTTI- and exception
code, is by default built as static library and linked-in automatically
(‘gcc -print-libgcc-file-name’ gives the full path to that library).
Generating RTTI- and exception-aware code during compile is also by default
turned on, thus no additional flags sre required.

Peter

“Steven Erickson” <sojg@mediaone.net> schrieb im Newsbeitrag
news:3B39D015.D04AA0D2@mediaone.net

I have the executables building and linking properly, but i’m still having
some trouble with my filter. The problem with the executables was that one
of
my libs is using exception handling, and i needed to turn that on in the
linker. I am trying to link in the libraries one by one into my filter,
and
seem to be having difficulty with the same lib that uses exception
handling. I
am building the lib with the -lang-c++ LD flag set. I am also setting this
flag when building my filter. Is exception handling allowed for filter
drivers?

Another possible problem could be the crypto lib i am using from SSL. I
built
a “-shared” version of the lib manually, so i’m not absolutely positive
that
it was built correctly.

Thanks for your continued help.

Steve/

Chris McKillop wrote:

Steven Erickson <> sojg@mediaone.net> > wrote:

Hello Again,

I am still having some significant linking problems and can’t quite
seem
to resolve them.


Here is a sample compile line from a devn driver I have that has a
support
library built as a shared archive.

qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -DNDEBUG -shared

-DVARIANT_a -DVARIANT_shared hcf.c

and the archiving line…

ntox86-ar -r libhcfS.a hcf.o hcfio.o

Perhaps this will shed some light on your situation.

chris




cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

qcc recognises -lang-c++ as an option, and will link in the C++ library
and the libgcc.a that contains the exception handling code.

I think -lang-c++ is not what you should pass to the linker. The linker sees
only the -l and assumes it should link against lib’ang-c++’.so. And it gives
no error message since all symbols are properly resolved. But the target
contains a reference to that imaginary library. Try without this linker
option.

Exception handling should work fine because the compiler-library ‘libgcc’,
which contains all builtin functions as well as the RTTI- and exception
code, is by default built as static library and linked-in automatically
(‘gcc -print-libgcc-file-name’ gives the full path to that library).
Generating RTTI- and exception-aware code during compile is also by default
turned on, thus no additional flags sre required.

Peter

“Steven Erickson” <> sojg@mediaone.net> > schrieb im Newsbeitrag
news:> 3B39D015.D04AA0D2@mediaone.net> …
I have the executables building and linking properly, but i’m still having
some trouble with my filter. The problem with the executables was that one
of
my libs is using exception handling, and i needed to turn that on in the
linker. I am trying to link in the libraries one by one into my filter,
and
seem to be having difficulty with the same lib that uses exception
handling. I
am building the lib with the -lang-c++ LD flag set. I am also setting this
flag when building my filter. Is exception handling allowed for filter
drivers?

Another possible problem could be the crypto lib i am using from SSL. I
built
a “-shared” version of the lib manually, so i’m not absolutely positive
that
it was built correctly.

Thanks for your continued help.

Steve/

Chris McKillop wrote:

Steven Erickson <> sojg@mediaone.net> > wrote:

Hello Again,

I am still having some significant linking problems and can’t quite
seem
to resolve them.


Here is a sample compile line from a devn driver I have that has a
support
library built as a shared archive.

qcc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -DNDEBUG -shared

-DVARIANT_a -DVARIANT_shared hcf.c

and the archiving line…

ntox86-ar -r libhcfS.a hcf.o hcfio.o

Perhaps this will shed some light on your situation.

chris




cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
\


cburgess@qnx.com

Yes, that’s true. I’m sorry. I was not aware that the linker is called
through qcc rather than directly in the QNX buildfile environment. I always
used my own Makefiles and passed only -shared to the linker, and it worked
with exception handling and RTTI, though I never used the C++ standard lib.

“Colin Burgess” <cburgess@qnx.com> schrieb im Newsbeitrag
news:9hq722$na$4@nntp.qnx.com

qcc recognises -lang-c++ as an option, and will link in the C++ library
and the libgcc.a that contains the exception handling code.

I think -lang-c++ is not what you should pass to the linker. The linker
sees
only the -l and assumes it should link against lib’ang-c++’.so. And it
gives
no error message since all symbols are properly resolved. But the target
contains a reference to that imaginary library. Try without this linker
option.

Exception handling should work fine because the compiler-library
‘libgcc’,
which contains all builtin functions as well as the RTTI- and exception
code, is by default built as static library and linked-in automatically
(‘gcc -print-libgcc-file-name’ gives the full path to that library).
Generating RTTI- and exception-aware code during compile is also by
default
turned on, thus no additional flags sre required.

Peter

“Steven Erickson” <> sojg@mediaone.net> > schrieb im Newsbeitrag
news:> 3B39D015.D04AA0D2@mediaone.net> …
I have the executables building and linking properly, but i’m still
having
some trouble with my filter. The problem with the executables was that
one
of
my libs is using exception handling, and i needed to turn that on in
the
linker. I am trying to link in the libraries one by one into my filter,
and
seem to be having difficulty with the same lib that uses exception
handling. I
am building the lib with the -lang-c++ LD flag set. I am also setting
this
flag when building my filter. Is exception handling allowed for filter
drivers?

Another possible problem could be the crypto lib i am using from SSL. I
built
a “-shared” version of the lib manually, so i’m not absolutely positive
that
it was built correctly.

Thanks for your continued help.

Steve/

Chris McKillop wrote:

Steven Erickson <> sojg@mediaone.net> > wrote:

Hello Again,

I am still having some significant linking problems and can’t quite
seem
to resolve them.


Here is a sample compile line from a devn driver I have that has a
support
library built as a shared archive.


cc -Vgcc_ntox86 -c -Wc,-Wall -Wc,-Wno-parentheses -O -DNDEBUG -shared

-DVARIANT_a -DVARIANT_shared hcf.c

and the archiving line…

ntox86-ar -r libhcfS.a hcf.o hcfio.o

Perhaps this will shed some light on your situation.

chris





cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL






\

cburgess@qnx.com