Vincent, 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. 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. Paul Le 15 mars 07 à 22:37, Vincent Lefevre a écrit :
On 2007-03-15 19:03:37 +0900, Paul Guyot wrote:
prunille:~> locate libreadline.dylib /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libreadline.dylib /opt/local/lib/libreadline.dylib /opt/local/var/db/dports/build/ _Users_vinc17_software_darwinports_dports_devel_readline/work/ destroot/opt/local/lib/libreadline.dylib /opt/local/var/db/dports/software/readline/5.1.004_0/opt/local/ lib/libreadline.dylib /usr/lib/libreadline.dylib
But only /opt/local/lib/libreadline.dylib and /usr/lib/ libreadline.dylib should be available.
configure (normally?) doesn't look into /opt/local.
It completely depends on the environment variables. To benefit from MacPorts, I have:
C_INCLUDE_PATH=/Users/vinc17/include:/opt/local/include LIBRARY_PATH=/Users/vinc17/lib:/opt/local/lib
[...]