Newbie help please - trying to build for QNX6
Hi, (New to Boost & bjam - not QNX) I am trying to build the Boost libs for QNX 6.3.0 on both the Windows hosted and QNX hosted development platforms using the gcc tools. What happens if I build out of the box is - Under Windows most of the libraries build, but they have Windows suffixes ".lib" and ".dll" which suggest that the build options are targeting Windows. Under QNX most of the build fails. The principal error seems to be a message "g++: unrecognised option -pthread". I have tried running './configure' but that does not make any difference. If I have interpreted the docs correctly perhaps the version 2 build system would be more appropriate for cross platform builds? Can I specify or detect the host, target and toolset independently? Any help and advice greatly appreciated... Jim Douglas
Jim Douglas wrote:
Hi,
(New to Boost & bjam - not QNX)
I am trying to build the Boost libs for QNX 6.3.0 on both the Windows hosted and QNX hosted development platforms using the gcc tools.
What happens if I build out of the box is -
Under Windows most of the libraries build, but they have Windows suffixes ".lib" and ".dll" which suggest that the build options are targeting Windows.
Under QNX most of the build fails. The principal error seems to be a message "g++: unrecognised option -pthread". I have tried running './configure' but that does not make any difference.
If I have interpreted the docs correctly perhaps the version 2 build system would be more appropriate for cross platform builds? Can I specify or detect the host, target and toolset independently?
Any help and advice greatly appreciated...
1. If you are going to attempt a cross-platform build with BBv1 then you will have to create a new toolset specifically for this. 2. QNX is not one of the platforms Boost supports, i.e. no one builds and tests on it, so you will get build errors even though it uses GCC 3.3.1 and Dinkumware 4.0.2. 3. There are some improvements for QNX in the RC_1_33_0 branch in CVS you will want. Like some code config, build, and bjam changes. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Rene Rivera"
Jim Douglas wrote:
Hi,
(New to Boost & bjam - not QNX)
I am trying to build the Boost libs for QNX 6.3.0 on both the Windows hosted and QNX hosted development platforms using the gcc tools.
[snip]
1. If you are going to attempt a cross-platform build with BBv1 then you will have to create a new toolset specifically for this.
Not a good idea. What about BBv2? Does it potentially offer a solution?
2. QNX is not one of the platforms Boost supports, i.e. no one builds and tests on it, so you will get build errors even though it uses GCC 3.3.1 and Dinkumware 4.0.2.
Hmm... I might consider offering my services as a QNX tester as there is some good timesaving stuff here and I could get a few other QNX programmers interested.
3. There are some improvements for QNX in the RC_1_33_0 branch in CVS you will want. Like some code config, build, and bjam changes.
I am using version 1.33.0 which I assume supercedes the branch RC_1_33_0 - release candidate I assume? Please correct me if I am wrong. Thanks Jim
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Jim Douglas wrote:
"Rene Rivera"
wrote in message news:433C0E7C.2060106@redshift-software.com... Jim Douglas wrote:
Hi,
(New to Boost & bjam - not QNX)
I am trying to build the Boost libs for QNX 6.3.0 on both the Windows hosted and QNX hosted development platforms using the gcc tools.
[snip]
1. If you are going to attempt a cross-platform build with BBv1 then you will have to create a new toolset specifically for this.
Not a good idea. What about BBv2? Does it potentially offer a solution?
Not immediately, similar changes that got done to BBv1 for supporting QCC would need to go into the BBv2 gcc toolset.
2. QNX is not one of the platforms Boost supports, i.e. no one builds and tests on it, so you will get build errors even though it uses GCC 3.3.1 and Dinkumware 4.0.2.
Hmm... I might consider offering my services as a QNX tester as there is some good timesaving stuff here and I could get a few other QNX programmers interested.
That would be awesome!
3. There are some improvements for QNX in the RC_1_33_0 branch in CVS you will want. Like some code config, build, and bjam changes.
I am using version 1.33.0 which I assume supercedes the branch RC_1_33_0 - release candidate I assume? Please correct me if I am wrong.
You are wrong :-) It's a very badly named branch name. The branch actually represents the ongoing work on the 1.33.x version of Boost, and will become 1.33.1 soon. We really should have picked the better BOOST_1_33 name, but oh well to late now :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Rene Rivera"
Jim Douglas wrote:
"Rene Rivera"
wrote in message news:433C0E7C.2060106@redshift-software.com... Jim Douglas wrote:
Hi,
(New to Boost & bjam - not QNX)
I am trying to build the Boost libs for QNX 6.3.0 on both the Windows hosted and QNX hosted development platforms using the gcc tools.
[snip]
1. If you are going to attempt a cross-platform build with BBv1 then you will have to create a new toolset specifically for this.
Not a good idea. What about BBv2? Does it potentially offer a solution?
Not immediately, similar changes that got done to BBv1 for supporting QCC would need to go into the BBv2 gcc toolset.
OK, so I will forget about cross development for now and concentrate on getting the libs to build on the self (QNX)-hosted development system as that is very similar to Linux. The final results can be copied to Windows for incorporation there as required.
2. QNX is not one of the platforms Boost supports, i.e. no one builds and tests on it, so you will get build errors even though it uses GCC 3.3.1 and Dinkumware 4.0.2.
Hmm... I might consider offering my services as a QNX tester as there is some good timesaving stuff here and I could get a few other QNX programmers interested.
That would be awesome!
Let's start off down that path and see how far we get. Given my inexperience it would be useful to have a mentor on hand for a little while until I get up to speed. Please advise how best to proceed.
3. There are some improvements for QNX in the RC_1_33_0 branch in CVS you will want. Like some code config, build, and bjam changes.
I am using version 1.33.0 which I assume supercedes the branch RC_1_33_0 - release candidate I assume? Please correct me if I am wrong.
You are wrong :-) It's a very badly named branch name. The branch actually represents the ongoing work on the 1.33.x version of Boost, and will become 1.33.1 soon. We really should have picked the better BOOST_1_33 name, but oh well to late now :-\
Noted. Jim
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Jim Douglas wrote:
Let's start off down that path and see how far we get. Given my inexperience it would be useful to have a mentor on hand for a little while until I get up to speed. Please advise how best to proceed.
A few things to do: * We have a list for those people who are running, or maintain, regression testing: http://www.boost.org/more/mailing_lists.htm#testing I suggest continuing over there, but some other initial comments for now... * There's a short set of instructions on running regression tests at: http://engineering.meta-comm.com/regression_setup/instructions.html It requires having Python 2.3 at least. Mike's QNX repository has a Python 2.4 build... http://mike.qnx.org.ru/qopencd/ * Make sure to test the RC_1_33_0 branch as the mainline doesn't have the minimal QNX support changes. I haven't merged them back into the trunk yet. * On that branch there's a "qcc-tools.jam" BBv1 toolset file which you can use instead of the regular gcc toolset. All it does is specify to use "QCC" or "qcc" instead of "g++" and "gcc" for the commands. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Rene Rivera"
Jim Douglas wrote:
Let's start off down that path and see how far we get. Given my inexperience it would be useful to have a mentor on hand for a little while until I get up to speed. Please advise how best to proceed.
A few things to do:
* We have a list for those people who are running, or maintain, regression testing:
http://www.boost.org/more/mailing_lists.htm#testing
I suggest continuing over there, but some other initial comments for now...
I will make my next posting there in a few days time after I have installed the regression test software and done some serious reading.
* There's a short set of instructions on running regression tests at:
http://engineering.meta-comm.com/regression_setup/instructions.html
It requires having Python 2.3 at least. Mike's QNX repository has a Python 2.4 build...
Ha! Comrade Gorchak gets everywhere :-) He is doing a great job porting all those apps to QNX.
* Make sure to test the RC_1_33_0 branch as the mainline doesn't have the minimal QNX support changes. I haven't merged them back into the trunk yet.
I have checked out this branch already. It does seem to be better behaved than release 1.33.0, but is a long way from perfect. Where did the motivation for QNX support come from? Are you tasked to implement it?
* On that branch there's a "qcc-tools.jam" BBv1 toolset file which you can use instead of the regular gcc toolset. All it does is specify to use "QCC" or "qcc" instead of "g++" and "gcc" for the commands.
Hmmm. QCC/qcc are not staight substitutes for g++/gcc. Some of the parameters are the same, but many e.g -W require a 'pass-through' prefix. It can get messy... I'll take a close look. Regards Jim
Jim Douglas wrote:
I have checked out this branch already. It does seem to be better behaved than release 1.33.0, but is a long way from perfect.
But at least it's past the initial everything breaks stage :-) And at minimum the iostreams library compiles (but without the bzip support).
Where did the motivation for QNX support come from? Are you tasked to implement it?
I was working on it for a short time but the commercial motivation ran out :-(
Hmmm. QCC/qcc are not staight substitutes for g++/gcc. Some of the parameters are the same, but many e.g -W require a 'pass-through' prefix. It can get messy... I'll take a close look.
OK. There where also some changes to the gcc toolset itself. But I guess there may be others needed depending on the type of build. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
participants (2)
-
Jim Douglas
-
Rene Rivera