Need help for porting
Tue Jan 13 13:54:00 GMT 2004
Dan Kegel <email@example.com> wrote:
> Oooh! You're the first person in a while who's wanted a real
> Canadian Cross, where build != host != target.
But this list is for cross-GCCs, so we should discuss about
using cross-GCCs here, not only about producing them and then
never using them... Yes, it is weird that most people will stay
eternally in the native compiling area when producing native
As so many messages here have told, Windoze really isn't the
best build platform, so if one has something better like Linux
to serve as the build system, that could be the natural choice.
One only replaces the native GCC with a cross GCC when producing
the binutils, GCC, GDB etc. binaries for the another runtime
When the idea about the possibility to use crosscompilers to
produce tools for other hosts has been found, things like producing
all Windoze binaries on Windoze, all Solaris2 binaries on Solaris2,
all NetBSD binaries on NetBSD, all FreeBSD binaries on FreeBSD etc.,
so having a separate build platform for each needed runtime platform,
may sound childish.
But if the question isn't only about building but about 'porting' as
the subject says, debugging the produced tools on the final host may
be obligatory. Or one can try remote debugging...
In the remote debugging area Windoze isn't very well or not at all
supported. Meanwhile with a X11 server one can see and control any
X11-based GDB-with-GUI running on some Unix-like system from the
Windoze screen/keyboard/mouse, one cannot do the same with a Windoze
hosted GDB-with-GUI because the Win32-API has been used there, not
Producing a X11-based GDB (Insight) for Cygwin could be possible
because there is some X11 support in Cygwin too. I remember producing
some X11 client apps for Cygwin years ago but using them only from
the local (Windoze hosted) X11 server. Nowadays X11 belongs to 'Unix'
as default, so claiming Cygwin being a working 'Unixfy-layer' tells
also X11 being working there and it being possible to produce X11
client apps which then can be controlled from somewhere else.
Another choice would be to use some kind of 'gdb-stub' or 'gdbserver'
and this then communicating with the Unix/Linux-hosted cross-GDB, but
in these system target cases using the native-GDB remotely sounds much
In the GDB/Insight area Cygwin should still be much better than MinGW,
although some progress has been happened in the remote-TCP-connections
area lately in MinGW. But whether the remote-RDI things for ARM now have
been ported to MinGW is unclear (the 'gdb/rdi-share' subdir in GDB sources).
Anyway if one wants to produce a Windoze-hosted GDB (for instance) for
'mips64vr4100-elf' and needs to debug this debugger from the build
platform, the native Windoze-GDB should then be remotely controlled.
The 'mips64vr4100-elf' target GDB on Windoze would use the Win32-API and
would be seen and controlled from there, but the GDB to debug it would
work somewhere in the background and be seen and controlled remotely.
With too few knowledge about the serious limits in Windoze it is easy to
imagine all kind of things, like the previous, being possible... Ok, if I
think how I usually will start/use a remote Insight from Linux/Windoze:
1. start the local X11-server
2. take a telnet connection to the remote host
3. redefine the DISPLAY there to be the Linux/Windoze one
4. start the Insight there and see its windows opening on the Linux/Windoze
5. control the remote Insight from the Linux/Windoze keyboard and mouse, the
remote Insight uses the telnet window as its 'target console' or opens
its own xterm for this purpose...
the step 2 alone can be impossible if the remote host is Windoze... How
one 'telnet's to Windoze and starts any apps there? (A very good stupid
question to be asked from the Windoze-gurus...) Does Cygwin include a
Ok, producing things to other systems and debugging them from the Unix
like build platform is easy as far as the other systems are also Unix
like with working X11, telnet etc. 'usual' things working. Windoze isn't
basically a Unix like system...
BTW, when so many people have produced those small embedded Linuces, has
the 'native' debugging been arranged like previously, ie. producing a GUI
based GDB and using it remotely via X11 or only a text-based GDB and using
it via telnet, rsh etc.? I don't remember anyone mentioning producing the
X11, GUI-toolkit etc. extra libraries for the target system after the self
build glibc. I would assume the X11 etc. libs needed to be in sync with
the used glibc, so producing one's own glibc results to producing self all
the other libs too...
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to firstname.lastname@example.org
More information about the crossgcc