Windows hosted cross to RTP?

Hi all,

Are there any plans to support a windows hosted cross compiler
to RTP, such as was available for Neutrino 2.0c? I was quite
disappointed to see that v1.0 of this toolkit was no different than PR4.
(Based on an old version of cygwin32, old version of gcc, PPC
exception handling problems, large array compilation problems, etc.)

Unfortunately our tools can not be moved from Windows, (MFC, C++ builder,
Active X, COM, etc.), so no “move to a self hosted RTP” messages please…

Thanks!
Kevin Radke

If I were in your position I’d pull my old light saber and go for ‘if
you want to do it right do it yourself’ approach. There should be GCC
for Win32 source somewhere, right? Patches for GNU toolchain to support
Neutrino are available (should be on Colin’s page). It should not be too
hard to build a new version based on latest GCC. I did something of that
sort a while back, when I was in your position (but we needed Solaris in
stead of Windows). Took me about a week and few conversations with Alain
to get it working.

Once you have GCC 2.95 for Win32 supporting Neutrino target, just plug
new libraries/headers instead of ones shipped with CW (take them from
RTP).

  • igor

Kevin Radke wrote:

Hi all,

Are there any plans to support a windows hosted cross compiler
to RTP, such as was available for Neutrino 2.0c? I was quite
disappointed to see that v1.0 of this toolkit was no different than PR4.
(Based on an old version of cygwin32, old version of gcc, PPC
exception handling problems, large array compilation problems, etc.)

Unfortunately our tools can not be moved from Windows, (MFC, C++ builder,
Active X, COM, etc.), so no “move to a self hosted RTP” messages please…

Thanks!
Kevin Radke

“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:3A6E3304.59F23670@motorola.com

If I were in your position I’d pull my old light saber and go for ‘if
you want to do it right do it yourself’ approach. There should be GCC
for Win32 source somewhere, right? Patches for GNU toolchain to support
Neutrino are available (should be on Colin’s page). It should not be too
hard to build a new version based on latest GCC. I did something of that
sort a while back, when I was in your position (but we needed Solaris in
stead of Windows). Took me about a week and few conversations with Alain
to get it working.

Once you have GCC 2.95 for Win32 supporting Neutrino target, just plug
new libraries/headers instead of ones shipped with CW (take them from
RTP).

Yes, this is an obvious solution. I have in fact built cross gcc before for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

Kevin

“Kevin Radke” <kradke@dsi-inc.net> wrote in message
news:94mqal$q55$1@inn.qnx.com

Yes, this is an obvious solution. I have in fact built cross gcc before
for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

I suspect that QSSL is in a similar situation (i.e. they don’t wan’t to be
in the business of supporting all the cross development environments that
gcc supports). It seems, however, that they have at least some degree of
interest in supporting Windows <-> Neutrino. I believe that this support is
currently not in a state that you are happy with, and you may very well be
justified in your dissatisfaction (I have not used the Windows tools, so I
don’t have an opinion on them).

I think Igors’ response was well intentioned, and useful in the general
sense, if not for your particular case. It does not justify the “Yes, this
is an obvious solution” response.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

That is your judgement to make. It is obvious that not using Neutrino is one
of your options; however; stating that in this newsgroup seems more of a
cynical attempt to get your issue elevated in importance, than a genuinely
useful piece of data for the readers of this newsgroup.

“John Doe” <john@csical.com> wrote in message
news:94n3hl$24m$3@inn.qnx.com

“Kevin Radke” <> kradke@dsi-inc.net> > wrote in message
news:94mqal$q55$> 1@inn.qnx.com> …
Yes, this is an obvious solution. I have in fact built cross gcc before
for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

I suspect that QSSL is in a similar situation (i.e. they don’t wan’t to be
in the business of supporting all the cross development environments that
gcc supports). It seems, however, that they have at least some degree of
interest in supporting Windows <-> Neutrino. I believe that this support
is
currently not in a state that you are happy with, and you may very well be
justified in your dissatisfaction (I have not used the Windows tools, so I
don’t have an opinion on them).

I think Igors’ response was well intentioned, and useful in the general
sense, if not for your particular case. It does not justify the “Yes, this
is an obvious solution” response.

I agree that his response was well intentioned, and I did not intend
to make it seem trivial. Obvious solutions are not in general “bad” things,
just not always the preferred solution.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

That is your judgement to make. It is obvious that not using Neutrino is
one
of your options; however; stating that in this newsgroup seems more of a
cynical attempt to get your issue elevated in importance, than a genuinely
useful piece of data for the readers of this newsgroup.

I would not term it “cynical”, but it was a (poor?) attempt to get
QNX’s attention on this matter.

Ultimately it is up to QNX to decide if supporting Windows hosted
cross compiler tools is a good business decision. Similar questions
have been asked in the past, with no definite answer…

Kevin

Upgrading tool chain, libraries and headers yourself, ok… fine. But what
is stopping QSSL of doing just this???

I have used the Metrowerks IDE for quite some time now and am quite happy
about the functonality and stability. I was disappointed when the last
upgrade to Metrowerks release 1.0 came and QSSL shipped the SAME Neutrino
2.0C CD as last time.

There have been a number of questions about Windows cross development, so
what about giving an answer QSSL!

“Kevin Radke” <kradke@dsi-inc.net> wrote in message
news:94nki0$c79$1@inn.qnx.com

“John Doe” <> john@csical.com> > wrote in message
news:94n3hl$24m$> 3@inn.qnx.com> …

“Kevin Radke” <> kradke@dsi-inc.net> > wrote in message
news:94mqal$q55$> 1@inn.qnx.com> …
Yes, this is an obvious solution. I have in fact built cross gcc
before
for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

I suspect that QSSL is in a similar situation (i.e. they don’t wan’t to
be
in the business of supporting all the cross development environments
that
gcc supports). It seems, however, that they have at least some degree
of
interest in supporting Windows <-> Neutrino. I believe that this
support
is
currently not in a state that you are happy with, and you may very well
be
justified in your dissatisfaction (I have not used the Windows tools, so
I
don’t have an opinion on them).

I think Igors’ response was well intentioned, and useful in the general
sense, if not for your particular case. It does not justify the “Yes,
this
is an obvious solution” response.

I agree that his response was well intentioned, and I did not intend
to make it seem trivial. Obvious solutions are not in general “bad”
things,
just not always the preferred solution.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

That is your judgement to make. It is obvious that not using Neutrino is
one
of your options; however; stating that in this newsgroup seems more of a
cynical attempt to get your issue elevated in importance, than a
genuinely
useful piece of data for the readers of this newsgroup.

I would not term it “cynical”, but it was a (poor?) attempt to get
QNX’s attention on this matter.

Ultimately it is up to QNX to decide if supporting Windows hosted
cross compiler tools is a good business decision. Similar questions
have been asked in the past, with no definite answer…

Kevin

The Neutrino 2.11 beta CD will come the 2.95.2 toolchain.
The last release still contained the 2.8.1 toolchain because you can’t beta
test one product and then replace it with a completely different product
just before the release. That would undermine the purpose of a beta test.

“Svein Erik Aasen” <svein.erik.aasen@oceanor.no> wrote in message
news:94nnh7$dou$1@inn.qnx.com

Upgrading tool chain, libraries and headers yourself, ok… fine. But what
is stopping QSSL of doing just this???

I have used the Metrowerks IDE for quite some time now and am quite happy
about the functonality and stability. I was disappointed when the last
upgrade to Metrowerks release 1.0 came and QSSL shipped the SAME Neutrino
2.0C CD as last time.

There have been a number of questions about Windows cross development, so
what about giving an answer QSSL!

“Kevin Radke” <> kradke@dsi-inc.net> > wrote in message
news:94nki0$c79$> 1@inn.qnx.com> …
“John Doe” <> john@csical.com> > wrote in message
news:94n3hl$24m$> 3@inn.qnx.com> …

“Kevin Radke” <> kradke@dsi-inc.net> > wrote in message
news:94mqal$q55$> 1@inn.qnx.com> …
Yes, this is an obvious solution. I have in fact built cross gcc
before
for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

I suspect that QSSL is in a similar situation (i.e. they don’t wan’t
to
be
in the business of supporting all the cross development environments
that
gcc supports). It seems, however, that they have at least some degree
of
interest in supporting Windows <-> Neutrino. I believe that this
support
is
currently not in a state that you are happy with, and you may very
well
be
justified in your dissatisfaction (I have not used the Windows tools,
so
I
don’t have an opinion on them).

I think Igors’ response was well intentioned, and useful in the
general
sense, if not for your particular case. It does not justify the “Yes,
this
is an obvious solution” response.

I agree that his response was well intentioned, and I did not intend
to make it seem trivial. Obvious solutions are not in general “bad”
things,
just not always the preferred solution.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

That is your judgement to make. It is obvious that not using Neutrino
is
one
of your options; however; stating that in this newsgroup seems more of
a
cynical attempt to get your issue elevated in importance, than a
genuinely
useful piece of data for the readers of this newsgroup.

I would not term it “cynical”, but it was a (poor?) attempt to get
QNX’s attention on this matter.

Ultimately it is up to QNX to decide if supporting Windows hosted
cross compiler tools is a good business decision. Similar questions
have been asked in the past, with no definite answer…

Kevin

\

Kevin Radke a écrit :

“John Doe” <> john@csical.com> > wrote in message
news:94n3hl$24m$> 3@inn.qnx.com> …

“Kevin Radke” <> kradke@dsi-inc.net> > wrote in message
news:94mqal$q55$> 1@inn.qnx.com> …
Yes, this is an obvious solution. I have in fact built cross gcc before
for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

I suspect that QSSL is in a similar situation (i.e. they don’t wan’t to be
in the business of supporting all the cross development environments that
gcc supports). It seems, however, that they have at least some degree of
interest in supporting Windows <-> Neutrino. I believe that this support
is
currently not in a state that you are happy with, and you may very well be
justified in your dissatisfaction (I have not used the Windows tools, so I
don’t have an opinion on them).

I think Igors’ response was well intentioned, and useful in the general
sense, if not for your particular case. It does not justify the “Yes, this
is an obvious solution” response.

I agree that his response was well intentioned, and I did not intend
to make it seem trivial. Obvious solutions are not in general “bad” things,
just not always the preferred solution.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

That is your judgement to make. It is obvious that not using Neutrino is
one
of your options; however; stating that in this newsgroup seems more of a
cynical attempt to get your issue elevated in importance, than a genuinely
useful piece of data for the readers of this newsgroup.

I would not term it “cynical”, but it was a (poor?) attempt to get
QNX’s attention on this matter.

Ultimately it is up to QNX to decide if supporting Windows hosted
cross compiler tools is a good business decision. Similar questions
have been asked in the past, with no definite answer…

Kevin

Just to give an opinion.
After having though about the question when we planned to use qnx, we finally
found quite powerfull to develop for neutrino with neutrino as we can do lot of
things that a cross ide cannot do at test time. We have directly access to any
files, directory tree, lot of tools, shell, etc… Things which need a rsh or
phindows. So, we decided to edit within windows editor as qrtp editors makes me
shudder compare to the powerfull SlickEdit editor (just for example as I know by
experience that editors subject can launch attacks), and we build the
applications through phindows. For sure, Slickedit doesn’t support remote
commands as Sniff do, (other example,… just an example) but Sniff is very
expensive, so we cannot get the error messages back to editor output window. A
little bit uncomfortable but I prefer to pay this price.
We use WinCVS, connected to the qrtp cvs to manage our file versions.
I work daily like that, recursive makefiles are incredibly powerfull, we are
sure to be up to date with qrtp on any points, headers, librairies,
toolchain,… I no more want to hear talking about cross IDE, I don’t want to
wonder if my problems come from QNX or the cross ide.
Anyway, as qrtp moves lot at the moment, it’s not time to talk about cross ide,
especially if it’s not a QNX product!!!

Alain.

Kevin Radke a écrit :

“John Doe” <> john@csical.com> > wrote in message
news:94n3hl$24m$> 3@inn.qnx.com> …

“Kevin Radke” <> kradke@dsi-inc.net> > wrote in message
news:94mqal$q55$> 1@inn.qnx.com> …
Yes, this is an obvious solution. I have in fact built cross gcc before
for
other platforms. However, we do not want to be in the business of
supporting these ports for our customers that would be using them in
conjunction with our product.

I suspect that QSSL is in a similar situation (i.e. they don’t wan’t to be
in the business of supporting all the cross development environments that
gcc supports). It seems, however, that they have at least some degree of
interest in supporting Windows <-> Neutrino. I believe that this support
is
currently not in a state that you are happy with, and you may very well be
justified in your dissatisfaction (I have not used the Windows tools, so I
don’t have an opinion on them).

I think Igors’ response was well intentioned, and useful in the general
sense, if not for your particular case. It does not justify the “Yes, this
is an obvious solution” response.

I agree that his response was well intentioned, and I did not intend
to make it seem trivial. Obvious solutions are not in general “bad” things,
just not always the preferred solution.

Another obvious solution is to just not use Neutrino, but that
is not a preferred option at the moment.

That is your judgement to make. It is obvious that not using Neutrino is
one
of your options; however; stating that in this newsgroup seems more of a
cynical attempt to get your issue elevated in importance, than a genuinely
useful piece of data for the readers of this newsgroup.

I would not term it “cynical”, but it was a (poor?) attempt to get
QNX’s attention on this matter.

Ultimately it is up to QNX to decide if supporting Windows hosted
cross compiler tools is a good business decision. Similar questions
have been asked in the past, with no definite answer…

Kevin

I just saw in QNX News, that the CodeWarrior tools are in pre-release stage.

Alain.

phindows. So, we decided to edit within windows editor as qrtp editors
makes me
shudder compare to the powerfull SlickEdit editor (just for example as I
know by

I decided the same thing when looking at how to develop for QNX 4.25. Using
Phindows you have full access to anything you need in native QNX and add to
that a Samba setup and now your favorite WinX editor can edit your source
files. It doesn’t give you 100% productivity but its a small price to pay
for the
fully featured WinX based stuff until native 4.25 and RTP stuff can be
developed
or ported or whatever…

Right now I use CodeWrite/Genitor/Samba/Phindows for QNX 4.25 and
after a little more time I hope to do the same for RTP…

toolchain,… I no more want to hear talking about cross IDE, I don’t want
to
wonder if my problems come from QNX or the cross ide.

I’m not usually impressed by cross IDE or cross anything…From what I have
seen
the added complexity and overhead to support multiple different platforms
usually detracts from the platform that concerns me. I much prefer
different
implementations of a piece of software, each optimized for the platform
rather
then some swiss army knife…:slight_smile:

~ Lee R. Copp
~ Project Engineer (EE/ME)
~ Michigan Scientific Corp.
~ 321 East Huron St.
~ Milford, MI 48381
~ 248-685-3939 x109 (V), 248-684-5406 (Fx)
~ http://www.michiganscientific.com
~ mailto:<Lee.R.Copp@MichiganScientific.com>