autoconf recipe to use gcc-ar and gcc-ranlib - gcc

I'm using link-time optimisation (LTO) in a project that compiles under both GCC and Clang and builds a static library. It's working with GCC 4.8, but GCC 5.4 makes thin LTO objects and when automake tries to build the static library with ar it fails, because it needs the wrapper script gcc-ar.
Is there a good example I can look at for how to make automake use gcc-ar instead of ar (and similarly for gcc-ranlib)? I can probably hack something in, but ideally it should:
Use the appropriate tools for the compiler (Clang has its own instructions).
Work even if the user overrides the compiler to one that isn't the system default.
Work when cross compiling

You can override the default tools used by calling
./configure AR=gcc-ar RANLIB=gcc-ranlib
I'm afraid for ./configure to pick them up by default, autoconf/automake will have to be fixed to know about those in the default set of checks.

Use this:
AC_ARG_VAR([AR], [AR command (default is gcc-ar)])
AC_CHECK_TOOL([AR], [gcc-ar])
AC_ARG_VAR([RANLIB], [RANLIB command (default is gcc-ranlib)])
AC_CHECK_TOOL([RANLIB], [gcc-ranlib])
AC_ARG_VAR is there just to document it, when invoking ./configure --help.
AC_CHECK_TOOL is used for these tools, instead of AC_CHECK_PROGS, so the right version is used when cross-compiling.
You can still override AR, RANLIB when invoking ./configure.
To fallback to regular ar and regular ranlib, you can use AC_CHECK_TOOLS instead:
AC_CHECK_TOOLS([AR], [gcc-ar ar])
An optional third argument can be set to something like : so you can test if none of the tools were found:
AC_CHECK_TOOLS([AR], [gcc-ar ar], [:])
AS_VAR_IF([AR], [:], AC_MSG_ERROR([could not find AR tool.]))
For Clang, they follow a different naming convention: llvm-ar, llvm-ranlib, llvm-objcopy, etc. I'll be using two helper macros.
First, we define MY_CHECK_TOOL_PREFIX, using AX_COMPILER_VENDOR, this will try to guess what tool prefix to use; it can be overridden with the TOOL_PREFIX variable. It will test the compiler for the current language (defaults to C); make sure to call AC_LANG(C++) beforehand if needed. It's used by the next macro, you don't need to call it manually.
AC_DEFUN([MY_CHECK_TOOL_PREFIX],
[
AC_REQUIRE([AX_COMPILER_VENDOR])
AC_ARG_VAR([TOOL_PREFIX], [tool prefix (gcc, llvm)])
AC_MSG_CHECKING([toolchain prefix])
# only convert vendor to prefix if not already set
AS_VAR_SET_IF([TOOL_PREFIX],
[],
[
AS_CASE([${ax_cv_[]_AC_LANG_ABBREV[]_compiler_vendor}],
[gnu], [TOOL_PREFIX="gcc"],
[clang], [TOOL_PREFIX="llvm"],
[TOOL_PREFIX="unknown"])
])
AC_MSG_RESULT([$TOOL_PREFIX])
])
Then comes the macro you'll be using: MY_CHECK_TOOL. The default action, if not variant of the tool is found, is to abort.
dnl MY_CHECK_TOOL(TOOL, PROGRAM-TO-CHECK, [ACTION-IF-NOT-FOUND])
AC_DEFUN([MY_CHECK_TOOL],
[
AC_REQUIRE([MY_CHECK_TOOL_PREFIX])
AC_ARG_VAR($1, [$1 command (default is TOOL_PREFIX-$2, $2)])
AC_CHECK_TOOLS($1, [${TOOL_PREFIX}-$2 $2], [:])
AS_VAR_IF($1, [:],
[m4_ifblank($3,
[AC_MSG_ERROR([could not find $1])],
$3)])
])
You can save both in a my_prefix_tools.m4 file in your M4 dir, if you don't want to clutter your configure.ac.
And here's how you'd use it in configure.ac:
AC_PROG_CXX
AC_LANG(C++)
MY_CHECK_TOOL([AR], [ar])
MY_CHECK_TOOL([RANLIB], [ranlib])
MY_CHECK_TOOL([OBJCOPY], [objcopy])
MY_CHECK_TOOL([NM], [nm])
When running ./configure where g++ is the default C++ compiler, this is the output:
checking for C++ compiler vendor... gnu
checking toolchain prefix... gcc
checking for gcc-ar... gcc-ar
checking for gcc-ranlib... gcc-ranlib
checking for gcc-objcopy... no
checking for objcopy... objcopy
checking for gcc-nm... gcc-nm
And when running ./configure CXX=clang++, this is the output:
checking for C++ compiler vendor... clang
checking toolchain prefix... llvm
checking for llvm-ar... llvm-ar
checking for llvm-ranlib... llvm-ranlib
checking for llvm-objcopy... llvm-objcopy
checking for llvm-nm... llvm-nm

Related

libtool: error: can't build x86_64-w64-mingw32 shared library unless -no-undefined is specified

I am trying to build and install the OpenFst library on windows10 using MINGW64 with Msys but i got the following error during the building with make. I first used this command:
./configure --enable-grm --enable-far --enable-ngram-fsts MAKE="mingw32-make"
some of the checking results from this command generates no:
checking whether we are cross compiling... no
checking for sysroot... no
checking for a working dd... ./configure: line 7016: cmp: command not found
./configure: line 7016: cmp: command not found
checking for mt... no
checking if : is a manifest tool... no
checking for unistd.h... no
checking if gcc supports -fno-rtti -fno-exceptions... ./configure: line 8930: diff: command `not found`
checking whether to build static libraries... no
The other checking results are ok and yes. Then I used the make command:
mingw32-make
it works for some files then terminated by that error:
libtool: error: can't build x86_64-w64-mingw32 shared library unless -no-undefined is
specified
It is my first time to build with MinGW. So, I do not know what the error means and if the resulting "no" checking from the configuration responsible for it.
This is normal.
MinGW does not allow building shared libraries (DLLs) when there are still unresolved symbols, because on Windows each symbol referenced from a DLL must point to something that exists. On other platforms this is not always required.
So you should pass to -Wl,-no-undefined to gcc when linking.
For projects using autoconf's configure this is normally already done if it was a recent enough version of autoconf. Otherwise you may need to add LDFLAGS="-Wl,-no-undefined" to the configure line.
If that doesn't help you can try to change it in the libtool file generated by configure.
So specicially you can try this in MSYS/MSYS2 shell:
./configure LDFLAGS="-Wl,-no-undefined"
and if that doesn't work you can also try this (after the configure command and before running make):
sed -i.bak -e "s/\(allow_undefined=\)yes/\1no/" libtool
Other build tools like cmake, meson or scons already know how to build Windows DLLs and need no special treatment.

How to override default linker compiling with configure?

I need to install a package (ROOT) from source on OSX using GCC 4.7.3 as a compiler. Default compiler on OSX is clang, so I look to configure command options to change it. I see that I can change it:
with compiler options, prefix with --with-, overrides default value
cc alternative C compiler and options to be used
cxx alternative C++ compiler and options to be used
But when I run:
./configure --with-cxx=g++ --with-cc=gcc
I see:
Checking for C compiler ... gcc
Checking for C++ compiler ... g++
Checking for linker (LD) ... clang++
So it trying to compile with gcc and link with clang, this obviously leads to failure. But I can't find an option in configure how to change linker used by make.
Is there a default options of configure to change linker? Something like --with-cxxlinker.
If not - how can I find and change the linker used by specific package?
The recommended way of building ROOT from source is to use git and obtain the most recent production version available. As of today that is version 5.34.19.
Open Terminal.app (then use each of the commands in succession):
cd ~/desktop && mkdir root
git clone http://root.cern.ch/git/root.git && cd root
./configure
make
make install
The nice thing about using git is that it contains a complete source tree for all systems (72 MB). You shouldn't need to use any special ./configure commands (unless you want to use add-on components).
You could also install the Mac Ports version by using the command:
sudo port install root

What is important when cross compiling using automake?

This may not be easy to answer concisely but I don't consider it to be open-ended: when using automakeand configure to cross-compile a library, what should be the most important things I need to avoid 'toolchain leaks'?
Here is some context...
First off, a toolchain leak is defined here: http://landley.net/writing/docs/cross-compiling.html
I'm compiling libuuid from source using a toolchain that is made for cross compiling code that will run on a custom debian based system. The goal of the project is to compile the code (including this 3rd party library that my app depends on) using the toolchain so that the compilation is independent of the host machine.
So far, I've tried to supply my toolchain's gcc compiler which looks okay, but when I run ./configure there are many things it checks for, and I'm not sure how to tell which ones truly matter, and I'm not sure how to have it only check in my toolchain and ignore anything on the host system. Here are a few examples:
Here you can see that ./configure is happy with my toolchain compiler:
checking whether we are using the GNU C compiler... yes
checking whether <toolchain>/bin/i686-linux-gcc accepts -g... yes
Then shortly after you can see it finds grep on my host system which seems like a 'toolchain leak'
checking for grep that handles long lines and -e... /bin/grep
Then later on it searches the host system for some headers. I think I can specify where it should look, but I still don't know which headers are required:
checking for linux/compiler.h... no
checking for linux/blkpg.h... yes
checking for linux/major.h... yes
checking asm/io.h usability... no
<...>
Then shortly after you can see it finds grep on my host system which seems like a 'toolchain leak'
I would not call that a 'toolchain leak', and the referenced article doesn't either. It does mention these things as being 'leaks':
Improper header files from the autoconf --build system (called "host" in the article, and in your post).
Improper libraries from the --build system
I don't think any toolchain I've used has it's own grep executable. What would it do differently?
That being said, it shouldn't be using --builds linux headers. Usually the toolchain has it's own copy of those. That would be a 'leak'.
I'm compiling libuuid from source using a toolchain that is made for cross compiling code that will run on a custom debian based system. The goal of the project is to compile the code (including this 3rd party library that my app depends on) using the toolchain so that the compilation is independent of the host machine.
It'll go something like this: compile the dependency with the toolchain and install it in the toolchain /usr/lib (or somewhere where you plan on keeping cross compiled libraries, if you don't want to clutter up your toolchain). Compile libuuid with the toolchain (referencing the dependency, of course).

Compiling PHP + Libpuzzle to Windows

I got the libpuzzle source here: http://www.pureftpd.org/project/libpuzzle/download.
I read I need MinGW to compile any C programs on windows, so I got that alot with C, C++ and mins options. Using mins I was followed: http://wiki.openttd.org/Compiling_on_MinGW
I downloaded the .tar.gz and unpacked it, executed the ./configure command and got:
libgd2 development files are not found
Makes sense given in the readme:
In order to load images, the library relies on the GD2 library.
You need to install gdlib2 and its development headers before compiling
libpuzzle.
The GD2 library is available as a pre-built package for most operating systems.
Debian and Ubuntu users should install the "libgd2-dev" or the "libgd2-xpm-dev"
package.
Gentoo users should install "media-libs/gd".
OpenBSD, NetBSD and DragonflyBSD users should install the "gd" package.
MacPorts users should install the "gd2" package.
X11 support is not required for the Puzzle library.
Once GD2 has been installed, configure the Puzzle library as usual:
My problem at this time is finding a libgd2-dev or like file to compile. I found this: http://mldonkey.sourceforge.net/Windows and downloaded http://www.boutell.com/gd/http/gd-2.0.33.tar.gz and it installed fine. Running gdlib-config outputs typical man. However, libpuzzle still says I need the "libgd2 development files", so I assume the gd I downloaded was "libgd" but just "gd" or the file I had didn't have development files. Where can I found what I need?
Here is mingw output:
Brian#2500K ~/libpuzzle-0.11
$ gdlib-config
Print information on GD library's version, configuration, and use.
Usage: gdlib-config [options]
Options:
--libdir # directory where GD library is installed
--includedir # directory where GD library headers are installed
--version # complete GD library version string
--majorversion # GD library major version number
--minorversion # GD library minor version number
--revision # GD library revision version number
--ldflags # options required for linking against GD library
--libs # libs required for linking against GD library
--cflags # options required for compiling GD library apps
--includes # same as --cflags
--features # lists optional features compiled into gd, separated
# by spaces. Currently (as of 2.0.26) the optional
# features are GD_PNG, GD_JPEG, GD_XPM, and
# GD_FREETYPE. When these features are reported by
# --features, it is safe to include calls to the
# related functions in your code.
--all # print a summary of all GD library configure options
Brian#2500K ~/libpuzzle-0.11
$ gdlib-config --includedir
/usr/local/include
Brian#2500K ~/libpuzzle-0.11
$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... no, using cp -p
checking whether make sets $(MAKE)... (cached) yes
checking for gdlib-config... /usr/local/bin/gdlib-config
checking for gdImageCreateFromGd2 in -lgd... no
configure: error: libgd2 development files not found
Edit: Started a bounty. I am looking for either compile the libpuzzle for me so it works on WAMP (skipping the complicated middle stuff). Or help on getting each requirement needed so that I can compile it. My end goal is having libpuzzle run on wamp
Edit 2: Just an update, it seems libgd2 has problems with mingw. Even if I was to get libgd2 to finally work then I still need phpize for mingw as well, which also doesn't work for mingw. It seems it's not possible to use libpuzzle for windows
It sounds like the program is just not finding the headers for libgd. If you look at that tarbar, it's a source tarball that includes the headers. When you compiled and installed it, it installed the library and the headers somewhere. You need to figure out where.
Run ./configure --help
There should be an option like --with-gd=, that option lets you tell it the path where libgd is installed. Specify the path where it is installed, and it should work.
Encountered the same error when compiled GD2 myself.
Using old precompiled version from GnuWin32 solved the problem:
http://sourceforge.net/projects/gnuwin32/files/gd/2.0.33-1/

Problem compiling gcc 4.4.0 on OpenSolaris 2009.6

I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package

Resources