|
Mario Charest
09/04/2008 4:51 PM
post12881
|
I'm trying to use the IDE part of the Alpha release, on Windows. The project is of C++ type. Our makefiles specify gcc3
.3.5 but when trying to build the project from within the IDE I get:
Compiling: shm_pretrait.c
cc: unknown target 'gcc_ntox86+debug+profile'
cc: no targets defined in C:/QNX640/host/win32/x86/etc/qcc/gcc/3.3.5!
The same error comes up for every file. What is the proper course of action to solve this problem, aside switching to 4
.2.4 ;-)
Regards,
Mario
|
|
|
|
|
|
Colin Burgess(deleted)
09/04/2008 5:03 PM
post12882
|
I'm pretty sure the problem is that your QNX_TARGET/QNX_HOST are pointing to the 6.4.0 versions - there
is no 3.3.5 in the 6.4.0 distribution
Mario Charest wrote:
> I'm trying to use the IDE part of the Alpha release, on Windows. The project is of C++ type. Our makefiles specify
gcc3.3.5 but when trying to build the project from within the IDE I get:
>
> Compiling: shm_pretrait.c
> cc: unknown target 'gcc_ntox86+debug+profile'
> cc: no targets defined in C:/QNX640/host/win32/x86/etc/qcc/gcc/3.3.5!
>
> The same error comes up for every file. What is the proper course of action to solve this problem, aside switching to
4.2.4 ;-)
>
> Regards,
>
> Mario
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post12881
>
--
cburgess@qnx.com
|
|
|
|
|
|
Mario Charest
09/04/2008 5:41 PM
post12887
|
> I'm pretty sure the problem is that your QNX_TARGET/QNX_HOST are pointing to
> the 6.4.0 versions - there
> is no 3.3.5 in the 6.4.0 distribution
>
Anyway to add 3.3.5 and 2.95.3 to 6.4.0, either self hosted or on Windows.
I guess on windows one could install multiple version of the IDE and somehow manage to set QNX_TARGET/QNX_HOST on a per
project basic (that's going to be ugly).
But on self hosted I don't see how I can do it? I mean from self hosted 6.4.0 I *HAVE* to be able to generate the same
executable I build with 6.3.2.
|
|
|
|
|
|
Alex Chapiro
09/05/2008 9:26 AM
post12913
|
There is no convenient way to do that now. You can copy manually 2.95
and/or 3.35 directories to $(QNX_HOST)/etc/qcc\gcc. However, keep in
mind that it still uses qcc taken from 6.4. Another option is to install
both QNX: 6.3.2 and 6.4, but use only 6.4 IDE (.4.5). Then ]you can
change active configuration using IDE preferences (see QNX page). But to
sort out all the problems you have to update PATH manually to position
correctly $(QNX_HOST)/usr/bin directories and restart IDE. Anyway I
cannot garantee 100% that it works (worked for me in a few cases I
tried it).
Regards,
Alex
Mario Charest wrote:
>> I'm pretty sure the problem is that your QNX_TARGET/QNX_HOST are pointing to
>> the 6.4.0 versions - there
>> is no 3.3.5 in the 6.4.0 distribution
>>
>>
>
> Anyway to add 3.3.5 and 2.95.3 to 6.4.0, either self hosted or on Windows.
>
> I guess on windows one could install multiple version of the IDE and somehow manage to set QNX_TARGET/QNX_HOST on a
per project basic (that's going to be ugly).
>
> But on self hosted I don't see how I can do it? I mean from self hosted 6.4.0 I *HAVE* to be able to generate the
same executable I build with 6.3.2.
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post12887
>
>
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/05/2008 9:34 AM
post12914
|
Alex Chapiro wrote:
> There is no convenient way to do that now. You can copy manually 2.95
> and/or 3.35 directories to $(QNX_HOST)/etc/qcc\gcc. However, keep in
> mind that it still uses qcc taken from 6.4. Another option is to install
> both QNX: 6.3.2 and 6.4, but use only 6.4 IDE (.4.5). Then ]you can
> change active configuration using IDE preferences (see QNX page). But to
> sort out all the problems you have to update PATH manually to position
> correctly $(QNX_HOST)/usr/bin directories and restart IDE. Anyway I
> cannot garantee 100% that it works (worked for me in a few cases I
> tried it).
If he needs to produce identical binaries to 6.3.2, he'd have to use the
both 6.3.2 qnx host and qnx target directories. You won't get
identical binaries if you use 6.3.2 tools and link against 6.4 libraries.
Regards,
Ryan Mansfield
|
|
|
|
|
|
Alex Chapiro
09/05/2008 9:41 AM
post12916
|
Oh, definitely! This is what I meant. This is supported by switching in
preferences.
Ryan Mansfield wrote:
> Alex Chapiro wrote:
>
>> There is no convenient way to do that now. You can copy manually 2.95
>> and/or 3.35 directories to $(QNX_HOST)/etc/qcc\gcc. However, keep in
>> mind that it still uses qcc taken from 6.4. Another option is to install
>> both QNX: 6.3.2 and 6.4, but use only 6.4 IDE (.4.5). Then ]you can
>> change active configuration using IDE preferences (see QNX page). But to
>> sort out all the problems you have to update PATH manually to position
>> correctly $(QNX_HOST)/usr/bin directories and restart IDE. Anyway I
>> cannot garantee 100% that it works (worked for me in a few cases I
>> tried it).
>>
>
> If he needs to produce identical binaries to 6.3.2, he'd have to use the
> both 6.3.2 qnx host and qnx target directories. You won't get
> identical binaries if you use 6.3.2 tools and link against 6.4 libraries.
>
> Regards,
>
> Ryan Mansfield
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post12914
>
>
|
|
|
|
|
|
Mario Charest
09/05/2008 10:54 AM
post12932
|
> Oh, definitely! This is what I meant. This is supported by switching in
> preferences.
>
> Ryan Mansfield wrote:
> > Alex Chapiro wrote:
> >
> >> There is no convenient way to do that now. You can copy manually 2.95
> >> and/or 3.35 directories to $(QNX_HOST)/etc/qcc\gcc. However, keep in
> >> mind that it still uses qcc taken from 6.4. Another option is to install
> >> both QNX: 6.3.2 and 6.4, but use only 6.4 IDE (.4.5). Then ]you can
> >> change active configuration using IDE preferences (see QNX page). But to
> >> sort out all the problems you have to update PATH manually to position
> >> correctly $(QNX_HOST)/usr/bin directories and restart IDE. Anyway I
> >> cannot garantee 100% that it works (worked for me in a few cases I
> >> tried it).
> >>
> >
> > If he needs to produce identical binaries to 6.3.2, he'd have to use the
> > both 6.3.2 qnx host and qnx target directories. You won't get
> > identical binaries if you use 6.3.2 tools and link against 6.4 libraries.
> >
Don't know if I'm not seeing the big picture but in QNX4 we can compile 20 years old program no sweat, Watcom 9 10 and
11, all living at the same time on a the same system. With Windows and Visual C same story, just have to install the
proper version of Visual C and all is good. It does sound like a major short coming to me. I mean the OS and compiler
should be independent. I should be able to install gcc (2.9.5, 3.3.2?, 3.3.5) and their related libraries in 6.4. I
mean isn't that what qcc -V is for?
The way I see this, in a couple of years everybody here will need to have installed 6.3.2, 6.4, 6.4.2, 6.5 in different
partition and reboot to go from one to the other in order to support the different version of our product.
Maybe there is something I"m missing?
|
|
|
|
|
|
Mario Charest
09/05/2008 10:56 AM
post12933
|
> Don't know if I'm not seeing the big picture but in QNX4 we can compile 20
> years old program no sweat, Watcom 9 10 and 11, all living at the same time on
> a the same system. With Windows and Visual C same story, just have to
> install the proper version of Visual C and all is good. It does sound like a
> major short coming to me. I mean the OS and compiler should be independent.
> I should be able to install gcc (2.9.5, 3.3.2?, 3.3.5) and their related
> libraries in 6.4. I mean isn't that what qcc -V is for?
>
> The way I see this, in a couple of years everybody here will need to have
> installed 6.3.2, 6.4, 6.4.2, 6.5 in different partition and reboot to go from
> one to the other in order to support the different version of our product.
>
> Maybe there is something I"m missing?
>
Just realized that with 6.3.2 I can't build anything for 6.1 and I've never complained about it. But then again our
first system to be deployed is based on 6.3.2 so the problem never showed up.
|
|
|
|
|
|
Bill Graham
09/05/2008 11:29 AM
post12935
|
It was an explicit decision to make 4.2.x the only compiler available with 6.4. This was a tough one as you have pointed
out - many customers need these other compilers. In the end, we needed to trim the number of branches of GCC we
supported. If we continued on our previous path we would have 2.95.3, 3.3.5 and then 4.2.x to support.
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/05/2008 11:41 AM
post12939
|
Mario Charest wrote:
>> Oh, definitely! This is what I meant. This is supported by switching in
>> preferences.
>>
>> Ryan Mansfield wrote:
>>> Alex Chapiro wrote:
>>>
>>>> There is no convenient way to do that now. You can copy manually 2.95
>>>> and/or 3.35 directories to $(QNX_HOST)/etc/qcc\gcc. However, keep in
>>>> mind that it still uses qcc taken from 6.4. Another option is to install
>>>> both QNX: 6.3.2 and 6.4, but use only 6.4 IDE (.4.5). Then ]you can
>>>> change active configuration using IDE preferences (see QNX page). But to
>>>> sort out all the problems you have to update PATH manually to position
>>>> correctly $(QNX_HOST)/usr/bin directories and restart IDE. Anyway I
>>>> cannot garantee 100% that it works (worked for me in a few cases I
>>>> tried it).
>>>>
>>> If he needs to produce identical binaries to 6.3.2, he'd have to use the
>>> both 6.3.2 qnx host and qnx target directories. You won't get
>>> identical binaries if you use 6.3.2 tools and link against 6.4 libraries.
>>>
>
> Don't know if I'm not seeing the big picture but in QNX4 we can compile 20 years old program no sweat, Watcom 9 10 and
11, all living at the same time on a the same system. With Windows and Visual C same story, just have to install the
proper version of Visual C and all is good. It does sound like a major short coming to me. I mean the OS and compiler
should be independent. I should be able to install gcc (2.9.5, 3.3.2?, 3.3.5) and their related libraries in 6.4. I
mean isn't that what qcc -V is for?
You can copy 2.95.3, 3.3.5 into 6.4 and switch between them using qcc
-V. But 6.4 will only ship with gcc 4.2.4.
On Linux and Windows host we support coexistence at the SDK level and
you can have 630, 632, 640 all installed beside one another and then
switch back and forth with ease. For self hosted the historical
packaging of the SDK and the runtime together require things to be
manually copied over. We didn't ship a self-hosted SDK package you could
install into 640. I suspect the historical motivation may have been that
self-hosted users would be targeting the same version Neutrino as their
host.
Potentially someone could use the 632 tools to link against 640
libraries by setting QNX_HOST/QNX_TARGET appropriately but your
requirement of being binary identical makes this impossible. The
regardless of which version of qnx host tools you are using, they will
pull from your qnx target directory so while code generated by the 6.3.2
would be identical the libraries it pulls in will have changed between
releases.
Regards,
Ryan Mansfield
|
|
|
|
|
|
Mario Charest
09/05/2008 11:59 AM
post12944
|
>
> You can copy 2.95.3, 3.3.5 into 6.4 and switch between them using qcc
> -V. But 6.4 will only ship with gcc 4.2.4.
Could QNX make availble 2.95.3 and 3.3.5 as separate archive much like 4.2.1 can be downloaded and installed on 6.3.2.
>
> On Linux and Windows host we support coexistence at the SDK level and
> you can have 630, 632, 640 all installed beside one another and then
> switch back and forth with ease.
With ease? Some config depends on environment variable, fiddling around we these is not what I call simple.
> For self hosted the historical
> packaging of the SDK and the runtime together require things to be
> manually copied over. We didn't ship a self-hosted SDK package you could install into 640.
Maybe not go as far as a SDK ( although I believe that is the way it should be done), but maybe come up with some sort
of official procedure.
>I suspect the historical motivation may have been that
> self-hosted users would be targeting the same version Neutrino as their
> host.
Wrong assumption if you ask me, but then again you didn't ask ;-)
>
> Potentially someone could use the 632 tools to link against 640
> libraries by setting QNX_HOST/QNX_TARGET appropriately but your
> requirement of being binary identical makes this impossible.
Nah nothing impossible (not quite, can't teleport ), impractical or too much work for QNX maybe but not impossible.
> The
> regardless of which version of qnx host tools you are using, they will
> pull from your qnx target directory so while code generated by the 6.3.2
> would be identical the libraries it pulls in will have changed between
> releases.
>
Needless to say this is going to be a big torn in our collective foot.
> Regards,
>
> Ryan Mansfield
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/05/2008 1:22 PM
post12955
|
Mario Charest wrote:
>> You can copy 2.95.3, 3.3.5 into 6.4 and switch between them using qcc
>> -V. But 6.4 will only ship with gcc 4.2.4.
>
> Could QNX make availble 2.95.3 and 3.3.5 as separate archive much like 4.2.1 can be downloaded and installed on 6.3.2.
You mean installed on 6.4? Yes, we have discussed making them available
available on the foundry so this is a possibility. If we did, it
wouldn't happen before 6.4 is released though.
>> On Linux and Windows host we support coexistence at the SDK level and
>> you can have 630, 632, 640 all installed beside one another and then
>> switch back and forth with ease.
>
> With ease? Some config depends on environment variable, fiddling around we these is not what I call simple.
I have them all installed on both my Windows and Linux hosts and
regularly flip between 630, 632 and 640 by changing the
QNX_HOST/QNX_TARGET combo. Putting the env variables in a script could
means you could change environments with one command instead of two. The
environment can also be switched using qconfig utility, and also the
Windows SDK has a utility called qwincfg.
>> For self hosted the historical
>> packaging of the SDK and the runtime together require things to be
>> manually copied over. We didn't ship a self-hosted SDK package you could install into 640.
>
> Maybe not go as far as a SDK ( although I believe that is the way it should be done), but maybe come up with some sort
of official procedure.
I agree this should be clarified. I would very much like to fully
support coexistence for self hosted. I'm not familiar with inter
workings of the Neutrino installer but I believe the way it shipped
doesn't allow it to be installed under 6.4.
>> I suspect the historical motivation may have been that
>> self-hosted users would be targeting the same version Neutrino as their
>> host.
>
> Wrong assumption if you ask me, but then again you didn't ask ;-)
To be fair I wasn't here at the time and I am simply guessing as to the
rationale of others. There could be other factors or problems that I am
not aware of that were behind the decision.
>> Potentially someone could use the 632 tools to link against 640
>> libraries by setting QNX_HOST/QNX_TARGET appropriately but your
>> requirement of being binary identical makes this impossible.
>
> Nah nothing impossible (not quite, can't teleport ), impractical or too much work for QNX maybe but not impossible.
No, there's no way to do it. If you want your binaries to be identical
to the ones generated in your 6.3.2 system, you must use the same tools
and link against the same libraries. For example, there were fixes made
to the crt1.o file in 640. By default, every link pulls in this object
file and your resulting binary will be different. To your make binaries
identical, the 6.4 libraries couldn't be changed in any way which means
they would have to be identical to the 6.3.2 libraries. How can things
cannot be the both the same and different?
>> The
>> regardless of which version of qnx host tools you are using, they will
>> pull from your qnx target directory so while code generated by the 6.3.2
>> would be identical the libraries it pulls in will have changed between
>> releases.
>>
>
> Needless to say this is going to be a big torn in our collective foot.
I understand. We appreciate the feedback and will take your comments
under consideration.
Regards,
Ryan Mansfield
|
|
|
|
|
|
Bill Graham
09/05/2008 1:41 PM
post12958
|
We can look at hosting these archives for 2.95.3 and 3.3.5 on the CLT project. This wouldn't necessarily be part of the
official release but something we can provide to support what you're trying to do.
Bill
|
|
|
|
|
|
Mario Charest
09/05/2008 1:57 PM
post12962
|
> We can look at hosting these archives for 2.95.3 and 3.3.5 on the CLT project.
> This wouldn't necessarily be part of the official release but something we
> can provide to support what you're trying to do.
>
Yes that would be good enough. Just like 4.2.1 can be downloaded now and run on 6.3.2, I should be able to download 3.3.
5 and run it on 6.4. Then there could be a SDK to install the libraries that came with 6.3.2 (/usr/qnx630, /usr/qnx632,
etc)
> Bill
|
|
|
|
|
|
Mario Charest
09/05/2008 1:55 PM
post12960
|
> Mario Charest wrote:
> >> You can copy 2.95.3, 3.3.5 into 6.4 and switch between them using qcc
> >> -V. But 6.4 will only ship with gcc 4.2.4.
> >
> > Could QNX make availble 2.95.3 and 3.3.5 as separate archive much like 4.2.1
> can be downloaded and installed on 6.3.2.
>
> You mean installed on 6.4? Yes, we have discussed making them available
> available on the foundry so this is a possibility. If we did, it
> wouldn't happen before 6.4 is released though.
>
For us that means we wouldn't use 6.4 for the dev seat till they become available. Note that this doesn't affect our
runtime. The way we build our runtime images is independent of the OS we are build it on.
>
> >> I suspect the historical motivation may have been that
> >> self-hosted users would be targeting the same version Neutrino as their
> >> host.
> >
> > Wrong assumption if you ask me, but then again you didn't ask ;-)
>
>
> >> Potentially someone could use the 632 tools to link against 640
> >> libraries by setting QNX_HOST/QNX_TARGET appropriately but your
> >> requirement of being binary identical makes this impossible.
> >
> > Nah nothing impossible (not quite, can't teleport ), impractical or too much
> work for QNX maybe but not impossible.
>
> No, there's no way to do it. If you want your binaries to be identical
> to the ones generated in your 6.3.2 system, you must use the same tools
> and link against the same libraries. For example, there were fixes made
> to the crt1.o file in 640. By default, every link pulls in this object
> file and your resulting binary will be different. To your make binaries
> identical, the 6.4 libraries couldn't be changed in any way which means
> they would have to be identical to the 6.3.2 libraries. How can things
> cannot be the both the same and different?
What I'm saying is I should be able to use the tools that came with 6.3.2 but on 6.4. I should be able to mix and match
SDK/compiler/host at will. Although it would be understandable that some combination would not be officially
supported for example 2.95.3 with the 6.4 libraries.
>
> I understand. We appreciate the feedback and will take your comments
> under consideration.
Thanks for listening.
|
|
|
|
|
|
Alex Chapiro
09/05/2008 1:40 PM
post12957
|
What I wrote before is the current state. It should be changed before
the final release.
Mario Charest wrote:
>> Oh, definitely! This is what I meant. This is supported by switching in
>> preferences.
>>
>> Ryan Mansfield wrote:
>>
>>> Alex Chapiro wrote:
>>>
>>>
>>>> There is no convenient way to do that now. You can copy manually 2.95
>>>> and/or 3.35 directories to $(QNX_HOST)/etc/qcc\gcc. However, keep in
>>>> mind that it still uses qcc taken from 6.4. Another option is to install
>>>> both QNX: 6.3.2 and 6.4, but use only 6.4 IDE (.4.5). Then ]you can
>>>> change active configuration using IDE preferences (see QNX page). But to
>>>> sort out all the problems you have to update PATH manually to position
>>>> correctly $(QNX_HOST)/usr/bin directories and restart IDE. Anyway I
>>>> cannot garantee 100% that it works (worked for me in a few cases I
>>>> tried it).
>>>>
>>>>
>>> If he needs to produce identical binaries to 6.3.2, he'd have to use the
>>> both 6.3.2 qnx host and qnx target directories. You won't get
>>> identical binaries if you use 6.3.2 tools and link against 6.4 libraries.
>>>
>>>
>
> Don't know if I'm not seeing the big picture but in QNX4 we can compile 20 years old program no sweat, Watcom 9 10 and
11, all living at the same time on a the same system. With Windows and Visual C same story, just have to install the
proper version of Visual C and all is good. It does sound like a major short coming to me. I mean the OS and compiler
should be independent. I should be able to install gcc (2.9.5, 3.3.2?, 3.3.5) and their related libraries in 6.4. I
mean isn't that what qcc -V is for?
>
> The way I see this, in a couple of years everybody here will need to have installed 6.3.2, 6.4, 6.4.2, 6.5 in
different partition and reboot to go from one to the other in order to support the different version of our product.
>
> Maybe there is something I"m missing?
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post12932
>
>
|
|
|
|
|
|
