Re: 1.7.0 beta rc1: libcurl errors

2008-12-11 Thread Ryan Schmidt


On Dec 9, 2008, at 07:38, Jay Levitt wrote:


Does MacPorts log any history anywhere?  I don't think it does.


Nope, MacPorts writes no logfiles.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-11 Thread Ryan Schmidt


On Dec 9, 2008, at 07:20, Jay Levitt wrote:


Joshua Root wrote:


Could the wrong libcurl be picked up if there is something like
LDFLAGS=-L/opt/local/lib in the environment? If that's what  
happened to
Jay, it shouldn't be a problem with selfupdate because the  
environment

is sanitised.


I do, in fact, have that:

CPATH=/opt/local/include
CPPFLAGS=-I/opt/local/include
LDFLAGS=-L/opt/local/lib
LIBTOOLIZE=/opt/local/bin/glibtoolize
PATH=/usr/local/bin:/usr/local/sbin:/Users/jay/bin:/opt/local/bin:/ 
opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/ 
Applications/Utilities/diglloyd/disktester:/usr/local/git/bin:/opt/ 
local/lib/postgresql83/bin



Stuff in /usr/local can and does conflict with MacPorts-installed  
software. Perhaps you have a different version of curl in there. See  
what happens if you rename /usr/local to e.g. /usr/local-off.




___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-09 Thread Rainer Müller
Bryan Blackburn wrote:
 Considering that the MacPorts port clears configure.cppflags and
 configure.ldflags, I'm guessing the same should probably be done in
 macports::selfupdate?

MacPorts already removes $prefix/bin and $prefix/sbin from PATH on
configure. See MP_PATH_SCAN in aclocal.m4. This ensures that it not only
works on selfupdate, but also on reinstalling/upgrading from a source
tarball.

Rainer

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-09 Thread Jay Levitt

Bryan Blackburn wrote:

On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said:
I know this isn't a great bug report, because I already overwrote the fail 
case; sorry about that.


I upgraded from a DMG-installed 1.6.0 to a built-from-source 1.7.0 beta 1. 
I then updated a bunch of ports, but I don't think libcurl was one of 
them.  (Is there a log?  I don't think there is.)


Today, I tried using git, and got:

dyld: Library not loaded: /opt/local/lib/libcurl.4.dylib
  Referenced from: /opt/local/bin/git
  Reason: Incompatible library version: git requires version 6.0.0 or  
later, but libcurl.4.dylib provides version 5.0.0


Did you happen to activate an older version of the curl port?  What does
'port installed curl' say, as here, 7.19.2_0 is installed and libcurl has a
compat version of 6.0.0 and current 6.1.0.


Not intentionally.  I don't use curl directly, certainly not enough to know 
which version I need, so it would have been installed at some point with 
port install curl, possibly later upgraded with port upgrade curl, and 
then possibly cleaned up with port uninstall -f outdated if I saw multiple 
versions of it.


Does MacPorts log any history anywhere?  I don't think it does.  I do see 
two directories in /opt/local/var/macports/receipts/curl:


curl% ll
total 0
drwxr-xr-x  4 root  admin   136B Dec  8 15:17 7.19.2_0/
drwxr-xr-x  4 root  admin   136B Dec  8 15:10 7.19.2_0+ssl/

curl% ll 7.19.2_0
total 16
-rw-r--r--  1 root  admin   3.3K Dec  8 15:17 receipt.bz2
-rw-r--r--  1 root  admin   3.3K Dec  6 09:05 receipt.bz2.mpsaved
curl% ll 7.19.2_0+ssl
total 16
-rw-r--r--  1 root  admin   3.4K Dec  8 15:10 receipt.bz2
-rw-r--r--  1 root  admin   3.4K Dec  8 15:10 receipt.bz2.mpsaved




___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-09 Thread Jay Levitt

Joshua Root wrote:


Could the wrong libcurl be picked up if there is something like
LDFLAGS=-L/opt/local/lib in the environment? If that's what happened to
Jay, it shouldn't be a problem with selfupdate because the environment
is sanitised.


I do, in fact, have that:

CPATH=/opt/local/include
CPPFLAGS=-I/opt/local/include
LDFLAGS=-L/opt/local/lib
LIBTOOLIZE=/opt/local/bin/glibtoolize
PATH=/usr/local/bin:/usr/local/sbin:/Users/jay/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/Applications/Utilities/diglloyd/disktester:/usr/local/git/bin:/opt/local/lib/postgresql83/bin

I realized that, thanks to CrashPlan, I do in fact have a full backup of my 
system at many points-in-time, which should let me recreate the situation, 
assuming it didn't depend on some precise sequence of port installations.


What would be useful to you guys?  Are there files and links you want to 
know about, or verbose outputs of.. something..?



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-09 Thread Vincent Lefevre
On 2008-12-09 13:45:30 +0100, Rainer Müller wrote:
 MacPorts already removes $prefix/bin and $prefix/sbin from PATH on
 configure.

Does it also handle environment variables such as LIBRARY_PATH,
CPATH and C_INCLUDE_PATH?

-- 
Vincent Lefèvre [EMAIL PROTECTED] - 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)
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-09 Thread Joshua Root
Vincent Lefevre wrote:
 On 2008-12-09 13:45:30 +0100, Rainer Müller wrote:
 MacPorts already removes $prefix/bin and $prefix/sbin from PATH on
 configure.
 
 Does it also handle environment variables such as LIBRARY_PATH,
 CPATH and C_INCLUDE_PATH?

It clears the entire environment apart from the list of keep_vars.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


1.7.0 beta rc1: libcurl errors

2008-12-08 Thread Jay Levitt
I know this isn't a great bug report, because I already overwrote the fail 
case; sorry about that.


I upgraded from a DMG-installed 1.6.0 to a built-from-source 1.7.0 beta 1. 
I then updated a bunch of ports, but I don't think libcurl was one of them. 
 (Is there a log?  I don't think there is.)


Today, I tried using git, and got:

dyld: Library not loaded: /opt/local/lib/libcurl.4.dylib
  Referenced from: /opt/local/bin/git
  Reason: Incompatible library version: git requires version 6.0.0 or 
later, but libcurl.4.dylib provides version 5.0.0


I tried to rebuild the port, but the port command had the same problem:

sudo port clean git
couldn't load file /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib: 
dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10): Library 
not loaded: /opt/local/lib/libcurl.4.dylib

  Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib
  Reason: Incompatible library version: Pextlib.dylib requires version 
6.0.0 or later, but libcurl.4.dylib provides version 5.0.0

while executing
load /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib
(package ifneeded script)
invoked from within
package require Pextlib 1.0
(file /opt/local/bin/port line 40)

I tried upgrading to 1.7.0rc1, but IT had the same problem:

$ svn switch http://svn.macports.org/repository/macports/tags/release_1_7_0-rc1
$ ./configure;make;sudo make install
[...]
/usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl
can't find package Pextlib 1.0
while executing
package require Pextlib 1.0
(file /opt/local/share/macports/Tcl/registry1.0/receipt_flat.tcl line 37)
invoked from within
source /opt/local/share/macports/Tcl/registry1.0/receipt_flat.tcl
(package ifneeded script)
invoked from within
package require receipt_flat 1.0
(file /opt/local/share/macports/Tcl/registry1.0/registry.tcl line 35)
invoked from within
source /opt/local/share/macports/Tcl/registry1.0/registry.tcl
(package ifneeded script)
invoked from within
package require registry 1.0
(file src/dep_map_clean.tcl line 10)
make: *** [install] Error 1

Finally, I did make clean;make;sudo make install which succeeded.  I was 
then able to get things working:


$ sudo port clean git-core
Portfile changed since last build; discarding previous state.
---  Cleaning git-core
$ sudo port sync
$ sudo port install git-core
Error: Requested variants do not match original selection.
Please perform 'port clean curl' or specify the force option.
Error: The following dependencies failed to build: curl
Error: Status 1 encountered during processing.
$ sudo port clean curl
---  Cleaning curl
$ sudo port install curl
---  Activating curl @7.19.2_0
$ git version
git version 1.6.0.4
$

So, since I can't reproduce this anymore... consider this an FYI that 
something might be broken for people upgrading from 1.6.0.  Or it might not. 
 Probably one of the two.


Jay

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-08 Thread Bryan Blackburn
On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said:
 I know this isn't a great bug report, because I already overwrote the fail 
 case; sorry about that.

 I upgraded from a DMG-installed 1.6.0 to a built-from-source 1.7.0 beta 1. 
 I then updated a bunch of ports, but I don't think libcurl was one of 
 them.  (Is there a log?  I don't think there is.)

 Today, I tried using git, and got:

 dyld: Library not loaded: /opt/local/lib/libcurl.4.dylib
   Referenced from: /opt/local/bin/git
   Reason: Incompatible library version: git requires version 6.0.0 or  
 later, but libcurl.4.dylib provides version 5.0.0

Did you happen to activate an older version of the curl port?  What does
'port installed curl' say, as here, 7.19.2_0 is installed and libcurl has a
compat version of 6.0.0 and current 6.1.0.


 I tried to rebuild the port, but the port command had the same problem:

 sudo port clean git
 couldn't load file 
 /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib:  
 dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10): 
 Library not loaded: /opt/local/lib/libcurl.4.dylib
   Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib
   Reason: Incompatible library version: Pextlib.dylib requires version  
 6.0.0 or later, but libcurl.4.dylib provides version 5.0.0

This could be an issue with selfupdate as it should be linking Pextlib
against the system libcurl, not one found in MacPorts.  Will have to look
into this.

[...]
 I tried upgrading to 1.7.0rc1, but IT had the same problem:

 $ svn switch 
 http://svn.macports.org/repository/macports/tags/release_1_7_0-rc1
 $ ./configure;make;sudo make install
 [...]
 /usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl
 can't find package Pextlib 1.0

Probably the above issue I'm guessing.

[...]

 Finally, I did make clean;make;sudo make install which succeeded.  I was 
 then able to get things working:

Suggesting selfupdate is picking up the MacPorts one instead since make
should be seeing the system libcurl properly.


 $ sudo port clean git-core
 Portfile changed since last build; discarding previous state.
 ---  Cleaning git-core
 $ sudo port sync
 $ sudo port install git-core
 Error: Requested variants do not match original selection.
 Please perform 'port clean curl' or specify the force option.
 Error: The following dependencies failed to build: curl
 Error: Status 1 encountered during processing.

That's interesting, definitely sounds like you have some oddities with the
curl port, which would explain the git issues mentioned above.

Bryan


 $ sudo port clean curl
 ---  Cleaning curl
 $ sudo port install curl
 ---  Activating curl @7.19.2_0
 $ git version
 git version 1.6.0.4
 $

 So, since I can't reproduce this anymore... consider this an FYI that  
 something might be broken for people upgrading from 1.6.0.  Or it might 
 not.  Probably one of the two.

 Jay

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-08 Thread Ryan Schmidt

On Dec 8, 2008, at 15:41, Bryan Blackburn wrote:


On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said:

I tried to rebuild the port, but the port command had the same  
problem:


sudo port clean git
couldn't load file
/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib:
dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10):
Library not loaded: /opt/local/lib/libcurl.4.dylib
  Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/ 
Pextlib.dylib
  Reason: Incompatible library version: Pextlib.dylib requires  
version

6.0.0 or later, but libcurl.4.dylib provides version 5.0.0


This could be an issue with selfupdate as it should be linking Pextlib
against the system libcurl, not one found in MacPorts.  Will have  
to look

into this.


I remember when building MacPorts manually, it will link with its own  
ports, which isn't so great IMHO. Which is why I now build MacPorts  
through a script which first sets the PATH so it doesn't contain the  
MacPorts prefix. Like this:



#!/bin/bash

PREFIX=/mp

cd ~/macports/base
PATH=/bin:/sbin:/usr/bin:/usr/sbin \
./configure \
--prefix=$PREFIX \
--with-tclpackage=$PREFIX/Library/Tcl \
--with-install-user=rschmidt \
--with-install-group=admin \
--with-applications-dir=/Applications/mp \
--with-frameworks-dir=$PREFIX/Library/Frameworks \
--enable-readline || exit $?
make -j2 || exit $?
make install || exit $?
make clean || exit $?




___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-08 Thread Bryan Blackburn
On Mon, Dec 08, 2008 at 04:19:41PM -0600, Ryan Schmidt said:
 On Dec 8, 2008, at 15:41, Bryan Blackburn wrote:

 On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said:

 I tried to rebuild the port, but the port command had the same  
 problem:

 sudo port clean git
 couldn't load file
 /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib:
 dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10):
 Library not loaded: /opt/local/lib/libcurl.4.dylib
   Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/ 
 Pextlib.dylib
   Reason: Incompatible library version: Pextlib.dylib requires  
 version
 6.0.0 or later, but libcurl.4.dylib provides version 5.0.0

 This could be an issue with selfupdate as it should be linking Pextlib
 against the system libcurl, not one found in MacPorts.  Will have to 
 look
 into this.

 I remember when building MacPorts manually, it will link with its own  
 ports, which isn't so great IMHO. Which is why I now build MacPorts  
 through a script which first sets the PATH so it doesn't contain the  
 MacPorts prefix. Like this:

FYI I've never had MacPorts link against anything installed by MacPorts when
using configure/make/make install.  I do have the curl port installed by
Pextlib is still linked to the system libcurl...

Bryan

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-08 Thread Joshua Root
Bryan Blackburn wrote:
 On Mon, Dec 08, 2008 at 04:19:41PM -0600, Ryan Schmidt said:
 On Dec 8, 2008, at 15:41, Bryan Blackburn wrote:

 On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said:

 I tried to rebuild the port, but the port command had the same  
 problem:

 sudo port clean git
 couldn't load file
 /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib:
 dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10):
 Library not loaded: /opt/local/lib/libcurl.4.dylib
   Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/ 
 Pextlib.dylib
   Reason: Incompatible library version: Pextlib.dylib requires  
 version
 6.0.0 or later, but libcurl.4.dylib provides version 5.0.0
 This could be an issue with selfupdate as it should be linking Pextlib
 against the system libcurl, not one found in MacPorts.  Will have to 
 look
 into this.
 I remember when building MacPorts manually, it will link with its own  
 ports, which isn't so great IMHO. Which is why I now build MacPorts  
 through a script which first sets the PATH so it doesn't contain the  
 MacPorts prefix. Like this:
 
 FYI I've never had MacPorts link against anything installed by MacPorts when
 using configure/make/make install.  I do have the curl port installed by
 Pextlib is still linked to the system libcurl...

Could the wrong libcurl be picked up if there is something like
LDFLAGS=-L/opt/local/lib in the environment? If that's what happened to
Jay, it shouldn't be a problem with selfupdate because the environment
is sanitised.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


Re: 1.7.0 beta rc1: libcurl errors

2008-12-08 Thread Bryan Blackburn
On Tue, Dec 09, 2008 at 10:04:03AM +1100, Joshua Root said:
[...]
 
 Could the wrong libcurl be picked up if there is something like
 LDFLAGS=-L/opt/local/lib in the environment? If that's what happened to
 Jay, it shouldn't be a problem with selfupdate because the environment
 is sanitised.

Considering that the MacPorts port clears configure.cppflags and
configure.ldflags, I'm guessing the same should probably be done in
macports::selfupdate?

Bryan


 
 - Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users