I can see some value in disabling /usr/local/include (shouldn't we also disable /usr/local/lib ?), but I think putting %p/include and %p/lib at the end of our search paths rather than the beginning is going to cause us trouble: Wouldn't we be putting ourselves at the mercy of anything that Apple decides to ship in a new OS version? What benefit would we get from the different search order?
Setting LIBRARY_PATH does not put %p/lib at the very end, it puts it before /usr/lib and /usr/local/lib, but after anything else specified with -L, as you can see below:
peter% env LIBRARY_PATH=/sw/lib gcc -print-search-dirs [snip] libraries: =/sw/lib/ppc/3.3/ /sw/lib/ /usr/libexec/gcc/darwin/ppc/3.3/ [snip] /lib/ppc/3.3/ /lib/ /usr/lib/ppc/3.3/ /usr/lib/
You will see that LIBRARY_PATH has zero effect on things which (incorrectly) use ld directly. Note that disabling /usr/local/lib is impossible, it is hardcoded into ld:
/* the standard directories to search for -lx names */
__private_extern__ char *standard_dirs[] = {
"/lib/",
"/usr/lib/",
"/usr/local/lib/",
NULL
};The only ways to change it is to ld -Z to delete all of them, or the NEXT_ROOT env var which modifies them. I would love to know why /lib is everywhere in the toolchain when it does not exist in reality :).
What if we make CPPFLAGS=-I%p/include -DLOCAL_INCLUDE_DIR=\%p/include ?
That way, %p/include would theoretically be searched twice, but in practice, the second time wouldn't actually matter, since any successful #include would already be done by then.
I like this better, it disables /usr/local but otherwise does not change the way packages currently build.
There is, of course, the option of having cc/gcc shell scripts somewhere under /sw which get added to the head of the path during build (and perhaps depending on the GCC: field), these shell scripts could add any required options to the command line, and would then pass the modified line along to the next cc/gcc in the path. The advantages of this system defeat me, but perhaps it would better integrate with distcc/ccache (or probably make distcc/ccache worse).
Anyway, this e-mail is pretty worthless, however, I have typed it, so I will inflict it on everyone anyway :)
Peter -- Peter O'Gorman - http://www.pogma.com
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
