On 2007-03-15 23:48:18 +0900, Paul Guyot wrote:
Basically, you are confusing the behavior of the configure script with C_INCLUDE_PATH and LIBRARY_PATH environment variables. There is not much we can do except unset those variables in the configuration script to prevent this.
These variables are necessary for normal use of MacPorts, e.g. to compile non-MacPorts software. Unsetting them in the configure script is not sufficient. You have to make sure that they are not set when the compiler is executed. So, in Mk/dports.autoconf.mk, there should also be: CC = env -u C_INCLUDE_PATH -u LIBRARY_PATH gcc TCL_CC = env -u C_INCLUDE_PATH -u LIBRARY_PATH gcc -pipe SHLIB_LD = env -u C_INCLUDE_PATH -u LIBRARY_PATH cc -dynamiclib ${LDFLAGS} BTW, I reported the gcc bug here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
For your information, the bug I was mentioning is quite different. It happens when there is an installation of readline in /usr/local with headers and no library or with headers and a static library. The reason is that gcc looks into /usr/local/include as part of the system includes (and before /usr/include), while ld does not look into /usr/local/lib and even when told to do so, the -L arguments do not form a simple priority chain as static libraries and dynamic libraries are handled differently. In other words, gcc will take the headers of the newer version of readline in /usr/local while ld will take the library from the system installation of readline.
Last time I checked, the gcc from Xcode didn't look at /usr/local/include. If ld doesn't look in /usr/local/lib when told to do so: has this bug reported to Apple? BTW, some (all?) Linux distributions have the same problem, and I reported it in the Debian BTS, but no-one is decided to fix it. :( -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)