Hello everyone! I just tagged 1.4.0-rc2 and posted corresponding test tarballs and checksums to our downloads directory. Those of you keeping track of svn commits should know about the changes that took place since rc1, those of you that don't please be patient, I'll update the ChangeLog as I get a chance through out the day. In any case, there have been changes to the release_1_4 branch so getting some testing on rc2 would be good! Just the same, if anything comes up please file a ticket in trac and assign it to the "MacPorts 1.4" milestone, base component (forwarding the ticket number to this list, thanks!). Does anyone have any compelling reason why I should keep the rc1 tarballs around...? I'm inclined to deleting them. Final 1.4 release shouldn't be too far now (famous last words! ...just kidding ;-). Regards and thanks to all for your help,... -jmpp
Juan Manuel Palacios wrote:
Hello everyone! I just tagged 1.4.0-rc2 and posted corresponding test tarballs and checksums to our downloads directory. Those of you keeping track of svn commits should know about the changes that took place since rc1, those of you that don't please be patient, I'll update the ChangeLog as I get a chance through out the day. In any case, there have been changes to the release_1_4 branch so getting some testing on rc2 would be good! Just the same, if anything comes up please file a ticket in trac and assign it to the "MacPorts 1.4" milestone, base component (forwarding the ticket number to this list, thanks!).
I'm trying to build 1.4 rc 2 for testing purposes with PortAuthority, and it's not building because it requires a threaded build of Tcl. Is there any way to patch the configure file so that it links against the Tcl in /System/Library directory? How do others handle this? -- Kevin Walzer Code by Kevin http://www.codebykevin.com
Kevin Walzer wrote:
Juan Manuel Palacios wrote:
Hello everyone! I just tagged 1.4.0-rc2 and posted corresponding test tarballs and checksums to our downloads directory. Those of you keeping track of svn commits should know about the changes that took place since rc1, those of you that don't please be patient, I'll update the ChangeLog as I get a chance through out the day. In any case, there have been changes to the release_1_4 branch so getting some testing on rc2 would be good! Just the same, if anything comes up please file a ticket in trac and assign it to the "MacPorts 1.4" milestone, base component (forwarding the ticket number to this list, thanks!).
I'm trying to build 1.4 rc 2 for testing purposes with PortAuthority, and it's not building because it requires a threaded build of Tcl. Is there any way to patch the configure file so that it links against the Tcl in /System/Library directory? How do others handle this?
Whoops, please disregard. I just noticed that configure was picking up a non-threaded build of Tcl from my Fink install. I moved /sw out of my path and things are building fine. -- Kevin Walzer Code by Kevin http://www.codebykevin.com
On Mar 14, 2007, at 09:47, Juan Manuel Palacios wrote:
Hello everyone! I just tagged 1.4.0-rc2 and posted corresponding test tarballs and checksums to our downloads directory. Those of you keeping track of svn commits should know about the changes that took place since rc1, those of you that don't please be patient, I'll update the ChangeLog as I get a chance through out the day. In any case, there have been changes to the release_1_4 branch so getting some testing on rc2 would be good! Just the same, if anything comes up please file a ticket in trac and assign it to the "MacPorts 1.4" milestone, base component (forwarding the ticket number to this list, thanks!).
I didn't try 1.4rc1... How do I try 1.4rc2? If I have a working copy of the release_1_4 branch, do I just configure, make, sudo make install? Does it just overwrite my existing 1.3.2 installation? Anything else I need to do to make it work? Anything to watch out for? The only way I've ever upgraded MacPorts in the past was to use sudo port selfupdate so I just want to make sure I don't hose something here.
On Mar 14, 2007, at 5:11 PM, Ryan Schmidt wrote:
I didn't try 1.4rc1... How do I try 1.4rc2? If I have a working copy of the release_1_4 branch, do I just configure, make, sudo make install?
Yes.
Does it just overwrite my existing 1.3.2 installation?
Yes.
Anything else I need to do to make it work?
No.
Anything to watch out for?
It's pre-release software. There may be bugs. If you find any, file a ticket and assign it the 1.4 milestone.
The only way I've ever upgraded MacPorts in the past was to use sudo port selfupdate so I just want to make sure I don't hose something here.
selfupdate basically does a ./configure, make, sudo make install for you. The only caveat to be careful of is if you've installed something like Tcl/Tk Aqua, which replaces /usr/bin/tclsh (or as Kevin Walzer pointed out, if you have tclsh installed from fink) it can cause problems. The only real caveat I can think of is if the official 1.4 release is different than 1.4rc2, a `port selfupdate` won't pick it up, since it will think both versions are 1.400. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Mar 14, 2007, at 6:00 PM, Kevin Ballard wrote:
On Mar 14, 2007, at 5:11 PM, Ryan Schmidt wrote:
I didn't try 1.4rc1... How do I try 1.4rc2? If I have a working copy of the release_1_4 branch, do I just configure, make, sudo make install?
Yes.
You can also either check out from the tags dir in our repo, http://svn.macports.org/repository/macports/tags/release_1_4_0-rc2, or download the equivalent tarball snapshots (.gz or .bz2, which ever you prefer) from the downloads directory, http://svn.macports.org/repository/macports/downloads/MacPorts-1.4 ---snip---
The only real caveat I can think of is if the official 1.4 release is different than 1.4rc2, a `port selfupdate` won't pick it up, since it will think both versions are 1.400.
This is certainly an issue for anyone installing from the 1.4 release branch (or its snapshots), as the version number there is already 1.4. When released, selfupdate wont notice any difference, but then again we can presume people installing from svn are savvy enough to know either about forcing the upgrade or how to install from source ;-) Regards,... -jmpp
On 2007-03-14 18:00:08 -0400, Kevin Ballard wrote:
On Mar 14, 2007, at 5:11 PM, Ryan Schmidt wrote:
I didn't try 1.4rc1... How do I try 1.4rc2? If I have a working copy of the release_1_4 branch, do I just configure, make, sudo make install?
Yes.
Build fails here: [...] 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 make[2]: *** [Pextlib.dylib] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 -- 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)
Le 15 mars 07 à 11:44, Vincent Lefevre a écrit :
On 2007-03-14 18:00:08 -0400, Kevin Ballard wrote:
On Mar 14, 2007, at 5:11 PM, Ryan Schmidt wrote:
I didn't try 1.4rc1... How do I try 1.4rc2? If I have a working copy of the release_1_4 branch, do I just configure, make, sudo make install?
Yes.
Build fails here:
[...] 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 make[2]: *** [Pextlib.dylib] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1
This is bug #10651 https://svn.macosforge.org/projects/macports/ticket/10651 Please uninstall your other copy of readline and try again. Paul
On 2007-03-15 12:05:03 +0900, Paul Guyot wrote:
Please uninstall your other copy of readline and try again.
I don't want to do that as ports depend on it: prunille:~> sudo port -v uninstall readline ---> Unable to uninstall readline 5.1.004_0, the following ports depend on it: ---> python24 ---> p5-term-readline-gnu ---> GiNaC ---> GiNaC ---> gnupg ---> gnupg ---> lftp ---> gnupg ---> p5-term-readline-gnu ---> gnupg ---> GiNaC ---> gnuplot ---> guile ---> gnupg ---> GiNaC ---> GiNaC ---> calc ---> calc ---> sqlite3 Error: port uninstall failed: Please uninstall the ports that depend on readline first. -- 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-03-15 12:05:03 +0900, Paul Guyot wrote:
Please uninstall your other copy of readline and try again.
I don't want to do that as ports depend on it:
It's not what I meant. You probably have three copies of readline: - System's readline - MP's readline - Another copy. This is the other copy that makes MacPorts choke, because of diverging priorities in /usr/ & /usr/local between compilation (/usr/ include, /usr/local/include) and linking (/usr/lib, /usr/local/lib). I'll bet the configure script thinks your system has both old-style readline functions and new-style readline functions. Paul
On 2007-03-15 12:41:44 +0900, Paul Guyot wrote:
On 2007-03-15 12:05:03 +0900, Paul Guyot wrote:
Please uninstall your other copy of readline and try again.
I don't want to do that as ports depend on it:
It's not what I meant. You probably have three copies of readline: - System's readline - MP's readline - Another copy.
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.
This is the other copy that makes MacPorts choke, because of diverging priorities in /usr/ & /usr/local between compilation (/usr/include, /usr/local/include) and linking (/usr/lib, /usr/local/lib).
I don't have a /usr/local/lib directory (as said in the make output). -- 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)
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. And the linker didn't use /opt/local/lib, to quote your log excerpt:
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
What does "locate readline.h" print out? Paul
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 Anyway, since -L/usr/lib is used, it will have the precedence over /opt/local/include and /usr/lib/libreadline.dylib will be used. And indeed, no problem with it: if I unset LIBRARY_PATH, the build still fails.
And the linker didn't use /opt/local/lib, to quote your log excerpt:
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
What does "locate readline.h" print out?
In short, I have: /opt/local/include/readline/readline.h /usr/include/readline/readline.h BTW, I've noticed a bug: -L/usr/local/lib -L/usr/lib is used at link time, but only -I"/usr/include" is used at compile time, instead of -I/usr/local/include -I/usr/include. Now, this doesn't explain the problem I have. If I unset C_INCLUDE_PATH, then the build doesn't fail. So, this means that readline.h is taken from /opt/local/include/readline/readline.h (with my C_INCLUDE_PATH), even though -I"/usr/include" is used. Any explanation? -- 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-03-15 14:37:08 +0100, Vincent Lefevre wrote:
If I unset C_INCLUDE_PATH, then the build doesn't fail. So, this means that readline.h is taken from /opt/local/include/readline/readline.h (with my C_INCLUDE_PATH), even though -I"/usr/include" is used. Any explanation?
This is confirmed with: prunille:~> cat test.c #include <readline/readline.h> prunille:~> gcc -E -I/usr/include test.c | grep readline/readline.h # 1 "/opt/local/include/readline/readline.h" 1 3 [...] Similar problem under Linux. BTW, this bug seems to occur only with /usr/include (perhaps because it is a system directory). The gcc man page says: -isystem dir Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. so that one should have a path like: /usr/include /opt/local/include /usr/include the first /usr/include being specified by -I and the last one being in the standard system directories list. As MacPorts needs /usr/include, it should probably unset CPATH, C_INCLUDE_PATH and LIBRARY_PATH. -- 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)
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
[...]
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)
My understanding was that configure generally added directories based on --prefix for include and lib paths, though a recent program I compiled only used it for lib and ignored it for include. On Mar 15, 2007, at 6:03 AM, Paul Guyot wrote:
configure (normally?) doesn't look into /opt/local.
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
participants (6)
-
Juan Manuel Palacios
-
Kevin Ballard
-
Kevin Walzer
-
Paul Guyot
-
Ryan Schmidt
-
Vincent Lefevre