Re: OSX Porting Problems

>
> 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.


Well there goes my easy fix.  :)  Well, perhaps something like this would
work better?  I modified HelperRules to look like this:
245     if $(HOST_PLATFORM) = darwin {
246         $(prefix)_SYSTEM_INCLUDES_OPTION = "-I" ;
247     }
248     else {
249         $(prefix)_SYSTEM_INCLUDES_OPTION = "-idirafter " ;
250     }

That fixes the implicit extern C issue and also should hopefully not cause
any problems for linux?

Morgan

-------------------------------------------------------------------------
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

_______________________________________________
Open-beos-kernel-devel mailing list
Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel