Selection of shared libs at runtime

I have written a serial char-io driver that is expected to be released
shortly. The current executable is linked to the Dinkum libraries. I
have found that if one attempts to use the driver on the NC version of
QNX6, it can’t find libcpp.so.2a.

Do I have to supply two different runtimes - one for dinkum and one for
GCC and let a user decide which one works? This doesn’t seem right to
me. Is GCC the lowest common denomiator? Preferably I would like one
executable that doesn’t care what the runtime environment is. The fact
that it was developed on an SE or PE system with dinkum libraries should
not preclude anyone from running it. How will this affect pure runtime
instalolations of QNX6 (that is, non-development systems)?

Am I off the mark here? How can I distribute one only executable and
have it run on any type of QNX6 system?

Thanks,

Geoff.

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

“Geoff” <geoff@rtts.com.au> wrote in message
news:3E1CA4DF.DB6B90AF@rtts.com.au

I have written a serial char-io driver that is expected to be released
shortly. The current executable is linked to the Dinkum libraries. I
have found that if one attempts to use the driver on the NC version of
QNX6, it can’t find libcpp.so.2a.

Do I have to supply two different runtimes - one for dinkum and one for
GCC and let a user decide which one works? This doesn’t seem right to
me. Is GCC the lowest common denomiator? Preferably I would like one
executable that doesn’t care what the runtime environment is. The fact
that it was developed on an SE or PE system with dinkum libraries should
not preclude anyone from running it. How will this affect pure runtime
instalolations of QNX6 (that is, non-development systems)?

Am I off the mark here? How can I distribute one only executable and
have it run on any type of QNX6 system?

I found this in another group. It carries a hint at least - create a
symlink for
libcpp.so.2a. It also implies that GCC is the lowest common denominator,
so your problem is probably solved by linking to the GCC libs, so long as
you
can stand the license terms.


Otto Mixa <ottomixa@email.cz> wrote:

Is the Dinkum libraries which wasn’t released in NC also possible reason
of
some unsatisfied packages?Because in those packages are dependencies on
some
required libraries and I can’t find them.

Possibly, if the app is C++ and wasn’t linked with the GNU libs. You can
just
symlink libcpp.so.2 to libcpp.so.2a and tell the installer to ignore the
dependancy.

Hello Geoff,

I’ll try to answer your questions.

“Geoff” <geoff@rtts.com.au> wrote in message
news:3E1CA4DF.DB6B90AF@rtts.com.au

I have written a serial char-io driver that is expected to be released
shortly. The current executable is linked to the Dinkum libraries. I
have found that if one attempts to use the driver on the NC version of
QNX6, it can’t find libcpp.so.2a.

Yes that is correct, the NC version doesn’t contain the Dinkum runtimes.

Do I have to supply two different runtimes - one for dinkum and one for
GCC and let a user decide which one works? This doesn’t seem right to
me. Is GCC the lowest common denomiator? Preferably I would like one
executable that doesn’t care what the runtime environment is. The fact
that it was developed on an SE or PE system with dinkum libraries should
not preclude anyone from running it. How will this affect pure runtime
instalolations of QNX6 (that is, non-development systems)?

Do you mean supplying two different binaries to run on NC and SE/PE?
The NC is free and it doesn’t have all the support that SE/PE have, hence
there
is no Dinkum C++ support. If you develop your app on SE or PE with Dinkum
libs,
it will allow you to run with SE or PE, but not on NC (GCC x86 only). If
you
develop your driver on NC (GCC x86 only) it will run fine on all three
versions.
The only full support we have with GCC C++ and Dinkum libraries is for x86
target,
any other targets relay on Dinkum C++ libs. Under PE and SE the common
denomiator
is full C++ Dinkum lib.

Am I off the mark here? How can I distribute one only executable and
have it run on any type of QNX6 system?

If it is on x86 you can link your program with GCC C++ to have it working on
all
three versions NC, SE and PE editions. The qcc -V will show you all
supported
target and libs.
Another solution would be to have two version one using Dinkum and
one using GCC libs. (the choice is yours).

Regards,

Marcin

Thanks,

Geoff.

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: > geoff@rtts.com.au

What is the situation then if someone purchases a pure QNX6 runtime (ie,
not NC, not SE, and not PE) with no libraries at all (as it seems is the
case)? Am I allowed to distribute the Dinkum shared libs that my driver
is now dependent on to work? Also, if I choose to allow someone with who
only has NC to run my driver or app, am I allowed to let them also have
the shared libraries? I imagine so as had I statically linked, they’d be
there anyway. Just “hidden” in the app itself.

I don’t want to link to the GCC libs and I don’t want to inadvertantly
violate any license conditions. As a developer, need I concern myself
with what a customer has (NC or otherwise)? Actually, I can’t imagine
many end-users of this driver app having any development environment
shipping with their products…

BTW, x86 is the only platform of concern here.

Geoff.

Marcin Dzieciol wrote:

Hello Geoff,

I’ll try to answer your questions.

“Geoff” <> geoff@rtts.com.au> > wrote in message
news:> 3E1CA4DF.DB6B90AF@rtts.com.au> …
I have written a serial char-io driver that is expected to be released
shortly. The current executable is linked to the Dinkum libraries. I
have found that if one attempts to use the driver on the NC version of
QNX6, it can’t find libcpp.so.2a.

Yes that is correct, the NC version doesn’t contain the Dinkum runtimes.


Do I have to supply two different runtimes - one for dinkum and one for
GCC and let a user decide which one works? This doesn’t seem right to
me. Is GCC the lowest common denomiator? Preferably I would like one
executable that doesn’t care what the runtime environment is. The fact
that it was developed on an SE or PE system with dinkum libraries should
not preclude anyone from running it. How will this affect pure runtime
instalolations of QNX6 (that is, non-development systems)?

Do you mean supplying two different binaries to run on NC and SE/PE?
The NC is free and it doesn’t have all the support that SE/PE have, hence
there
is no Dinkum C++ support. If you develop your app on SE or PE with Dinkum
libs,
it will allow you to run with SE or PE, but not on NC (GCC x86 only). If
you
develop your driver on NC (GCC x86 only) it will run fine on all three
versions.
The only full support we have with GCC C++ and Dinkum libraries is for x86
target,
any other targets relay on Dinkum C++ libs. Under PE and SE the common
denomiator
is full C++ Dinkum lib.


Am I off the mark here? How can I distribute one only executable and
have it run on any type of QNX6 system?

If it is on x86 you can link your program with GCC C++ to have it working on
all
three versions NC, SE and PE editions. The qcc -V will show you all
supported
target and libs.
Another solution would be to have two version one using Dinkum and
one using GCC libs. (the choice is yours).

Regards,

Marcin


Thanks,

Geoff.

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: > geoff@rtts.com.au

Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA

Phone: 61-2-6291 3833
Fax: 61-2-6291 3838
Mobile: 0413 634 667
Email: geoff@rtts.com.au

Yes that is correct, the NC version doesn’t contain the Dinkum runtimes.

Only because we messed up and didn’t ship them. The dinkum runtimes are
to be included with 6.2.1 NC. However, there are no Dinkum development
libs, headers, configs, etc, etc. So, if you are making a C++ library
you will need to either make two versions or only support libstdc++ from
the GNU libs.

chris


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

Chris McKillop <cdm@qnx.com> wrote:

Yes that is correct, the NC version doesn’t contain the Dinkum runtimes.


Only because we messed up and didn’t ship them. The dinkum runtimes are
to be included with 6.2.1 NC. However, there are no Dinkum development
libs, headers, configs, etc, etc. So, if you are making a C++ library
you will need to either make two versions or only support libstdc++ from
the GNU libs.

Also, we did ship one version of the Dinkum libs with NC, libcpp.so.2,
but the updated build of the libs, libcpp.so.2a, was missed in the NC
shiplist. This actually caused some included applications to fail
(phplay when playing back mpeg video files).

chris


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