This is the mail archive of the
mailing list for the GCC project.
Re: Crosscompiler C/C++ developement.
- From: Nix <nix at esperi dot demon dot co dot uk>
- To: Immanuel Litzroth <immanuell at enfocus dot be>
- Cc: gcc at gcc dot gnu dot org
- Date: 30 May 2002 20:48:41 +0100
- Subject: Re: Crosscompiler C/C++ developement.
- References: <20020529125434.16FC11FFAE@eos.telenet-ops.be>
On Wed, 29 May 2002, Immanuel Litzroth mused:
> Since our version of the xlC compiler has minimal C++ support we
> wish to explore the following path:
> 1) use gcc to compile the C++ core and the the C wrapper.
> 2) create a static library to deliver to the customer.
> 3) the customer uses xlC to compile and link to our library.
> the problem is that a test application generated according to this
> scenario requires me to link with libsupc++.a and libgcc.a and results
> in an application that dumps core.
If some C++ parts of a program are built by GCC, the program must be
linked by GCC. GCC runs a program called `collect2' to arrange for
global constructors and destructors to be called at the right time, and
> Can anyone tell if
> 1) this scenario is feasible
Not really, no :( you could always try to get collect2 to work outside
of GCC, but I don't know how big a job that would be.
You could alternatively use `gcc -v' to find out what command-line
collect2 is called with when linking your application, and call it in
the same way on the customer site to do the linking. (But this is rather
> 2) how to go about creating a fully functional application
Using GCC to link is the easiest course by far.
`Nick shipped buggy code!'
`Oh, no dinner for him...'