wiki:ProblemHotlist

Version 102 (modified by cooljeanius (Eric Gallager), 12 years ago) (diff)

one more way to interactively login as root

Problem Hotlist

Table of Contents

  1. MacPorts port installs fail on OS X Lion 10.7 after a fresh App Store installation of Xcode
  2. MacPorts stops working after installing Xcode 4.3
    1. Command Line Tools
    2. xcode-select
    3. Xcode License Agreement
  3. Error message from "port upgrade outdated": uninstall failure: "an invalid entry was passed"
  4. A port build fails on Snow Leopard with: "file is not of required architecture"
  5. A port fails to build when using Xcode 4
    1. Xcode 4.2 and later
    2. Xcode 4.0 and 4.1
  6. Incompatible library version: X requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
  7. man port fails with error message
  8. port fails with: Image error: /opt/local/bin/a2p…
  9. Fetch failures
  10. Image error: /opt/local/bin/xmlwf already exists and does not belong to a registered port
  11. A command failed to run with a message referring to libpng12.0.dylib
  12. A port failed to build with a message referring to 1/lib: No such file or directory
  13. Corrupt Filemap
  14. Hanging commands on Mountain Lion

MacPorts port installs fail on OS X Lion 10.7 after a fresh App Store installation of Xcode

The port command will remind you to install Xcode (or upgrade if you have an old version lying around from a previous installation of OS X). This is most easily accomplished using the "App Store" application on your Mac, which requires an Apple ID. Xcode 4.5 is the version currently available for Lion from the App Store.

However, as with Xcode 4.3 (below), the command line tools required for the build process are not installed automatically and require an additional manual step to install the tools through Xcode's preferences.

MacPorts stops working after installing Xcode 4.3

Support for Xcode 4.3 was added in MacPorts 2.0.4. If you have an earlier version of MacPorts, you will need to upgrade to be able to use Xcode 4.3.

Command Line Tools

Xcode 4.3 does not include a fully working set of command line tools by default. Nothing will build without it, despite the fact that xcode-select and which make may return correct values.

You must open Xcode, go to Preferences, and download this component from the Downloads section. You will require an Apple ID to download the component.

xcode-select

There have been reports of xcode-select not pointing to the new Xcode location for some users after upgrading to 4.3. If you are having problems even with the latest MacPorts version and xcode-select -print-path does not print /Applications/Xcode.app/Contents/Developer on your system, or 

Warning: Xcode appears to be installed but xcodebuild is unusable; some ports will likely fail to build.

then you need to run: 

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

This is particularly important for people who have error messages referring to their old compiler locations after installing Xcode 4.3: you need to reinstall the package that stored the old compiler location if you see an error message like this: 

error: can't exec '/Developer/usr/bin/<compiler>' (No such file or directory)

So far this error is seen in previously-built perl and python when building perl or python modules. For example, if a py27-xxxx port fails to install and the log contains error messages of this type, try reinstalling the main python27 port with: 

sudo port -n upgrade --force python27

Note you might have an older version of the xcode-select tool in case you installed Xcode 4.2 after installing the Mac OS X 10.7.3 update. If the command xcode-select -version returns version 2003 this is from Xcode 4.2 and we recommend to install the update once again with the ​Mac OS X 10.7.3 combo updater. The current xcode-select version that comes with Mac OS X 10.7.3 identifies itself as version 2307.

Xcode License Agreement

When attempting to build a port which compiles an OS X app (e.g., gimp-app), the compilation may fail with an xcodebuild error. One of the possible causes of this is that an initial run of xcodebuild from the terminal may be needed to accept the EULA before any compilation can proceed. Run: 

xcodebuild -license

from a terminal window and follow the prompts. After accepting the EULA, rebuild the port again.

With some ports and some versions of Xcode (e.g. libunwind-headers with Xcode 4.4+) you may need to accept the license as root, i.e.: 

sudo xcodebuild -license

Error message from "port upgrade outdated": uninstall failure: "an invalid entry was passed"

Before MacPorts 2.1.3 it was possible to leave the registry in an inconsistent state if an uninstallation was interrupted. Although this has been fixed in version 2.1.3, the fix does not cure a previously corrupt registry.

The perl script attached to the ticket ​about this bug fixes the registry. The direct link is ​here.

A port build fails on Snow Leopard with: "file is not of required architecture"

If you had MacPorts installed before upgrading to Snow Leopard, see Migration.

A port fails to build when using Xcode 4

gcc has been the compiler collection MacPorts has used by default up until Xcode 4, in which Apple has switched to the llvm/clang compiler collection. These are new compilers and many programs have not yet been tested with them, and some ports will fail as a result. Using a different compiler may work better for a particular port. If the below workarounds enable you to install a port that failed with its default compiler, file a ticket and let us know so we can fix it. Portfile authors, see wiki:PortfileRecipes#compiler.

Xcode 4.2 and later

If a port foo fails to build and you're using Xcode 4.2 or later, the default compiler is clang; try compiling with llvm-gcc-4.2 instead: 

sudo port clean foo
sudo port install foo configure.compiler=llvm-gcc-4.2

If that fails, try installing the apple-gcc42 port and compiling with that: 

sudo port clean foo
sudo port install apple-gcc42
sudo port install foo configure.compiler=apple-gcc-4.2

Xcode 4.0 and 4.1

If a port foo fails to build and you're using Xcode 4.0 or 4.1, the default compiler is llvm-gcc-4.2; try compiling with clang instead: 

sudo port clean foo
sudo port install foo configure.compiler=clang

If that fails, try using gcc-4.2: 

sudo port clean foo
sudo port install foo configure.compiler=gcc-4.2

Incompatible library version: X requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

You might see this error when running a program, or in the main.log or config.log when a port fails to configure or build: 

dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
  Referenced from: /path/to/X
  Reason: Incompatible library version: X requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

This usually means libiconv is installed for the wrong architecture(s) and needs to be rebuilt. To rebuild libiconv: 

sudo port -n upgrade --force libiconv

But if libiconv's architecture was wrong, it's likely other ports have the similar problem. The usual reason for architecture mismatches is that you migrated from Leopard or earlier to Snow Leopard or later and did not follow the migration instructions. Another possible culprit is installing a third-party software package that was itself created using MacPorts, which overwrote some of your MacPorts files; see #xmlwf for more on this.

The error message is confusing. What OS X should be saying is: "The program or library X is linked with /opt/local/lib/libiconv.2.dylib and requires version 8.0.0 of that library. /opt/local/lib/libiconv.2.dylib is at least version 8.0.0, but it's built for the wrong architecture, so I'm going to look around for another libiconv.2.dylib. Ok, I found /usr/lib/libiconv.2.dylib and it's built for the right architectures, so I'll use that instead. Wait, /usr/lib/libiconv.2.dylib is only version 7.0.0. That's too old for X. I'll display an error message that the version is too old."

Another possible culprit is that you have DYLD_LIBRARY_PATH set in your environment; if so, try unsetting it.

man port fails with error message

Error message:

$ man port
Cannot open the message catalog "man" for locale "de_DE.UTF-8" (NLSPATH="<none>")
No manual entry for port

Workaround:

Add the following line to your .profile or .bash_profile. 

unset MANPATH

Ticket: #13444

port fails with: Image error: /opt/local/bin/a2p…

Error message:

Error: Activating perl5 @5.12.3_1 failed: Image error: /opt/local/bin/a2p is being used by the active perl5.8 port.  Please deactivate this port first, or use the -f flag to force the activation.

The perl5.8, perl5.10 and perl5.12 ports used to conflict with each other unless a particular variant was selected. This has now been solved by suffixing their binaries with a version number, and the perl5 port installs links without any suffix. The old versions of perl5.x conflict with the current version of perl5.

Fix:
To fix this issue, upgrade whichever of the above ports that you have installed. 

port upgrade installed and \( perl5.8 perl5.10 perl5.12 \)

Fetch failures

If fetch failed for a port, you can still get the distfile from anywhere else. For example, the ​main MacPorts distfiles mirror contains most ports' distfiles, or maybe the homepage of the software lists alternative download locations for source tarballs. Just download the distfile and save it to the path shown by port distfiles <portname>. Make sure you get a file with exactly the same name (watch out for .tar.gz and .tar.bz2!) If a port clean --all has been done the distfile directory will have been removed. The directory for each port is created at the beginning of the fetch phase. After placing the distfile, run port install <portname>again.

Note: Checksum failures after a fetch are typically a separate issue. See the FAQ.

Image error: /opt/local/bin/xmlwf already exists and does not belong to a registered port

When installing a port with MacPorts, you encounter this error: 

Error: Target org.macports.activate returned: Image error: /opt/local/bin/xmlwf already exists and does not belong to a registered port.  Unable to activate port expat.

xmlwf is a part of the expat port (which is a dependency of many other ports, and thus is likely to be one of the first ports to ever get installed), but for some reason this file already exists on your computer, and MacPorts did not install it.

One possible reason for this is that you have installed a 3rd-party software package—possibly ​gprolog or ​swi-prolog or ​SMBup—which was itself built with MacPorts, set to its default prefix, and therefore conflicts with your normal use of MacPorts in its default prefix. The developers of the 3rd-party package you installed should not have distributed their software in this manner; they should have configured MacPorts in a custom prefix instead, one that is unique to their software. (For example, in the case of swi-prolog, /usr/local/swi-prolog or /opt/swi-prolog would be good choices.)

Another possible reason is that you previously had MacPorts (and expat and probably other ports) installed, then somehow uninstalled MacPorts itself, or at least its registry of which ports are installed, without actually uninstalling those ports, and have now installed MacPorts again with a clean registry, which therefore thinks no ports are installed, though some still are.

Either way, the cleanest solution at this point is to follow the ​MacPorts uninstallation instructions. This will remove the 3rd-party software package that installed itself unannounced into MacPorts' prefix, and/or ports installed by your prior MacPorts installation. Then you can ​install MacPorts again.

A command failed to run with a message referring to libpng12.0.dylib

Error message:

dyld: Library not loaded: /opt/local/lib/libpng12.0.dylib

Explanation:
When the libpng port was updated from 1.2.x to 1.4.x, the libpng library version changed. Software always links against a specific library version, so the ports you currently have installed that depend on libpng are linked against a now-nonexistent version of the libpng library. To fix this problem, all ports that depend on libpng will need to be rebuilt so that they link with the new version of the libpng library. This may be quite a few ports.

Workaround:
We have tried to find all affected ports and incremented the revision number. In most cases a simple upgrade should get them all fixed. 

sudo port selfupdate
sudo port upgrade outdated

If this does not help, force a rebuild of the port in question by using the following command: 

sudo port -n upgrade --force $portname

You should also ​file a ticket against the port in question.

A port failed to build with a message referring to 1/lib: No such file or directory

Error message:

apple-darwin9-gcc-4.0.1: 1/lib: No such file or directory
make: *** Error 1

Explanation:
When upgrading from Tiger to Leopard without removing the previous Mac OS version, updated versions of some libraries in /usr/ and /usr/lib/ are moved from /old/path/ to /old/path 1/. Notice the space before 1. This makes some configure scripts build bad build instructions, making the build phases of several ports fail.

Two incriminated directories have been encountered : 

/usr/X11R6 1/
/usr/lib/ruby 1/

Workaround:

In order to fix this problem, you can remove the backups created by the installers, and then clean the work directory of the failed port so that its configure script will be re-run: 

port clean --work <port>

Corrupt Filemap

Error message:

Error: unknown node kind in database (database is corrupted?)

Workaround:

Probably something went wrong while a port was being (un)installed or (de)activated, such as a kernel panic or the machine losing power. You can fix the database file (/opt/local/var/macports/receipts/file_map.db) by downloading the following script: 

http://svn.macports.org/repository/macports/contrib/repairfilemap/repairfilemap.tcl

Follow the instructions in the comments at the beginning of the script. You can invoke the script by typing: 

chmod +x repairfilemap.tcl
sudo ./repairfilemap.tcl

Hanging commands on Mountain Lion

Symptom

Running MacPorts 2.1.3 or older under a root login shell on Mountain Lion may hang indefinitely; this is due to ​certain changes in CoreFoundation. A workaround has been committed to trunk and will be released in a future version of MacPorts.

Workaround

The recommended way to avoid this issue is to avoid running MacPorts in root login shells. Non-login root shells are fine.

DO DON’T
Non-interactive sudo port …
su -c port … 		su - -c port …
Interactive sudo -s
su 		sudo -i
sudo su -
su -
login root

If you absolutely must use a root login shell, you can

  1. run MacPorts from trunk, or
  2. work around the problem by setting __CFPREFERENCES_AVOID_DAEMON to “1” in the environment and configuring MacPorts to preserve it in macports.conf: 
    extra_env   __CFPREFERENCES_AVOID_DAEMON

Note that using extra_env is unsupported.