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
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
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/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
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
bsdmake. Furthermore, make sure
/usr/local/bin/ does not contain another copy of
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
/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
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
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-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.
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
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
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
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
P.6.11: I get messages saying that I'm missing
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.
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
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
if you're using
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: *** [rsvg-gz.lo] Error 1 make: *** [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: *** [vteft2.lo] Error 1 make: *** [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-hinting package and the
freetype2 headers that are included with X11 |
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: *** [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
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
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 "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
P.6.24: I get
unrecognized option `-dynamic' errors from
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