Hi Ned, I like the patch - there are probably many cases where a package does not cross compile properly when include paths are not fixed. In those cases, it would be necessary to patch the source on an ebuild-by-ebuild basis. This would eliminate the need to fix the files at an ebuild level with a relatively inexpensive check.
Mike has a couple of good points too - unless it's necessary to use thee function from outside gcc or whatever library it ends up in, it may as well be marked static. Path vs name ? I think path. Regarding arbitrary non-standard include paths that could generate false positives, i have no comment. Regarding path normalization ( "//" => "/" ) - in my opinion, if gcc doesn't already do it, then forget about it - otherwise one would be obliged to fix it for the rest of gcc, no? Keep it short and simple. Depending on the level of community feedback you want, I could help test for a while, or you could just include it in an unstable ~ gcc version and see how the universe reacts to it :) Regards, Chris On Sun, Sep 21, 2008 at 12:12 PM, Ned Ludd <[email protected]> wrote: > I've been toying with an idea after seeing a patch which would abort() > when it detected host includes for cross compiles. I did not like the > idea of aborting as it prevented me from building pkgs that had the same > headers in $ROOT as /. I did like the fact there was a little QA I could > slip in there. After thinking about it a while. I said fsck the QA and > just fixed the problem. Here is what I came up with for gcc-4.2.4.. > > While in my testing I'm finding this works beautifully. However I'd like > some input from others on what they think of such an idea. > Good/Bad/Other? > > Basic goal detect ^/usr/include and rewrite it to $ROOT/usr/include if > using a cross compiler and ROOT is set. > > > -solar > >
