Re: OSX Porting Problems
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> Wed, 14 Mar 2007 20:59:31 +0100
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2007-03-14 at 20:43:31 [+0100], Morgan Howe <[email protected]> wrote: > On 3/14/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote: > > On 2007-03-14 at 19:01:48 [+0100], Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected] > > wrote: > > > On 2007-03-14 at 18:21:14 [+0100], Morgan Howe <[email protected]> wrote: > > > > > > > > I have just rebuilt gcc4, and am going to start going forward again. > > > > This > > > > will be my next focus. In regards to your earlier comment about using > > a > > > > "very old system", I noticed that and found it strange > > myself. :) I've > > > > found a few things mentioning defining NO_IMPLICIT_EXTERN_C, but that > > does > > > > not seem to help. I'll continue to look into that as well. > > > > > > The "-isystem" -> "-I" change looks OK to me. It even seems to be more > > > correct (or at least desired) to use "-I". So, I'll apply it as soon as > > I've > > > checked that it doesn't break the gcc 4 build under Linux. Which I > > suppose > > > it > > > won't. > > > > Mmh, apparently I was wrong. Unlike the "System Headers" section in the > > gcc > > online docs states, the compiler does not only suppress warnings, but even > > errors when processing a "system header". I'll have a look whether it is > > worthwhile to try and fix those issues. > > > > Actually, you will like this news even better. GCC apparently handles the > idirafter differently for darwin than it does for others. I was messing > around and realized that I had missed the obvious. Jam is actually calling > /usr/bin/c++ which obviously has a target of darwin. I pulled out the build > command and prepended the generated/cross-tools/bin/i586-pc-haiku- path so > it was actually *using* the cross compiler, and that seems to resolve both > problems. :) > > How do I make it so that jam prepends the target system to all of the build > tools instead of calling my native ones? It is actually correct that for some build targets the host tool chain is used. There are several tools -- rc, xres, settype, mimeset, setversion, ... (actually everything in src/tools, plus the bfs_shell) -- that are built to run on the host platform. They generate files (e.g. resource files) or modify other generated files (e.g. by adding resources or attributes). These tools have to run on the host platform and it wouldn't be wise to use the cross-compilation tool chain to build them. The build system might in some cases be inconsequent regarding what headers are used for sources compiled for the host platform, but it should be very correct what tool chain is used in what case. CU, Ingo ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV