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 /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 /sw/bin/HEAD (not by any Fink package). This is easier to solve: rename /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: This is new with the December 2002 Tools. You may occasionally see messages like (choosing libgdk-pixbuf as an example):

ld: warning dynamic shared library:
/sw/lib/libgdk-pixbuf.dylib not made a weak library in output with
MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1

You may regard these as harmless. If you are curious, read through the release notes in the developer documentation directory, especially GCC's and the linker's, for more info. It essentially has to do with whether missing symbols at runtime is considered a fatal error on startup or not, for applications that use weak references.

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 /sw/src/root-foo-0.1.2-3/sw/lib/libbar*.dylib \
/sw/src/root-foo-shlibs-0.1.2-3/sw/lib/ 
mv: cannot stat `/sw/src/root-foo-0.1.2-3/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 path. If you are having problems with a build that aren't covered by another FAQ entry, you should check whether you have libraries in /usr/local/lib or headers in /usr/local/include. If so, then try renaming /usr/local to something else, e.g.:

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

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

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

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

ld: table of contents for archive: 
/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 /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 corrupted, usually from a crash or some other unrecoverable error. You can fix it by copying the previous version of the database, like so:

sudo cp /sw/var/lib/dpkg/status-old /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:

/sw/include/pango-1.0/pango/pangoft2.h:52: 
error: parse error before '*' token 
/sw/include/pango-1.0/pango/pangoft2.h:57:
error: parse error before '*' token
/sw/include/pango-1.0/pango/pangoft2.h:61: 
error: parse error before '*' token 
/sw/include/pango-1.0/pango/pangoft2.h:86: 
error: parse error before "pango_ft2_font_get_face"
/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.

Finally, if you get an error like

dyld: klines Undefined symbols: /sw/lib/libqt-mt.3.dylib 
undefined reference to _FT_Access_Frame

then you probably have a binary version that built fine with gcc3.3 on Jaguar but doesn't work on Panther. This has now been updated, so you you just need to update your packages, e.g. via sudo apt-get update ; sudo apt-get dist-upgrade.

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: Some packages that need gettext headers to build have been updated to use libgettext3-dev and some still use gettext-dev. Consequently, Fink may try to switch to whichever one isn't currently installed in order to satisfy a build dependency for some package that you're trying to update. In addition, the fink tool treats gettext-dev as essential, and will install it any time you selfupdate.

Similar behavior can happen for other pairs of packages, too.

Unfortunately, due to limitations in the build-dependency engine, you may find that your build bombs because you've swapped in one of these but some later package in your build chain wants the other one. You can usually proceed by repeating your update command again.

In extreme cases you may wind up having to install those packages which build-depend on gettext-dev separately from those which want libgettext3-dev (or whichever pair are causing problems). You may even have to install packages one by one.

A permanent fix should hopefully be available in fink-0.24.9.

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 "/sw/src/root-python24-2.4.1-1/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 /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).