This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

cross compilation for vxworks on FreeBSD



Given the essentially total lack of references to Wind River
Systems/vxWorks in any of the Cygnus documentation, I hope I'm not
violating any tabus (or intruding on some of Cygnus's business) with
this question.

I am attempting to build a gnu-based development environment for a
vxWorks project. I have access to the Win95 (Tornado) toolchain, but
being totally unimpressed (with both Win95 and the Tornado tools), I'm
looking for a way to migrate my work to a more palatable environment.
Given that my favorite flavor of Unix (FreeBSD) is not among the
platforms supported by any of the sources of tools, I hope this
request doesn't step on anybody's commercial toes, but also is not so
obscure as to be unheard of.

Basically, I have managed to get the GNU tools compiled with the
Cygnus one-tree approach, but now I need some recommendations as to
how to proceed.

First, where should the GNU toolchain live? Is it recommended to put
it in the Tornado/host tree? If so, what should the tree look like?

Second, when I try to make the pc486 kernel, my best guess at how to
configure the makefile looks for the compiler as "cc386", but the gnu
cross compiler executable is built as i386-vxworks-aout-gcc. I've had
some success getting the compiler to work by symlinking cc386 to
i386-vxworks-aout-gcc, but is this the right thing to do, or should I
be building the tools elsewhere and copy them to the directory for
host executables in the tornado tree?

Third, when I build symlinks to all the executables so that the
makefile knows about cc386 and friends, it then starts trying to build
a constructor/destructor table source file called ctdt.c with a tool
called 'munch'. The Win95 toolchain includes munch.exe, but the
closest reference I found in the gnu documentation is to collect2, the
function of which has apparently been subsumed into the linker, at
least for self-hosted build environments. How does one get around
this?

Finally, if I ever get everything compiled and linked, I'm planning to
use the 5.2 method of connecting the debugger to the target via rdb
instead of using wtx via the target server. Am I likely to encounter
any problems with this approach?

Basically, I would be interested in establishing communication with
anyone who has done (or attempted) this kind of project, on either
FreeBSD or Linux (which I would consider to be essentially equivalent
once the tools are built). 

Thanks for any help.
Phil


-- 
Phil Staub, KE7HC		Senior Software Engineer
phil@staub.net			Audio Precision, Inc.
or phils@audioprecision.com	Beaverton, OR 97075, (800) 231-7350