Want to migrate from QNX 6.00 to 6.21. Any pratfalls?

In another thread in this forum (NFS Server files missing) I posted the version of QNX we are using which was:

QNX localhost 6.00 2000/10/17 -14:59:25edt x86pc x86

It was quickly pointed out that this is more than 3 years old and we would be well served by upgrading.

Well after talking to my boss and to our QNX rep I’ve gotten the OK to take on a side project of upgrading one machine to 6.21 and testing out our S/W to see if it works.

So before I begin this process I searched around on this forum but didn’t find anything about doing such a migration. I was told that the C++ libraries have changed to the Dinkum ones. Other than that, what else has changed and what pratfalls should I be on the look out for when I attempt to compile and run under 6.21.

Our product is a medical device and as such we have no GUI so changes there are not an issue. We are currently using the GNU compiler and libraries under 6.00. We interface to a Windows box in addition to the hardware that we talk to.

TIA,

Tim

I don’t think there is an upgrade path, so first you will have to install a fresh 6.2.1 and then try to run your old apps. The binaries should be backward compatible assuming they are all dynamically linked.

Since you have the source, it is mostly just a matter of recompile. Post back if you have problems :slight_smile:

OK. I’v gotten a 6.21 CD installed on a machine and now uname -a gives me an output of:

QNX qnx 6.2.1 2003/05/17-02:28:40edt x86pc x86

I looked at our current make files and under 6.00 we are using g++ to do all our C++ compilation.

I transferred over the files to the 6.2.1 machine and tried to do just a ‘make’ to see if everything compiled.

It got about 1/3 of the way through the files when it errored out due to an error of trying to find a file called fp.h. On 6.00 this was located in usr/include and the title at the top says something about ‘Floating Point Functions’. I found what looks to be an equivalent file called float.h under 6.2.1 and made the change but it still doesn’t compile because I am now unable find the definition for FP_NAN (which is set equal to 1) which was in fp.h. I did not see an equivalent definition in float.h.

Anyone know why fp.h no longer exists and what I should change the define of FP_NAN to under 6.2.1?

On another note regarding compilers. We are using g++. If this works for us is there a real pressing reason to move to qcc (ie g++ will soon no longer exist) and if I do switch to qcc what kinds of issues can I expect to see compilation wise (ie is it a lot of work).

TIA

Tim

It should be defined in math.h
I think QNX screwed up in 6.2.1, and this will be fixed in the upcoming 6.3

OK. I’v gotten a 6.21 CD installed on a machine and now uname -a gives me an output of:

QNX qnx 6.2.1 2003/05/17-02:28:40edt x86pc x86

I looked at our current make files and under 6.00 we are using g++ to do all our C++ compilation.

I transferred over the files to the 6.2.1 machine and tried to do just a ‘make’ to see if everything compiled.

It got about 1/3 of the way through the files when it errored out due to an error of trying to find a file called fp.h. On 6.00 this was located in usr/include and the title at the top says something about ‘Floating Point Functions’. I found what looks to be an equivalent file called float.h under 6.2.1 and made the change but it still doesn’t compile because I am now unable find the definition for FP_NAN (which is set equal to 1) which was in fp.h. I did not see an equivalent definition in float.h.

Anyone know why fp.h no longer exists and what I should change the define of FP_NAN to under 6.2.1?

On another note regarding compilers. We are using g++. If this works for us is there a real pressing reason to move to qcc (ie g++ will soon no longer exist) and if I do switch to qcc what kinds of issues can I expect to see compilation wise (ie is it a lot of work).

TIA

Tim

So far there is only one compiler available and it’s GCC. In a nutshell qcc/cc/gcc/g++ are front end that passed different default option to gcc.

Really? Are you sure? From the command line:

which -l qcc - 35016 May 17 2003 /usr/bin/qcc
which -l g++ - 64460 May 17 2003 /usr/bin/g++

Then there’s the issue of libraries used by g++ and qcc which I understand are different.

On top of that g++ compiles my code without any problems once I made local defines for FP_NAN in my source files that were using it. Meanwhile qcc halts fairly quickly spewing all kinds of messages about the C++ code using non standard C++ implementations in some of the class definitions.

So right now I am leaving my compiler as g++ and testing out that drivers and the like still work under 6.2.1. Once I’ve determined that they do, I may find time later to go back and try to get everything to compile using qcc.

Tim

What’s your point? These are WAY to small to be compilers :wink:

Yes, the front end will supply different compiler and linker option to gcc, specifying different libraries.

As well as librairies each qcc, gc++ specify different header (to match the library) there are gcc libraries/header and the Dinkum librairies/header(for some reason I can’t memorize the exact name)

Run qcc -V (or maybe -v) that will show you all the possible combinaison of headers/librairies (with 6.2.1 there are a bunch). With 6.3.0 there are even more :wink:

Trust me on this one there is only one compiler :wink:

  • Mario