The MacPorts project is pleased to announce the release of MacPorts v1.4.0. Change log is at <http://trac.macosforge.org/projects/macports/ browser/tags/release_1_4_0/base/ChangeLog>. Downloads are available at <http://trac.macosforge.org/projects/ macports/browser/downloads/MacPorts-1.4.0>. Thanks to all project members who contributed to this release, and especially to Juan Manuel Palacios, who served as release manager. Bugs may be filed at the <http://www.macports.org/?page_id=8>. We plan to release a v1.4.1 within weeks with some ongoing enhancements. Please note that our official plan is to build disk images only for 1.x.0 releases, and let subsequent point releases selfupdate from there. If you have a previous release of MacPorts installed, the easiest path to MacPorts 1.4.0 is simply "sudo port selfupdate". — MacPorts team
On 2007-04-05 12:26:10 -0700, James Berry wrote:
The MacPorts project is pleased to announce the release of MacPorts v1.4.0.
Change log is at <http://trac.macosforge.org/projects/macports/browser/tags/release_1_4_0/base/ChangeLog>. Downloads are available at <http://trac.macosforge.org/projects/macports/browser/downloads/MacPorts-1.4.0>.
There's still a bug when I try to build it: cc -dynamiclib -L/usr/local/lib -L/usr/lib -lcurl -lssl -lcrypto -lz Pextlib.o strsed.o fgetln.o md5cmd.o setmode.o xinstall.o find.o strcasecmp.o vercomp.o filemap.o sha1cmd.o compat.o curl.o rmd160cmd.o readline.o uid.o -o Pextlib.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4 -L/usr/local/lib -L/usr/lib -lcurl -lssl -lcrypto -lz -lreadline -lcrypto ld: warning -L: directory name (/usr/local/lib) does not exist ld: warning -L: directory name (/usr/local/lib) does not exist ld: Undefined symbols: _rl_completion_matches _rl_filename_completion_function _rl_username_completion_function /usr/bin/libtool: internal link edit command failed $ 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 /opt/local/var/db/dports/software/readline/5.2.001_0/opt/local/lib/libreadline.dylib /usr/lib/libreadline.dylib -- 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)
On Apr 5, 2007, at 4:46 PM, Vincent Lefevre wrote:
There's still a bug when I try to build it:
cc -dynamiclib -L/usr/local/lib -L/usr/lib -lcurl -lssl -lcrypto - lz Pextlib.o strsed.o fgetln.o md5cmd.o setmode.o xinstall.o find.o strcasecmp.o vercomp.o filemap.o sha1cmd.o compat.o curl.o rmd160cmd.o readline.o uid.o -o Pextlib.dylib -L/System/Library/ Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4 -L/usr/local/ lib -L/usr/lib -lcurl -lssl -lcrypto -lz -lreadline -lcrypto ld: warning -L: directory name (/usr/local/lib) does not exist ld: warning -L: directory name (/usr/local/lib) does not exist ld: Undefined symbols: _rl_completion_matches _rl_filename_completion_function _rl_username_completion_function /usr/bin/libtool: internal link edit command failed
$ 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 /opt/local/var/db/dports/software/readline/5.2.001_0/opt/local/lib/ libreadline.dylib /usr/lib/libreadline.dylib
The problem IIRC has to do with mismatched headers and library. So you'll want to do locate readline.h and see if there's a stray one (in /usr/local/include, probably) that's causing the build to choke. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
The problem IIRC has to do with mismatched headers and library.
Yes, probably because the Makefile is incorrect.
So you'll want to do
locate readline.h
and see if there's a stray one (in /usr/local/include, probably) that's causing the build to choke.
No: prunille:~> locate include/readline/readline.h /Developer/SDKs/MacOSX10.4u.sdk/usr/include/readline/readline.h /opt/local/include/readline/readline.h /opt/local/var/db/dports/build/_Users_vinc17_software_darwinports_dports_devel_readline/work/destroot/opt/local/include/readline/readline.h /opt/local/var/db/dports/software/readline/5.1.004_0/opt/local/include/readline/readline.h /opt/local/var/db/dports/software/readline/5.2.001_0/opt/local/include/readline/readline.h /usr/include/readline/readline.h The problem is a mismatch between Apple's linker and gcc. A -I/usr/include is ignored by gcc (because it is in the system path), while with -L/usr/lib, this directory has the precedence. In short, using -L/usr/lib is incorrect. -- 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)
On Apr 5, 2007, at 8:12 PM, Vincent Lefevre wrote:
On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
The problem IIRC has to do with mismatched headers and library.
Yes, probably because the Makefile is incorrect.
It is? Do you have a patch to fix it?
The problem is a mismatch between Apple's linker and gcc. A -I/usr/include is ignored by gcc (because it is in the system path), while with -L/usr/lib, this directory has the precedence. In short, using -L/usr/lib is incorrect.
I'm confused as to why you're seeing a build a problem if you don't have another readline installed. I've got both the system readline and macports readline installed and haven't seen that build error. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-04-06 09:31:56 -0400, Daniel J. Luke wrote:
On Apr 5, 2007, at 8:12 PM, Vincent Lefevre wrote:
On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
The problem IIRC has to do with mismatched headers and library.
Yes, probably because the Makefile is incorrect.
It is? Do you have a patch to fix it?
The use of -L/usr/lib is incorrect as it is not consistent with the include search path. For some reason, CURL_CONFIG seems to be set to /usr/bin/curl-config, though "which curl-config" outputs /opt/local/bin/curl-config (that's a bug since it can lead to inconsistent paths), and there's a bug in /usr/bin/curl-config too: prunille:~> /usr/bin/curl-config --libs -L/usr/lib -lcurl -lssl -lcrypto -lz ^^^^^^^^^^ This shouldn't be there.
The problem is a mismatch between Apple's linker and gcc. A -I/usr/include is ignored by gcc (because it is in the system path), while with -L/usr/lib, this directory has the precedence. In short, using -L/usr/lib is incorrect.
I'm confused as to why you're seeing a build a problem if you don't have another readline installed.
I have one in /opt/local and this prefix is included in my various path environment variables. -- 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)
On Apr 6, 2007, at 10:37 AM, Vincent Lefevre wrote:
For some reason, CURL_CONFIG seems to be set to /usr/bin/curl-config, though "which curl-config" outputs /opt/local/bin/curl-config (that's a bug since it can lead to inconsistent paths),
I believe that the configure script was modified to not look in $ {prefix} as it could lead to bootstrap issues. (yep, see the OD_PATH_SCAN macro)
The problem is a mismatch between Apple's linker and gcc. A -I/usr/include is ignored by gcc (because it is in the system path), while with -L/usr/lib, this directory has the precedence. In short, using -L/usr/lib is incorrect.
I'm confused as to why you're seeing a build a problem if you don't have another readline installed.
I have one in /opt/local and this prefix is included in my various path environment variables.
I've got CPPFLAGS and LDFLAGS set on one of my machines with macports readline installed and it doesn't have this problem. Do you have something else set that if you unset, the build works? -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-04-06 16:37:09 +0200, Vincent Lefevre wrote:
On 2007-04-06 09:31:56 -0400, Daniel J. Luke wrote:
On Apr 5, 2007, at 8:12 PM, Vincent Lefevre wrote:
On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
The problem IIRC has to do with mismatched headers and library.
Yes, probably because the Makefile is incorrect.
It is? Do you have a patch to fix it?
The use of -L/usr/lib is incorrect as it is not consistent with the include search path. For some reason, CURL_CONFIG seems to be set to /usr/bin/curl-config, though "which curl-config" outputs /opt/local/bin/curl-config (that's a bug since it can lead to inconsistent paths), and there's a bug in /usr/bin/curl-config too:
prunille:~> /usr/bin/curl-config --libs -L/usr/lib -lcurl -lssl -lcrypto -lz ^^^^^^^^^^ This shouldn't be there.
Well, I think this is a more general problem, and pkg-config does the right thing by providing --libs-only-l and --libs-only-other. The rule is: * If you are linking with curl only, using the -L flags may be safe. * If you are linking with other libraries (e.g. readline), then the -L flags must not be used, because they may conflict with each other. The cleanest way to avoid such a conflict is to have a global setting, e.g. via LIBRARY_PATH and ditto for the include search path. So, the -L flags should be filtered out with sed 's/-L[^ ]*//g', and with --cflags, the -I flags should be filtered out with sed 's/-I[^ ]*//g'. The attach patch fixes the problem here. -- 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)
On 2007-04-06 10:55:20 -0400, Daniel J. Luke wrote:
On Apr 6, 2007, at 10:37 AM, Vincent Lefevre wrote:
For some reason, CURL_CONFIG seems to be set to /usr/bin/curl-config, though "which curl-config" outputs /opt/local/bin/curl-config (that's a bug since it can lead to inconsistent paths),
I believe that the configure script was modified to not look in ${prefix} as it could lead to bootstrap issues. (yep, see the OD_PATH_SCAN macro)
If it doesn't want to look at ${prefix}, it should do that *completely*.
I have one in /opt/local and this prefix is included in my various path environment variables.
I've got CPPFLAGS and LDFLAGS set on one of my machines with macports readline installed and it doesn't have this problem.
I'm not talking about the flags, but about the path variables, as described by the gcc documentation (see LIBRARY_PATH, CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH). The configure script should probably remove ${prefix}-based paths from these variables. -- 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)
participants (3)
-
Daniel J. Luke
-
James Berry
-
Vincent Lefevre