On Aug 21, 2007, at 16:49, Stephen Bannasch wrote:
Reading Ryan's last message. I realized that my problem could be interactions with libraries I had already installed into /usr/local so I tried this:
$ sudo mv /usr/local /usr/localx $ sudo port install db44 Library not loaded: /usr/local/lib/libreadline.5.1.dylib Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/ Pextlib.dylib Reason: image not found while executing "load /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib" ("package ifneeded" script) invoked from within "package require Pextlib 1.0" (procedure "mportinit" line 365) invoked from within "mportinit ui_options global_options global_variations" Error: /opt/local/bin/port: Failed to initialize MacPorts, Library not loaded: /usr/local/lib/libreadline.5.1.dylib Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/ Pextlib.dylib Reason: image not found
Clue ...!
OK ... so a bunch of my ports were probably built using things in / usr/local -- and this isn't useful.
Is there a quick way I can tell ports to build everything again?
No... And in this case, it's MacPorts itself that was built against readline, so you'll have to reinstall MacPorts. You could download the 1.5.0 disk image from www.macports.org and install it, then you should (provided you've moved /usr/local out of the way) be able to selfupdate to 1.5.2.
Is there a better way to have code built from source in /usr/local and other code built with ports (that use some libraries in common) and not have them interact without temporarily renaming /usr/local?
No... I recommend you have nothing directly in /usr/local. If possible, install that software with MacPorts as well. If no portfiles exist, you could write them and contribute them to the project. Portfiles are fairly easy to write. You can look at how the existing portfiles are written, or read the new manual that's being developed.