F.A.Q. - 6. Compile Problems - General

A: Read the docs next time. To compile packages from source, you must install the Developer Tools, which among other stuff contains the C compiler, cc.

A: You need to install the Developer Tools.

A: if your message is of the form

make: command not found

or

Can't exec "make": 
No such file or directory at /opt/sw/lib/perl5/Fink/Services.pm line 190.

It means you need to install the Developer Tools.

On the other hand, if your error message looks like

make: illegal option -- C

then you've replaced the GNU version of the make utility installed as part of the Developer Tools with a BSD version of make. Many packages rely on special features only supported by GNU make. Make sure that /usr/bin/make is a symlink to gnumake, not bsdmake. Furthermore, make sure that /usr/local/bin/ does not contain another copy of make.

A: If you're seeing this:

Unknown option: 1 Usage: head [-options] <url>...

followed by a list of option descriptions, you have a broken head executable. This happens when you install the Perl libwww library on an HFS+ system volume. It tries to create a new command /usr/bin/HEAD, which overwrites the existing head command because the file system is case-insensitive. head is a standard command used in many shell scripts and Makefiles. You need to get the original head executable back if you want to use Fink.

The bootstrap script of the source release now checks for this, but you can still run into it if you use the binary release for first-time installation or install libwww after you installed Fink.

This problem has also been reported due to the installation of /opt/sw/bin/HEAD (not by any Fink package). This is easier to solve: rename /opt/sw/bin/HEAD.

A: This occasionally happens with splitoff packages (i.e. the ones with -dev, -shlibs, etc.) when a file gets moved from one part of the splitoff to another (e.g. from foo to foo-shlibs. What you can do is overwrite the file with that from the package you are trying to install (since they are nominally the same):

sudo dpkg -i --force-overwrite filename
        

where filename is the .deb file corresponding to the package that you are trying to install.

A: If you have StuffIt Pro installed, it could be that you have "Archive Via Real Name" mode enabled. Check for a StuffIt preference pane in the System Preferences tool, and disable "ArchiveViaRealName" if it's enabled. It contains a buggy reimplementation of a few important system calls that will cause a number of strange and transient errors such as this.

Otherwise, an mv error typically means that another error happened earlier in the build, but the build process didn't stop. To track down the offending file(s), search in the output of the build for the nonexistent file, e.g. if you have something like:

mv /opt/sw/src/root-foo-0.1.2-3/opt/sw/lib/libbar*.dylib \
/opt/sw/src/root-foo-shlibs-0.1.2-3/opt/sw/lib/ 
mv: cannot stat `/opt/sw/src/root-foo-0.1.2-3/opt/sw/lib/libbar*.dylib': 
No such file or directory 
### execution of mv failed, exit code 1 
Failed: installing foo-0.1.2-3 failed

then you should look for libbar somewhere further back in the output of your build attempt.

A: These errors look something like this:

Failed: Internal error: node for system-xfree86 already exists

This problem is that the dependency engine is confused, due to changes in some of the package info files. To fix it:

• Remove the offending package by force, e. g.

  sudo dpkg -r --force-all system-xfree86

  for the example given above.

• Try again to install | upgrade. At some point a "virtual dependency" prompt will come up that includes the package you just removed. Select it, and it will be reinstalled during your build.

A: This is a frequent source of problems, because the package configuration script finds headers and libraries in /usr/local and decides to use them rather than using those in the Fink tree. Often, such errors will show up as part of a package's build diagnostics, for example:

Looking for incorrect headers in 44 dependency files...
	 ./objs/.libs/ftgzip.d uses /usr/local/include/zconf.h
	 ./objs/.libs/ftgzip.d uses /usr/local/include/zlib.h
Please fix build process to get consistent use of fink's headers.
        

And if you are having problems with a build that aren't covered by another FAQ entry, you should also check whether you have libraries in /usr/local/lib or headers in /usr/local/include.

If you do have headers and/or libraries in /usr/local, then rename /usr/local to something else, e.g.:

sudo mv /usr/local /usr/local.moved

do your build, and then you can put /usr/local back:

sudo mv /usr/local.moved /usr/local

Starting with macOS 10.14, it's sometimes not possible to rename /usr/local. If you get an error when renaming /usr/local directly, then rename the subdirectories inside it instead:

        sudo mv /usr/local/include /usr/local/include.moved
        sudo mv /usr/local/lib /usr/local/lib.moved
        

do your build, and then you can put /usr/local/include and /usr/local/lib back:

        sudo mv /usr/local/include.moved /usr/local/include
        sudo mv /usr/local/lib.moved /usr/local/lib
        

A: The output hints at what to do. The message is usually something like:

ld: table of contents for archive: 
/opt/sw/lib/libintl.a is out of date; 
rerun ranlib(1) (can't load from it)

What you need to do is run ranlib (as root) on whatever library is causing the problem. As an example, for the case above, you would run:

sudo ranlib /opt/sw/lib/libintl.a

A: This happens because one of the steps in the build of atlas sends a prompt to the user that Fink Commander doesn't display. You'll have to use fink install atlas instead.

A: Both of these problems are typically due to the absence of essential headers that are provided by the DevSDK package of the Developer Tools. Check whether /Library/Receipts/DevSDK.pkg exists on your system. If not, then run the Dev Tools Installer again, and install the DevSDK package using a Custom Install.

The cannot create executables error can also occur when your Developer Tools version is for an earlier OS version.

A: To get around this, try updating a single package, then try to use "fink update-all" again. If you still get the message, repeat the process.

A: This means that somehow your dpkg database got damaged, usually from a crash or some other unrecoverable error. This most often occurs with a buildlock, e.g:

package `fink-buildlock-foo-1.2.3-4':  missing version

(of course, replace foo-1.2.3-4 with the package name you are seeing).

When this happens, you should edit /opt/sw/var/lib/dpkg/status as a superuser. Then go near the line number which shows up in the error message. You should see a fink-buildlock-foo-1.2.3-4 package whose Status field is marked

install ok installed

Change that to

purge ok not-installed

Under other circumstances, there may be garbage in the file. You can fix this situation by copying the previous version of the database, like so:

sudo cp /opt/sw/var/lib/dpkg/status-old /opt/sw/var/lib/dpkg/status

You may need to re-install the last couple of packages you installed before the problem started occurring.

A: There are several varieties of such errors. If you get the following:

/usr/bin/ld: can't locate file for: -lfreetype

check whether you have an extraneous freetype-config excutable by running

where freetype-config

if you're using tcsh, or

type -a freetype-config

if you're using bash. The Mono Framework has been known to install a /usr/bin/freetype-config that is a symbolic link to a file in that framework.

If your error looks like:

/opt/sw/include/pango-1.0/pango/pangoft2.h:52: 
error: parse error before '*' token 
/opt/sw/include/pango-1.0/pango/pangoft2.h:57:
error: parse error before '*' token
/opt/sw/include/pango-1.0/pango/pangoft2.h:61: 
error: parse error before '*' token 
/opt/sw/include/pango-1.0/pango/pangoft2.h:86: 
error: parse error before "pango_ft2_font_get_face"
/opt/sw/include/pango-1.0/pango/pangoft2.h:86: 
warning: data definition has no type or storage class 
make[2]: *** [rsvg-gz.lo] Error 1
make[1]: *** [all-recursive] Error 1 
make: *** [all-recursive-am] Error 2 
### execution of make failed, exit code 2 
Failed: compiling librsvg2-2.4.0-3 failed

or

In file included from vteft2.c:32: 
vteglyph.h:64: error:
parse error before "FT_Library" 
vteglyph.h:64: warning: 
no semicolon at end of struct or union vteft2.c: 
In function `_vte_ft2_get_text_width': 
vteft2.c:236: error: 
dereferencing pointer to incomplete type 
vteft2.c: In function `_vte_ft2_get_text_height':
vteft2.c:244: error: 
dereferencing pointer to incomplete type
vteft2.c: In function `_vte_ft2_get_text_ascent': 
vteft2.c:252: error:
dereferencing pointer to incomplete type 
vteft2.c: In function `_vte_ft2_draw_text': 
vteft2.c:294: error: 
dereferencing pointer to incomplete type 
vteft2.c:295: error: 
dereferencing pointer to incomplete type
make[2]: *** [vteft2.lo] Error 1 
make[1]: *** [all-recursive] Error 1 
make: *** [all] Error 2 
### execution of make failed, exit code 2
Failed: compiling vte-0.11.10-3 failed

or

checking for freetype-config.../usr/X11R6/bin/freetype-config 
checking For sufficiently new FreeType (at least 2.0.1)... no 
configure: error: pangoxft 
Pango backend found but did not find freetype libraries 
make: *** No targets specified and no makefile found. Stop. 
### execution of LD_TWOLEVEL_NAMESPACE=1 failed, exit code 2 
Failed: compiling gtk+2-2.2.4-2 failed

the problem is due to confusion between headers from the freetype | freetype-hinting package and the freetype2 headers that are included with X11 | XFree86.

fink remove freetype freetype-hinting

will remove whichever variant you have installed. On the other hand, if your error looks like:

ld: Undefined symbols: _FT_Access_Frame

this is typically due to a residual file from a prior installation of X11. Reinstall the X11 SDK.

A: If you have an error that looks like this

unix_dl.c: In function `rep_open_dl_library':
unix_dl.c:328: warning: assignment discards qualifiers from pointer target type 
unix_dl.c: In function `rep_find_c_symbol': 
unix_dl.c:466: error: `Dl_info' undeclared (first use in this function)
unix_dl.c:466: error: (Each undeclared identifier is reported only once 
unix_dl.c:466: error: for each function it appears in.)
unix_dl.c:466: error: parse error before "info" 
unix_dl.c:467: error: `info' undeclared (first use in this function) 
make[1]: *** [unix_dl.lo] Error 1

then most likely you have a header file, /usr/local/include/dlfcn.h, that is incompatible with Panther. Move it out of the way.

This usually is installed by Open Office, and you should replace this header file, as well as the library /usr/local/lib/libdl.dylib, with symbolic links to Panther's builtin files

sudo ln -s /usr/include/dlfcn.h /usr/local/include/dlfcn.h
sudo ln -s /usr/lib/libdl.dylib /usr/local/lib/libdl.dylib

A: This is because gcc2 and gcc3.1 are virtual packages to indicate the presence of gcc-2.95 and gcc-3.1, respectively, on your system. Install the gcc2.95 and/or the gcc3.1 package from the XCode Tools (earlier OS versions have gcc-2.95 and gcc-3.1 as part of their main Developer Tools installation).

Note: Installing gcc2.95 and/or gcc3.1 will not interfere with your gcc3.3 compiler--they can all coexist.

A: If you're using the unstable tree, make sure you have intltool-0.34.1or later installed.

Otherwise, you need to make sure that you have the right variant of the xml-parser-pm package to match the Perl version for your system. For example, if you're on Panther you should have xml-parser-pm581 rather than xml-parser-pm560 (you may also have the xml-parser-pm placeholder), since you have Perl-5.8.1 rather than Perl-5.6.0. If you're on Jaguar, and are using the default system Perl version, you'll have the pm560 variant, and if you've installed Perl 5.8.0 you may have the pm580 variant.

A: What's happened here is that Fink is trying to use one of it's so called Master mirrors. These were set up to makes sure that sources for Fink packages are available even when the upstream site has moved them around. Typically these errors occur when a new upstream version of a package is released, but hasn't made it to the Master mirrors yet.

To remedy this, run fink configure and set the search order to use Master mirrors last.

A: Often, in a complicated build tree, you may find that some of the packages depend on a particular version of a library, and other depend on a different one (e.g. db47 vs. db44). Consequently, Fink may try to switch to whichever one isn't currently installed in order to satisfy the build dependency for the current package that you're trying to update.

Unfortunately, due to limitations in the build-dependency engine, you may wind up with the dreaded

Fink::SysState: Could not resolve inconsistent dependencies

message when trying a sufficiently complicated update-all. This generally gives you a command to try to resolve the issue:

fink scanpackages
sudo apt-get update
sudo apt-get install foo=1.23-4	
      

but this may not work for sufficiently complicated updates. You might need to update packages one-by-one, at least for a while.

A: For errors that look like the following:

running build
running build_ext
Traceback (most recent call last):
  File "setup_socket_ssl.py", line 21, in ?
    depends = ['socketmodule.h'] )
  File "/opt/sw/src/root-python24-2.4.1-1/opt/sw/lib/python2.4/distutils/core.py", line 166, in setup
SystemExit: error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.3" during configure
### execution of /opt/sw/bin/python2.4 failed, exit code 1

the problem occurs because the python2* packages write the current MACOSX_DEPLOYMENT_TARGET to a configuration file when they're built and the python build utilities use this value when compiling modules. This means that if you have, for example, a python24 package on 10.4 that was built on 10.3, either by upgrading 10.3 => 10.4, or via the 10.4-transitional binary distribution, in which python24 wasn't rebuilt, there will be a mismatch between what python thinks MACOSX_DEPLOYMENT_TARGET should be (10.3) and what it actually is (10.4).

The fix is to rebuild the offending python package, e.g. fink rebuild python24 for the case above.

For runtime errors that give the same type of error message as above, rebuild the module after rebuilding the appropriate python2* package.

A: This error:

 libtool: unrecognized option `-dynamic'

typically means that you've replaced Apple's /usr/bin/libtool with a GNU libtool. Unfortunately, the two libtools do not do the same thing.

The only way to solve this is to get a working Apple libtool from somewhere. It is installed as part of the DeveloperTools.pkg package of the XCode Tools, and you can reinstall that whole package if you first clear out its receipt in /Library/Receipts (drag it to the Trash for OS 10.4 and later, or use sudo rm -rf /Library/Receipts/DeveloperTools.pkg for 10.3).

A: If you see messages on 10.9 or 10.10 like

The directory that should contain system headers does not exist:
  /usr/include

or

cp: /usr/include/lber*.h: No such file or directory

when doing a build, this usually means that you are using a version of the Xcode command-line tools which is for a previous OS X version. Try to get a new version from the App Store, or by running sudo xcode-select -install, or by downloading them from developer.apple.com.

A: The error in question looks like

Unpacking replacement wxmaxima-mac ...
/opt/sw/bin/dpkg: error processing /opt/sw/fink/dists/stable/main/binary-darwin-x86_64/sci/wxmaxima-mac_15.04.0-1_darwin-x86_64.deb (--install):
 unable to make backup link of `./opt/sw/Applications/wxMaxima.app/Contents/PkgInfo' before installing new version: Operation not permitted
/opt/sw/bin/dpkg-deb: subprocess paste killed by signal (Broken pipe: 13)

The current workaround is to remove the offending package, which removes the PkgInfo file, and then to install the updated version.