Qnx 6 for a QNX 4 / Linux guy

Guys

I used to work with QNX 4.2x and Linux. So I’m familiar w/Photon and X
development for GUIs, the gnu toolset (and the old watcom tools), etc.

I am very confused wrt QNX 6.3.0.

Seems some apps are written in X, some are Photon, I can use QNXGL, I can
use MesaGL, etc. Some ppl use the gnu compiler some use the dinkum. Some use
elf etc. What the heck is going on? :slight_smile:

What is the “best practice” considering I my application to be reliable and
it must have a GUI. I would like to use OpenGL as well but it doesn’t seem
to behave on multiple monitor displays.

Is the X in photon server reliable or is it best to stick with a pure photon
app? I need this thing to run 99.9% of the time, that’s why i’m going w/QNX
instead of Windows XP (which has excellent OpenGL support compared to QNX).

Thanks
Nick

Nick C. <qnx@qrts.com> wrote:

Guys

I used to work with QNX 4.2x and Linux. So I’m familiar w/Photon and X
development for GUIs, the gnu toolset (and the old watcom tools), etc.

I am very confused wrt QNX 6.3.0.

Seems some apps are written in X, some are Photon, I can use QNXGL, I can
use MesaGL, etc. Some ppl use the gnu compiler some use the dinkum. Some use
elf etc. What the heck is going on? > :slight_smile:

Most new applications, especially “realtime” or “control” type applications
aren’t usually done in X – it is mostly used for portability purposes.

Everyone uses the GNU compiler – the GNU vs Dinkum is libraries. GNU
libraries are (IIRC) offered x86 only, and primarily, again, for
compatability with existing code that is being ported to QNX. (e.g.
for code in GNU/public applications where they depend on a particular
non-standard behaviour, or extension, in the GNU version of the library,
it can use the GNU libraries.) The default, and what is used by most
people, would be the Dinkum libraries.


What is the “best practice” considering I my application to be reliable and
it must have a GUI. I would like to use OpenGL as well but it doesn’t seem
to behave on multiple monitor displays.

I can’t comment on OpenGL vs Photon – don’t know enough about
OpenGL. (I think it is targeted at high-performance animation
type stuff, though.) It may not be an either-or, it may be
look at what you’re trying to do, and pick one vs the other.

Is the X in photon server reliable or is it best to stick with a pure photon
app? I need this thing to run 99.9% of the time, that’s why i’m going w/QNX
instead of Windows XP (which has excellent OpenGL support compared to QNX).

I would suggest pure Photon over X. As noted, the X in Photon is
primarily for portability and running things on the desktop.

Hope this helps a bit.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

David

Thanks for your kind reply.

Most new applications, especially “realtime” or “control” type
applications
aren’t usually done in X – it is mostly used for portability purposes.

That makes sense.

Everyone uses the GNU compiler – the GNU vs Dinkum is libraries. GNU
libraries are (IIRC) offered x86 only, and primarily, again, for
compatability with existing code that is being ported to QNX. (e.g.
for code in GNU/public applications where they depend on a particular
non-standard behaviour, or extension, in the GNU version of the library,
it can use the GNU libraries.) The default, and what is used by most
people, would be the Dinkum libraries.

What about gcc versions 2.95.3 vs 3.3.1

The reason I ask is there is a section in the helpviewer docs “/A Roadmap to
the QNX Mometics Professional Edition/6.30 and 6.21 Compatibility” that
mentions that the C++ libs and compilers…

libcpp.so.2 is for qnx 6.2.1
libcpp.so.3 is for 6.3.0 (compiled with GCC 2.95.3)
libcpp.so.4 is for 6.3.0 (compiled with GCC 3.3.1)

and I knew 2.95 had issues w/exceptions (I had problems with exceptions
using g++ but QCC -Vgcc_ntox86_cpp has no problems).

I guess it’s just different libs like you say.

I can’t comment on OpenGL vs Photon – don’t know enough about
OpenGL. (I think it is targeted at high-performance animation
type stuff, though.) It may not be an either-or, it may be
look at what you’re trying to do, and pick one vs the other.

There are supposed to be 2 implementations in QNX, Mesa and QNXGL. Both
implement some form of OpenGL (but I couldn’t find glut). The photon based
implementation is what I should use based on your feedback above re: photon
vs X.

I would suggest pure Photon over X. As noted, the X in Photon is
primarily for portability and running things on the desktop.

Hope this helps a bit.

It’s been very helpful. I see all these 3rd party programs and libs etc. and
wonder how well supported and reliable they are under QNX. And I get all
excited :slight_smile: but it looks like really not too much has changed since QNX 4.25,
if you want the reliable real-time apps you go with the QNX provided tools
and APIs. And reliability is why I’m using QNX for this project.

Thanks for your answers.
Nick

Nick C. <qnx@qrts.com> wrote:

NC > It’s been very helpful. I see all these 3rd party programs and libs etc. and
NC > wonder how well supported and reliable they are under QNX. And I get all
NC > excited :slight_smile: but it looks like really not too much has changed since QNX 4.25,
NC > if you want the reliable real-time apps you go with the QNX provided tools
NC > and APIs. And reliability is why I’m using QNX for this project.

NC > Thanks for your answers.
NC > Nick

I agree. The other things are nice is you need compatability.

But if you are developing new software, stick with the QNX native tools
and you won’t go wrong.

Nick C. <qnx@qrts.com> wrote:

David

Everyone uses the GNU compiler – the GNU vs Dinkum is libraries. GNU
libraries are (IIRC) offered x86 only, and primarily, again, for
compatability with existing code that is being ported to QNX. (e.g.
for code in GNU/public applications where they depend on a particular
non-standard behaviour, or extension, in the GNU version of the library,
it can use the GNU libraries.) The default, and what is used by most
people, would be the Dinkum libraries.

What about gcc versions 2.95.3 vs 3.3.1

I was hoping a compiler guy would chime in…but he didn’t so I went
and asked.

2.95.3 has more miles on it than 3.3.1 in a QNX environment. It is
the default, as well.

He said, though, unless you need to continue to build already-well-tested
applications from 6.2.1, which were built with 2.95.3, you should use
3.3.1 instead. It has quite a bit better code generation, moreso in
the non-x86 platforms, especially for SH4. It handles a bunch of C++
stuff better.

The reason I ask is there is a section in the helpviewer docs “/A Roadmap to
the QNX Mometics Professional Edition/6.30 and 6.21 Compatibility” that
mentions that the C++ libs and compilers…

libcpp.so.2 is for qnx 6.2.1
libcpp.so.3 is for 6.3.0 (compiled with GCC 2.95.3)
libcpp.so.4 is for 6.3.0 (compiled with GCC 3.3.1)

and I knew 2.95 had issues w/exceptions (I had problems with exceptions
using g++ but QCC -Vgcc_ntox86_cpp has no problems).

I guess it’s just different libs like you say.

IIRC there was a major change in the GNU C++ ABI between 2.95.3 and
3.3.1, which would be the reason for supplying the two 6.3.0 C++
shared objects.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

David

Thanks for the update.

Sorry if I’m confused again - could you please verify that what you’re
saying is…

  1. There is only one compiler shipped w/QNX 6.3.0.
  2. There are 2 sets of libs (2.95.3 and 3.3.1)
  3. What you are recommending for new code (non-qnx 6.2 compatible) written
    in C++ (esp. w/exceptions) is to run the compiler that is shipped w/QNX
    6.3.0 with the 3.3.1 libs?

Or are there 2 compilers and 2 sets of libes (2.95 and 3.3)?

Thanks
Nick

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:cjkeqg$1lr$3@inn.qnx.com

Nick C. <> qnx@qrts.com> > wrote:
David

Everyone uses the GNU compiler – the GNU vs Dinkum is libraries. GNU
libraries are (IIRC) offered x86 only, and primarily, again, for
compatability with existing code that is being ported to QNX. (e.g.
for code in GNU/public applications where they depend on a particular
non-standard behaviour, or extension, in the GNU version of the
library,
it can use the GNU libraries.) The default, and what is used by most
people, would be the Dinkum libraries.

What about gcc versions 2.95.3 vs 3.3.1

I was hoping a compiler guy would chime in…but he didn’t so I went
and asked.

2.95.3 has more miles on it than 3.3.1 in a QNX environment. It is
the default, as well.

He said, though, unless you need to continue to build already-well-tested
applications from 6.2.1, which were built with 2.95.3, you should use
3.3.1 instead. It has quite a bit better code generation, moreso in
the non-x86 platforms, especially for SH4. It handles a bunch of C++
stuff better.

The reason I ask is there is a section in the helpviewer docs “/A
Roadmap to
the QNX Mometics Professional Edition/6.30 and 6.21 Compatibility” that
mentions that the C++ libs and compilers…

libcpp.so.2 is for qnx 6.2.1
libcpp.so.3 is for 6.3.0 (compiled with GCC 2.95.3)
libcpp.so.4 is for 6.3.0 (compiled with GCC 3.3.1)

and I knew 2.95 had issues w/exceptions (I had problems with exceptions
using g++ but QCC -Vgcc_ntox86_cpp has no problems).

I guess it’s just different libs like you say.

IIRC there was a major change in the GNU C++ ABI between 2.95.3 and
3.3.1, which would be the reason for supplying the two 6.3.0 C++
shared objects.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

Nick C. <qnx@qrts.com> wrote:

David

Thanks for the update.

Sorry if I’m confused again - could you please verify that what you’re
saying is…

  1. There is only one compiler shipped w/QNX 6.3.0.

There are 2 compilers. (Well, really, there are a raft of compilers,
since there is one “compiler” for every host-target pair, for each
“release” of the compiler chain.) But, we ship two revisions of the
GNU Compiler Chain with QNX 6.3.0.

  1. There are 2 sets of libs (2.95.3 and 3.3.1)

Yes, one for each compiler tool chain.

  1. What you are recommending for new code (non-qnx 6.2 compatible) written
    in C++ (esp. w/exceptions) is to run the compiler that is shipped w/QNX
    6.3.0 with the 3.3.1 libs?

I’m recommending using the 3.3.1 compiler with the 3.3.1 libs. If you choose
the 3.3.1 compiler, it will automatically use the 3.3.1 libs.

Or are there 2 compilers and 2 sets of libs (2.95 and 3.3)?

Yes. (Nitpicky… 2 compiler tool chains.)

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

David Gibbs <dagibbs@qnx.com> wrote:

Nick C. <> qnx@qrts.com> > wrote:
David



(Well, really, there are a raft of compilers, since there is one
“compiler” for every host-target pair, for each “release” of the
compiler chain.)

I did a bit of math. 2 tool chain revs * 2 languages * 4 hosts *
7 target platforms = 112 compilers.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

David,

Thanks for the informative replies.

Sounds like I want to run the 3.3.1 compiler with the 3.3.1 library since
I’m working on an all new project under qnx 6.3.0.

So I should do “qcc -V3.3.1,gcc_ntox86 -o myfile myfile.c” to use the 3.3.1
compiler w/the 3.3.1 libs?

Thanks
Nick

Nick C. <qnx@qrts.com> wrote:

David,

Thanks for the informative replies.

Sounds like I want to run the 3.3.1 compiler with the 3.3.1 library since
I’m working on an all new project under qnx 6.3.0.

So I should do “qcc -V3.3.1,gcc_ntox86 -o myfile myfile.c” to use the 3.3.1
compiler w/the 3.3.1 libs?

That looks like the correct incantation to me.

Of course, if you’re looking at a makefile, you need to make sure the
-V option is correctly specified at both the compile stage and at the
link stage. (CFLAGS and LDFLAGS)

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

David Gibbs <dagibbs@qnx.com> wrote:
DG > Nick C. <qnx@qrts.com> wrote:

David,

Thanks for the informative replies.

Sounds like I want to run the 3.3.1 compiler with the 3.3.1 library since
I’m working on an all new project under qnx 6.3.0.

So I should do “qcc -V3.3.1,gcc_ntox86 -o myfile myfile.c” to use the 3.3.1
compiler w/the 3.3.1 libs?

DG > That looks like the correct incantation to me.

DG > Of course, if you’re looking at a makefile, you need to make sure the
DG > -V option is correctly specified at both the compile stage and at the
DG > link stage. (CFLAGS and LDFLAGS)

I believe that you can make that your default compiler and libs.

But I’m sorry, I don’t remember how.

Thanks for the info guys. That clears it up for me.