BUG: qt3-mac staging fails

[andre.berger@…]

Hi! I can't install qt3-mac, here's what happens:

port install qt3-mac ---> Fetching qt3-mac ---> Attempting to fetch qt-mac-free-3.3.4.tar.bz2 from ​ftp://ftp.trolltech.com/qt/source/ ---> Verifying checksum(s) for qt3-mac ---> Extracting qt3-mac ---> Applying patches to qt3-mac ---> Configuring qt3-mac ---> Building qt3-mac with target symlinks src-qmake src-moc sub-src sub-tools ---> Staging qt3-mac into destroot Error: Target com.apple.destroot returned: shell command "ranlib -s /opt/darwinports/dports/aqua/qt3-mac/work/destroot/usr/local/lib/libdesignercore.a" returned error 1 Command output: ranlib: can't open file: /opt/darwinports/dports/aqua/qt3-mac/work/destroot/usr/local/lib/libdesignercore.a (No such file or directory)

Here's what's in the directory:

$ ls /opt/darwinports/dports/aqua/qt3-mac/work/destroot/usr/local/lib/ qt3-plugins

My $prefix is set to /usr/local, with /usr/local being a symlink to /opt, the directory where the files reside. I did that a long time ago for two reasons: Most applications, self-compiled or not, default to / usr/local to look for libraries not supplied by the OS, and installation location. On the other hand, I wanted a convenient way to back up local additions, so I made a top level directory. I have never had any problem with Darwin "sharing" this setup so far.

Best regards,

-Andre

[travis@…]

I can confirm the bug as reported by Andre. I get the exact same error, with ranlib trying to access a file, libdesignercore.a, that isn't where it expects it to be. After some poking around, I discovered that the file is in the directory:

/opt/local/var/db/dports/build/ file._opt_local_var_db_dports_sources_rsync.rsync.opendarwin.org_dpupdate_dports_aqua_qt3-mac/ work/destroot/private/opt/local/lib/

I hope that additional information is helpful.

[opendarwin@…]

I have the same problem. This is probably related to the fact that /opt is a symlink to /private/opt on my system.

If the install was made directly to the hard drive, it would work fine because the two paths are equivalent. Since it's to a relocated root, and the link's not there, /opt and /private/opt aren't equivalent.

This is on a macbook pro, OSX 10.4.5. The directory was set up that way by default.

[opendarwin@…]

I was able to solve this problem but changing all of the /opt paths in ports.conf to /private/opt.

This is functionally equivalent to my old setup, since I can still refer to everything using /opt because of the link, but avoids the problem since port doesn't make use of the link when it builds the package.

DarwinPorts could sidestep this problem if it resolved links in all of the paths in ports.conf before using them.

[markd@…]

Installing DP in /usr isn't something that has a true fix and is to be avoided.