Autoconf Complains "C Compiler Cannot Create Executables" on Linux Mint

Autoconf problem: “error: C compiler cannot create executables”

The trouble is that there is a newline in the PACKAGE_TARNAME (and PACKAGE), which is set in the configure.ac file. You should look at what that contains - fix it, and regenerate the configure script.

One of my configure.ac scripts contains (near the top):

AC_CONFIG_HEADER(config.h)

PACKAGE="sqlcmd"
VERSION="86.04"

AC_MSG_RESULT([Configuring $PACKAGE version $VERSION])

AC_SUBST(PACKAGE)
AC_SUBST(VERSION)

crti.o file missing

crti.o is the bootstrap library, generally quite small. It's usually statically linked into your binary. It should be found in /usr/lib.

If you're running a binary distribution they tend to put all the developer stuff into -dev packages (e.g. libc6-dev) as it's not needed to run compiled programs, just to build them.

You're not cross-compiling are you?

If you're cross-compiling it's usually a problem with gcc's search path not matching where your crti.o is. It should have been built when the toolchain was. The first thing to check is gcc -print-search-dirs and see if crti.o is in any of those paths.

The linking is actually done by ld but it has its paths passed down to it by gcc. Probably the quickest way to find out what's going on is compile a helloworld.c program and strace it to see what is getting passed to ld and see what's going on.

strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test

Open the log file and search for crti.o, as you can see my non-cross compiler:

10616 execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=both", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o"
, "test", "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "-L/usr/lib/gcc/x86_64-linux-g
nu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/../lib", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu
/"..., "/tmp/cc4rFJWD.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_
64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."...], "COLLECT_GCC=gcc", "COLLECT_GCC_OPTIONS=\'-o\' \'test\' "..., "COMPILER_PATH=/usr/lib/gcc/x86_6"..., "LIBRARY_PATH=/usr/lib/gcc/x86_64"..., "CO
LLECT_NO_DEMANGLE="]) = 0
10616 open("/etc/ld.so.cache", O_RDONLY) = 3
10616 open("/usr/lib/libbfd-2.18.0.20080103.so", O_RDONLY) = 3
10616 open("/lib/libc.so.6", O_RDONLY) = 3
10616 open("test", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crt1.o", O_RDONLY) = 4
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crti.o", O_RDONLY) = 5
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtbegin.o", O_RDONLY) = 6
10616 open("/tmp/cc4rFJWD.o", O_RDONLY) = 7

If you see a bunch of attempts to open(...crti.o) = -1 ENOENT, ld is getting confused and you want to see where the path it's opening came from...

What is libintl.h and where can I get it?

Depending on the system, it's probably part of the GNU C library (glibc).

Note that just installing the file libintl.h isn't likely to do you any good.

On Debian-based systems (including Debian, Ubuntu, and Linux Mint), it's part of the libc6-dev package, installed with:

sudo apt-get install libc6-dev

Since you're using Mac OS X, a Google search for "libintl.h OSX" shows a lot of people having similar problems. According to the INSTALL file in the Git sources:

Set NO_GETTEXT to disable localization support and make Git only use English. Under autoconf the configure script will do this automatically if it can't find libintl on the system.

g++ with DevIL: unable to link

There are plenty of options for using libraries on Linux. It's usually fairly easy, but you seem to have stumbled on some of the common gotchas.

Rule #1: Don't touch /usr or /usr/local yourself.

The /usr directory is for packages installed by the system (e.g. apt-get on Debian, Ubuntu, or Mint), so you should almost never touch it at all.

The /usr/local directory is for packages that you install (assuming that you are the administrator of the machine), but you don't manually copy files there. Instead, you run installation scripts that put files there automatically.

Typically, you install like this:

./configure
make
sudo make install

Rule #2: Use the package manager first.

The package manager depends on which Linux distro you are using. For example, on Debian-based systems, the package system is "apt", and you can use synaptic, aptitude, or apt-get to install packages.

On my system, I would run the command:

sudo apt-get install libdevil-dev

The -dev means "development", so it includes the headers you need to compile programs that use DevIL.

Rule #3: If you compile from source, get a proper release before you look at GitHub.

Proper releases will have configure scripts. Because you downloaded from GitHub, you had to invoke autoconf, which just means installing more packages on your system. Don't bother, just grab a proper source code release.

Rule #4: Always use a build system.

You haven't mentioned how you're compiling things, so it makes me worried that you might just be typing gcc on the command line. This is a recipe for frustration.

Here is a makefile that you can use to compile a simple C++ program that uses DevIL, assuming your program is all in main.cpp:

all: myprog
clean:
rm -f myprog *.o

devil_cflags := $(shell pkg-config --cflags IL)
devil_libs := $(shell pkg-config --libs IL)

CXXFLAGS := -O0 -g -Wall -Wextra $(devil_cflags)
LIBS := $(devil_libs)

myprog: main.o
c++ $(LDFLAGS) -o $@ $^ $(LIBS)

This uses pkg-config to figure out how to link with DevIL. It's much better than writing the linker flags yourself.

Note that the indentation in a Makefile must be done with tabs, you can't use spaces.



Related Topics



Leave a reply



Submit