I use crossplatform environment on windows. It seems to be ok, simply
some set of gnu tools, gcc, gdb, some of the binutils and bunch of qnx
files. I installed xemacs and edit-compile cycle became nice and smooth.
The only problem for now is that gdb is strictly command line tool.
while I’m fine with this but some of our developers are not happy at all.
As you may know xemacs has some integration with gdb unfortunaterly it
doesn’t
work properly on Windows. When I try to start gdb xemacs fails to find
the source files. The reason seems to be simple, gdb returns some strange
pathes like /cygdrive/c/…/sourcefile.cpp.
Xemacs is smart enougth to add a drive letter like ‘c:’ at the beginnig
and recognize ‘/’. Moreover when I created the c:\cygdrive\c directory
and put my project there it seemed to start working! But it looks odd.
Alas, there are no gdb sources with QSSL modifications available,
though I don’t get why, since gdb is GNU software and I reckoned that if
someone
had modyfied GNU software it still covered by GNU licensing and hence souce
code had to be available. Anyway these licensing issues are out of my
comprehension.
So, I wonder if someone of QSSL gyus knows about this ‘cygdrive’ mangled
path
problem with gdb because Xemacs would be a great IDE if you fixed this
somehow.
cheers,
Igor
The problem arises from the fact that we currently build our win32 versions
of gcc/gdb/etc. using cygwin. That’s why you have the /cygdrive prefix.
Cygwin gives a unix style environment under win32 and to work around the
drive letter thing, they use the convention "/cygdrive//path
to get to windows paths. Unfortunately bringing unix apps to windows is
unpleasant at the best of times and usually requires some sort of
porting/emulation library. We’re investigating alternative ways of using
the GNU toolchain on windows but there always seems to be difficulties.
Personally I find the win32 SDK to be much more usable when I have cygwin
installed (gives me a nice bash shell and vi among other things) but we
recognize that many windows developers don’t find the command line overly
friendly. Check out http://www.eclipse.org to see a hint about where our
future development is going. We’ll be using Eclipse to provide a cross
platform IDE that should make QNX development much friendlier. (not to say
that unix isn’t user friendly…it’s just very picky about who it’s friends
are 
cheers,
Kris
“Igor Levko” <no_spam@nihrena.net> wrote in message
news:a2hcnu$qq4$1@inn.qnx.com…
I use crossplatform environment on windows. It seems to be ok, simply
some set of gnu tools, gcc, gdb, some of the binutils and bunch of qnx
files. I installed xemacs and edit-compile cycle became nice and smooth.
The only problem for now is that gdb is strictly command line tool.
while I’m fine with this but some of our developers are not happy at all.
As you may know xemacs has some integration with gdb unfortunaterly it
doesn’t
work properly on Windows. When I try to start gdb xemacs fails to find
the source files. The reason seems to be simple, gdb returns some strange
pathes like /cygdrive/c/…/sourcefile.cpp.
Xemacs is smart enougth to add a drive letter like ‘c:’ at the beginnig
and recognize ‘/’. Moreover when I created the c:\cygdrive\c directory
and put my project there it seemed to start working! But it looks odd.
Alas, there are no gdb sources with QSSL modifications available,
though I don’t get why, since gdb is GNU software and I reckoned that if
someone
had modyfied GNU software it still covered by GNU licensing and hence
souce
code had to be available. Anyway these licensing issues are out of my
comprehension.
So, I wonder if someone of QSSL gyus knows about this ‘cygdrive’ mangled
path
problem with gdb because Xemacs would be a great IDE if you fixed this
somehow.
cheers,
Igor
Igor Levko <no_spam@nihrena.net> wrote:
Hi Igor,
I use crossplatform environment on windows. It seems to be ok, simply
some set of gnu tools, gcc, gdb, some of the binutils and bunch of qnx
files. I installed xemacs and edit-compile cycle became nice and smooth.
The only problem for now is that gdb is strictly command line tool.
while I’m fine with this but some of our developers are not happy at all.
As you may know xemacs has some integration with gdb unfortunaterly it
doesn’t
work properly on Windows. When I try to start gdb xemacs fails to find
the source files. The reason seems to be simple, gdb returns some strange
pathes like /cygdrive/c/…/sourcefile.cpp.
Xemacs is smart enougth to add a drive letter like ‘c:’ at the beginnig
and recognize ‘/’. Moreover when I created the c:\cygdrive\c directory
and put my project there it seemed to start working! But it looks odd.
Alas, there are no gdb sources with QSSL modifications available,
though I don’t get why, since gdb is GNU software and I reckoned that if
someone
had modyfied GNU software it still covered by GNU licensing and hence souce
code had to be available. Anyway these licensing issues are out of my
comprehension.
Yes it is, goto:
http://developers.qnx.com/Ports/
Marcin
So, I wonder if someone of QSSL gyus knows about this ‘cygdrive’ mangled
path
problem with gdb because Xemacs would be a great IDE if you fixed this
somehow.
cheers,
Igor
Oh, I see. It’s cygwin.dll that does posix emulation.
Ok, It looks like I’d better take a look at xemacs’s gdb package.
This eclipse thing looks a bit monstrous to me, sorry.
I’m afraid we will need too many “horses” just to make this beast run.
Thanks a lot for the answers.
cheers,
Igor
On 21 Jan 2002 17:06:43 GMT, Tools Mail Account <tools@qnx.com> wrote:
Igor Levko <> no_spam@nihrena.net> > wrote:
Hi Igor,
I use crossplatform environment on windows. It seems to be ok, simply
some set of gnu tools, gcc, gdb, some of the binutils and bunch of qnx
files. I installed xemacs and edit-compile cycle became nice and smooth.
The only problem for now is that gdb is strictly command line tool.
while I’m fine with this but some of our developers are not happy at all.
As you may know xemacs has some integration with gdb unfortunaterly it
doesn’t
work properly on Windows. When I try to start gdb xemacs fails to find
the source files. The reason seems to be simple, gdb returns some strange
pathes like /cygdrive/c/…/sourcefile.cpp.
Xemacs is smart enougth to add a drive letter like ‘c:’ at the beginnig
and recognize ‘/’. Moreover when I created the c:\cygdrive\c directory
and put my project there it seemed to start working! But it looks odd.
Alas, there are no gdb sources with QSSL modifications available,
though I don’t get why, since gdb is GNU software and I reckoned that if
someone
had modyfied GNU software it still covered by GNU licensing and hence souce
code had to be available. Anyway these licensing issues are out of my
comprehension.
Yes it is, goto:
http://developers.qnx.com/Ports/
Marcin
So, I wonder if someone of QSSL gyus knows about this ‘cygdrive’ mangled
path
problem with gdb because Xemacs would be a great IDE if you fixed this
somehow.
cheers,
Igor
If I maythrow in an idea here-
How about the idea put forward by someone in a previous thread about
the possibility of using the Redhat’s Insight?
In the thread someone mentioned that the only problem with this
is the modification of the serial protocol as used by pdebug
so as to be non compatible with the GDB remote serial protocol.
Eclipse sounds good but it would nice to be able to offer a graphical
debugger sooner rather than later. Also, choice is your friend…
Here is an article on Redhat site about gdb & choices:
http://www.redhat.com/devnet/articles/embedgdb.htm
Alex Cellarius <acellarius@systems104-don’t-you-spam-me!.co.za> wrote:
Hi Alex,
On 21 Jan 2002 17:06:43 GMT, Tools Mail Account <> tools@qnx.com> > wrote:
Igor Levko <> no_spam@nihrena.net> > wrote:
Hi Igor,
I use crossplatform environment on windows. It seems to be ok, simply
some set of gnu tools, gcc, gdb, some of the binutils and bunch of qnx
files. I installed xemacs and edit-compile cycle became nice and smooth.
The only problem for now is that gdb is strictly command line tool.
while I’m fine with this but some of our developers are not happy at all.
As you may know xemacs has some integration with gdb unfortunaterly it
doesn’t
work properly on Windows. When I try to start gdb xemacs fails to find
the source files. The reason seems to be simple, gdb returns some strange
pathes like /cygdrive/c/…/sourcefile.cpp.
Xemacs is smart enougth to add a drive letter like ‘c:’ at the beginnig
and recognize ‘/’. Moreover when I created the c:\cygdrive\c directory
and put my project there it seemed to start working! But it looks odd.
Alas, there are no gdb sources with QSSL modifications available,
though I don’t get why, since gdb is GNU software and I reckoned that if
someone
had modyfied GNU software it still covered by GNU licensing and hence souce
code had to be available. Anyway these licensing issues are out of my
comprehension.
Yes it is, goto:
http://developers.qnx.com/Ports/
Marcin
So, I wonder if someone of QSSL gyus knows about this ‘cygdrive’ mangled
path
problem with gdb because Xemacs would be a great IDE if you fixed this
somehow.
cheers,
Igor
If I maythrow in an idea here-
How about the idea put forward by someone in a previous thread about
the possibility of using the Redhat’s Insight?
In the thread someone mentioned that the only problem with this
is the modification of the serial protocol as used by pdebug
so as to be non compatible with the GDB remote serial protocol.
Eclipse sounds good but it would nice to be able to offer a graphical
debugger sooner rather than later. Also, choice is your friend…
A port of ddd for windows (for QNX RTP 6.2) should be avaiable on
developers.qnx.com in the near future.
Regards,
Marcin
Here is an article on Redhat site about gdb & choices:
http://www.redhat.com/devnet/articles/embedgdb.htm