P.M.F. - 6. Compile Problems - General

P.6.1: Un script de configuración se queja que no puede encontrar un "cc aceptable". ¿Qué es eso?

R.: 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.

P.6.2: Cuando quiero hacer un "fink selfupdate-cvs" Me aparece este mensaje: "cvs: Command not found."

R.: You need to install the Developer Tools.

P.6.3: Me esta apareciendo un mensaje de error involucrando make.

R.: if your message is of the form

make: command not found


Can't exec "make": 
No such file or directory at /sw/lib/perl5/Fink/ 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.

P.6.4: Me esta apareciendo un mensaje de uso extraño del comando head. ¿Qué se ha roto?

R.: 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.

P.6.5: Cuando trato de instalar un paquete me aparece un mensaje con el error acerca de "sobreescribir un archivo que está en otro paquete".

R.: 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.

P.6.6: ¿Qué quiere decir "execution of mv failed, exit code 1" cuando trato de instalar un paquete?

R.: 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, am 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 \
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.

P.6.7: No puedo instalar o actualizar un paquete porque me aparece un mensaje de que un "node" ya existe.

R.: 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.

P.6.8: He escuchado que las librerías instaladas en /usr/local/lib a veces causan problemas de compilación para Fink, ¿es cierto?

R.: This is a frequent source of problems, because the package configuration script finds libraries under /usr/local/lib before searching 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. 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

P.6.9: Cuando trato de instalar un paquete, me aparece un mensaje que la "tabla de contenidos" ("table of contents") está desactualizada. ¿Qué necesito hacer?

R.: 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

P.6.10: Fink Commander falla cuando trato de instalar atlas.

R.: 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.

P.6.11: I get messages saying that I'm missing stddef.h | wchar.h | stdlib.h | crt1.o, or that my C compiler cannot create executables.

R.: 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.

P.6.12: No puedo actualizar porque Fink dice "unable to resolve version conflict on multiple dependencies"

R.: 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.

P.6.13: No puedo instalar nada porque me aparece: "dpkg: parse error, in file `/sw/var/lib/dpkg/status'"!

R.: 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 /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 /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.

P.6.14: Me aparecen errores involucrando a freetype.

R.: 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:

error: parse error before '*' token 
error: parse error before '*' token
error: parse error before '*' token 
error: parse error before "pango_ft2_font_get_face"
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


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


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.

P.6.15: Me aparecen errores al compilar involucrando "Dl info".

R.: 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

P.6.16: Fink dice que me falta el gcc2, pero yo no creo haberlo instalado.

R.: This is because gcc2 is a virtual package to indicate the presence of gcc-2.95 on your system. Install the gcc2.95 package from the XCode Tools (earlier OS versions have gcc-2.95 as part of their main Developer Tools installation.

P.6.17: Fink dice Failed: Can't resolve dependency "system-java14-dev", pero ese paquete no existe.

R.: That's because it's a virtual package. This type of error occurs when Java gets updated by Software Update: the header files get removed, which causes the -dev package not to be generated.

You need to download the appropriate Java Developer Tools package from Apple. In this specific case that's the Java 1.4.2 Developer Tools.

P.6.18: Cualquier cosa que trato de instalar siempre me aparece: dpkg (subprocess): failed to exec dpkg-split to see if it's part of a multiparter: No such file or directory. ¿Cómo soluciono esto?

R.: Generally, this can be fixed by setting your environment up correctly, cf. this FAQ entry.

P.6.19: Me aparece el mensaje siguiente: configure: error: XML::Parser perl module is required for intltool. ¿Qué debo hacer?

R.: 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.

P.6.20: I'm trying to download a package, but Fink goes to some weird site with distfiles in its name, and the file isn't there.

R.: 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.

P.6.21: I want Fink to use different options in building a package.

R.: The first thing to do is to contact the package maintainer to request a variant. It may be relatively easy to do it. If you don't hear from the maintainer or see the new packages, or want to try a different option yourself, check out the Packaging Tutorial and Packaging Manual.

Note: Fink is deliberately set up such that all official binaries are identical regardless of what machine they are built on, so things like G5 optimization won't happen with an official package. If you want them, you'll have to do it yourself.

P.6.22: Whenever I try to build from source, Fink keeps waffling between alternate versions of the same library.

R.: 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.

P.6.23: I get errors involving MACOSX_DEPLOYMENT_TARGET when I try to build a Python module.

R.: For errors that look like the following:

running build
running build_ext
Traceback (most recent call last):
  File "", line 21, in ?
    depends = ['socketmodule.h'] )
  File "/sw/src/root-python24-2.4.1-1/sw/lib/python2.4/distutils/", 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.

P.6.24: I get unrecognized option `-dynamic' errors from libtool.

R.: 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).

Siguiente: 7. Compile Problems - Specific Packages