Cross-compiling for ARM with Autoconf - c

I am having trouble cross-compiling a library for my arm board using autconf.
I am using this line:
./configure --target=arm-linux --host=arm-linux --prefix=/bla/bla/bla/linux_arm_tool CFLAGS='-m32'
make
make install
When I do file to check it I get:
libjpeg.so.8.4.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
That doesn't seem right at all, but I tried using it anyway... and I get:
/usr/lib/gcc/arm-linux-gnueabi/4.5.3/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /bla/bla/bla/bla/../linux_arm_tool/lib/libjpeg.so when searching for -ljpeg
I'm at a loss, I've been googling for an hour now...

So I knew I've cross compiled before using really basic method calls and I figured out why I've gotten away with this before after examining the output:
checking for arm-linux-gnueabi-gcc... no
checking for gcc... gcc
...
...
checking for arm-linux-gnueabi-gcc... gcc
In my /usr/bin there was no arm-linux-gnueabi-gcc, I had to:
ln -s /usr/bin/arm-linux-gnueabi-gcc-4.5 /usr/bin/arm-linux-gnueabi-gcc
I successfully cross-compiled using:
./configure --host=arm-linux-gnueabi -prefix=${CSTOOL_DIR}/linux_arm_tool
as for linking ... I still have to check some things, but I am going to assume I might need to throw some -rpath-link flags in more advanced compiles.

I think the problem could be restated more generally as: "How do I use Autoconf to cross compile for ARM?"
According to ./configure -h:
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
The official GNU documentation is helpful for answering this question:
http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Hosts-and-Cross_002dCompilation.html
Note when they defining the usage of --host and and --build:
Therefore, whenever you specify --host, be sure to specify --build too.
And here is an example that I just used to configure iperf for my embedded ARM platform:
First of all the "./configure" script is actually called "Autoconf" which really helps for google-ing.
The idea here is to:
Have your cross compilers in your current $PATH
Set the CC and CXX environment variables to point to the cross compilers
Give the right --host and --build
buildpath <--- my little script to setup my $PATH
export CC=arm_v5t_le-gcc
export CXX=arm_v5t_le-g++
./configure --host=armv5tl-montavista-linux-gnueabi --build=x86_64-linux-gnu

You need to override the environment variables CC, LD, and other pertinent ones. Setting those switches doesn't tell configure where your cross tool chain is (it could be anywhere)
Check out some guides for various projects, for instance:
http://wiki.wxwidgets.org/Cross-Compiling_Under_Linux
Also, here is a script I made to setup cross compile for node.js - same idea:
https://gist.github.com/edhemphill/5094239
The libjpeg is not going to work b/c it's a x86 binary, you need it to say:
ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, not stripped
or similar.
This is the reason you are getting a skipping incompatible

# Install arm-linux-gnueabi packages
apt-get install libc6-armel-cross libc6-dev-armel-cross \
binutils-arm-linux-gnueabi arm-linux-gnueabi-gcc libncurses5-dev
./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi
...
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-linux-gnueabi-gcc accepts -g... yes
checking for arm-linux-gnueabi-gcc option to accept ISO C89... none needed
checking whether arm-linux-gnueabi-gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of arm-linux-gnueabi-gcc... gcc3
...
make
arm-linux-gnueabi-gcc -DPACKAGE_NAME=\"Tutorial\ Program\" -DPACKAGE_TARNAME=\"tutorial-program\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"Tutorial\ Program\ 1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"tutorial-program\" -DVERSION=\"1.0\" -I. -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c

Related

cross compiling with autoconf

I was trying to cross compile with autoconf.
I had tried from these helps :
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html
https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html
https://github.com/jedisct1/libsodium/issues/274
Cross Compiling For ARM With Autoconf
And did -
./configure --build=x86_64-linux-gnu --host=/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf --target=/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf --disable-shared --disable-documentation
But after autoconf tool checking for the gcc and other things necessary for compilation it doesn't find these. Although they are already present in the directory.
So the log is :
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
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 whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ar... no
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-lib... no
checking for /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-link... no
checking for ar... ar
checking the archiver (ar) interface... ar
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf': machine `/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm' not recognized
configure: error: /bin/bash ./config.sub /opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf failed
This is the directory for all arm toolchain bin
host#ubuntu:/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin$ ls
arm-linux-gnueabihf-addr2line arm-linux-gnueabihf-gcc arm-linux-gnueabihf-gfortran arm-linux-gnueabihf-readelf
arm-linux-gnueabihf-ar arm-linux-gnueabihf-gcc-5.4.1 arm-linux-gnueabihf-gprof arm-linux-gnueabihf-size
arm-linux-gnueabihf-as arm-linux-gnueabihf-gcc-ar arm-linux-gnueabihf-ld arm-linux-gnueabihf-strings
arm-linux-gnueabihf-c++ arm-linux-gnueabihf-gcc-nm arm-linux-gnueabihf-ld.bfd arm-linux-gnueabihf-strip
arm-linux-gnueabihf-c++filt arm-linux-gnueabihf-gcc-ranlib arm-linux-gnueabihf-nm gdbserver
arm-linux-gnueabihf-cpp arm-linux-gnueabihf-gcov arm-linux-gnueabihf-objcopy runtest
arm-linux-gnueabihf-elfedit arm-linux-gnueabihf-gcov-tool arm-linux-gnueabihf-objdump
arm-linux-gnueabihf-g++ arm-linux-gnueabihf-gdb arm-linux-gnueabihf-ranlib
Any suggestion?
EDIT
I tried the solution suggested by Chrono. It was able to find arm toolchain. But another problem arised :
error adding symbols: File format not recognized
libtool: link: arm-linux-gnueabihf-gcc -shared -fPIC -DPIC src/.libs/libcoap_1_la-address.o src/.libs/libcoap_1_la-async.o src/.libs/libcoap_1_la-block.o src/.libs/libcoap_1_la-coap_dtls.o src/.libs/libcoap_1_la-coap_event.o src/.libs/libcoap_1_la-coap_keystore.o src/.libs/libcoap_1_la-coap_time.o src/.libs/libcoap_1_la-debug.o src/.libs/libcoap_1_la-encode.o src/.libs/libcoap_1_la-hashkey.o src/.libs/libcoap_1_la-mem.o src/.libs/libcoap_1_la-net.o src/.libs/libcoap_1_la-option.o src/.libs/libcoap_1_la-pdu.o src/.libs/libcoap_1_la-resource.o src/.libs/libcoap_1_la-str.o src/.libs/libcoap_1_la-subscribe.o src/.libs/libcoap_1_la-uri.o src/platform/posix/.libs/libcoap_1_la-coap_io.o src/platform/posix/.libs/libcoap_1_la-prng.o src/platform/posix/.libs/libcoap_1_la-run.o -L./ext/tinydtls -ltinydtls -g -O2 -Wl,--version-script=./libcoap-1.map -Wl,-soname -Wl,libcoap-1.so.0 -o .libs/libcoap-1.so.0.0.0
For this line of compilation the error is :
./ext/tinydtls/libtinydtls.a: error adding symbols: File format not recognized
EDIT 2:
The problem was with the library it is not passing the cross compiler params to the autoconf properly, hence the issue.
Ensure the directory containing your toolchain's binaries is in your $PATH:
export OLDPATH=$PATH
export PATH=$OLDPATH:/opt/toolchains/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin
You should only need to do that once, unless you log out or otherwise exit that terminal session.
With that done, you can configure properly:
./configure \
--build=x86_64-linux-gnu \
--host=arm-linux-gnueabihf \
--target=arm-linux-gnueabihf \
--disable-shared \
--disable-documentation

configure tries to test-run a cross compiled program

I try to compile something for IBM Blue Gene/Q with GCC 4.9. As a dependency I need the gmp (GNU Multi Precision) library, I use version 6.1.1. This comes with GNU Autotools.
Strangely, is has worked with LLVM before. And yesterday it did not work at noon but again in the evening and not any more today. I am thoroughly confused, honestly.
On Blue Gene/Q, you compile on an IBM PowerPC 740 and let it run on an IBM PowerPC A2 processor. Therefore you need to use the cross compiler. My configure is the following:
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure \
--prefix=/homec/hbn28/hbn28e/local-juqueen \
--host=powerpc64-bgq-linux \
--build=powerpc64-unknown-linux-gnu \
--disable-shared \
--enable-static \
CC=/bgsys/local/gcc/4.9.3/bin/mpigcc \
CXX=/bgsys/local/gcc/4.9.3/bin/mpig++ \
'CFLAGS=-O2 \
-finline-limit=50000 \
-Wall \
-Wpedantic \
-fmax-errors=1 \
-fdiagnostics-color=auto \
-Drestrict=__restrict__ \
--std=gnu99'
Error regarding CC_FOR_BUILD
The first issue has been this error.
/usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
The generated Makefile has used CC for a few files but then called itself recurively using CC=$(CC_FOR_BUILD). And that is just set to cc by default, the frontend compiler which does not do any good on the compute backend. So I have added CC_FOR_BUILD=/bgsys/local/gcc/4.9.3/bin/mpigcc to the configure flags. That fixed that error.
Testing cross compiled binary
Then the configure script runs a bit further:
checking build system type... powerpc64-unknown-linux-gnu
checking host system type... powerpc64-bgq-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc64-bgq-linux-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=mode64
checking whether /bgsys/local/gcc/4.9.3/bin/mpigcc is gcc... yes
checking compiler /bgsys/local/gcc/4.9.3/bin/mpigcc -O2 -finline-limit=50000 -Wall -Wpedantic -fmax-errors=1 -fdiagnostics-color=auto -Drestrict=__restrict__ --std=gnu99 ... yes
checking compiler /bgsys/local/gcc/4.9.3/bin/mpigcc -O2 -finline-limit=50000 -Wall -Wpedantic -fmax-errors=1 -fdiagnostics-color=auto -Drestrict=__restrict__ --std=gnu99 has sizeof(long)==8... yes
checking for powerpc64-bgq-linux-gcc... /bgsys/local/gcc/4.9.3/bin/mpigcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /bgsys/local/gcc/4.9.3/bin/mpigcc accepts -g... yes
checking for /bgsys/local/gcc/4.9.3/bin/mpigcc option to accept ISO C89... none needed
checking whether /bgsys/local/gcc/4.9.3/bin/mpigcc understands -c and -o together... yes
checking for /bgsys/local/gcc/4.9.3/bin/mpigcc option to accept ISO C99... none needed
checking for /bgsys/local/gcc/4.9.3/bin/mpigcc option to accept ISO Standard C... (cached) none needed
checking how to run the C preprocessor... /bgsys/local/gcc/4.9.3/bin/mpigcc -E
checking build system compiler /bgsys/local/gcc/4.9.3/bin/mpigcc... no
configure: error: Specified CC_FOR_BUILD doesn't seem to work
Looking at config.log, it says
configure:9899: checking build system compiler /bgsys/local/gcc/4.9.3/bin/mpigcc
configure:9912: /bgsys/local/gcc/4.9.3/bin/mpigcc conftest.c
configure:9915: $? = 0
/bgsys/source/srcV1R2M4.29840/comm/sys/buildtools/pami/common/bgq/BgqPersonality.h:102:
/bgsys/source/srcV1R2M4.29840/comm/sys/buildtools/pami/common/bgq/BgqPersonality.h<102>
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 10000: 26929 Aborted (core dumped) ./a.out
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./b.out: No such file or directory
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./a.exe: No such file or directory
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./a_out.exe: No such file or directory
/homec/hbn28/hbn28e/Sources/gmp-6.1.1/configure: line 9917: ./conftest: No such file or directory
configure:9922: result: no
configure:9927: error: Specified CC_FOR_BUILD doesn't seem to work
It seems to use the correct compiler. When running the program on the frontend (where I compile), it fails since the BgqPersonality.h has special information about the compute backend, the program just cannot run on the frontend.
configure assumes that the compiler is broken (which it arguably is for the frontend) and stops building. Previously I had neither error with LLVM, the cross compilation has just worked fine. configure even says checking whether we are cross compiling... yes so it must be aware of the situation. Perhaps the CC_FOR_BUILD is meant for the frontend whereas CC is for the compute backend. Without CC_FOR_BUILD I cannot compile as written above.
Is there some way to get this cross compiled properly?
CC_FOR_BUILD is supposed to be a compiler that can compile tools for the current system, rather than the one you want to build the binaries for. The name comes from the fact that CBUILD is the name to reference the system the build happens on.
I wrote a blog post some time ago that explains the nomenclature of these systems and how they are supposed to be used.

Compiling sources with a non-default compiler

I need to implement an authentication scheme on an embedded device and require gmp in order to perform large integer operations.
After downloading the sources they must be compiled with a proprietary version of compile tools in order to be able to statically link libraries(only one binary can be uploaded onto the controller at a time).
After running configure the following make file is produced.
Running make with the proprietary compiler
make CC=/home/TI/ccsv5/tools/compiler/gcc-arm-none-eabi-4_7-2012q4/arm-none-eabi/bin/gcc
gives the following errors:
make[2]: Entering directory `/home/TI_workspace/gmp-6.0.0/mpn'
/bin/bash ../libtool --tag=CC --mode=compile /home/TI/ccsv5/tools/compiler/gcc-arm-none-eabi-4_7-2012q4/arm-none-eabi/bin/gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo fib_table | sed 's/_$//'` -O2 -pedantic -fomit-frame-pointer -c -o fib_table.lo fib_table.c
libtool: compile: /home/TI/ccsv5/tools/compiler/gcc-arm-none-eabi-4_7-2012q4/arm-none-eabi/bin/gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_fib_table -O2 -pedantic -fomit-frame-pointer -c fib_table.c -fPIC -DPIC -o .libs/fib_table.o
gcc: error trying to exec 'cc1': execvp: No such file or directory
make[2]: *** [fib_table.lo] Error 1
make[2]: Leaving directory `/home/TI_workspace/gmp-6.0.0/mpn'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/TI_workspace/gmp-6.0.0'
make: *** [all] Error 2
cc1 is located in:
$ sudo find . -name cc1 -print
./ccsv5/tools/compiler/gcc-arm-none-eabi-4_7-2012q4/lib/gcc/arm-none-eabi/4.7.3/cc1
Is it possible to generate a makefile so that it uses the proprietary tool chain instead of the default one? If yes, how should it be configured?
Edit:
Bellow are the ./configure options:
$ ./configure --help
`configure' configures GNU MP 6.0.0 to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
Defaults for the options are specified in brackets.
Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking ...' messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache'
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..']
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc. You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
For better control, use the options below.
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/gmp]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
Program names:
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM run sed PROGRAM on installed program names
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
--enable-assert enable ASSERT checking [[default=no]]
--enable-alloca how to get temp memory [[default=reentrant]]
--enable-cxx enable C++ support [[default=no]]
--enable-assembly enable the use of assembly loops [[default=yes]]
--enable-fft enable FFTs for multiplication [[default=yes]]
--enable-old-fft-full enable old mpn_mul_fft_full for multiplication
[[default=no]]
--enable-nails use nails on limbs [[default=no]]
--enable-profiling build with profiler support [[default=no]]
--enable-fat build a fat binary on systems that support it
[[default=no]]
--enable-minithres choose minimal thresholds for testing [[default=no]]
--enable-fake-cpuid enable GMP_CPU_TYPE faking cpuid [[default=no]]
--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-static[=PKGS] build static libraries [default=yes]
--enable-fast-install[=PKGS]
optimize for fast installation [default=yes]
--disable-libtool-lock avoid locking (might break parallel builds)
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-readline readline support in calc demo program
[[default=detect]]
--with-pic[=PKGS] try to use only PIC/non-PIC objects [default=use
both]
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--with-sysroot=DIR Search for dependent libraries within DIR
(or the compiler's sysroot if not specified).
Some influential environment variables:
ABI desired ABI (for processors supporting more than one ABI)
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
CC_FOR_BUILD
build system C compiler
CPP_FOR_BUILD
build system C preprocessor
CXX C++ compiler command
CXXFLAGS C++ compiler flags
CXXCPP C++ preprocessor
M4 m4 macro processor
YACC The `Yet Another Compiler Compiler' implementation to use.
Defaults to the first program found out of: `bison -y', `byacc',
`yacc'.
YFLAGS The list of arguments that will be passed by default to $YACC.
This script will default YFLAGS to the empty string to avoid a
default value of `-d' given by some make applications.
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

make error: Building 64-bit GSL in Cygwin

Continuing from here, I am trying to build 64-bit GSL using GCC in Cygwin.
The call to ./configure (CC=x86_64-w64-mingw32-gcc CFLAGS=-m64 ./configure) goes through fine, but the call to make install results, after a whole load of folders are successfully processed, in
./.libs/libgslsiman.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
Makefile:326: recipe for target `siman_tsp.exe' failed
The full call that caused this was
Making all in siman
make2: Entering directory `/cygdrive/f/programming/c/libraries/gslCompiled/gsl-1.15/siman'
/bin/sh ../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -m64 -o siman_tsp.exe siman_tsp.o libgslsiman.la ../rng/libgslrng.la ../ieee-utils/libgslieeeutils.la ../err/libgslerr.la ../sys/libgslsys.la ../utils/libutils.la -lm
libtool: link: x86_64-w64-mingw32-gcc -m64 -o .libs/siman_tsp.exe siman_tsp.o ./.libs/libgslsiman.a ../rng/.libs/libgslrng.a ../ieee-utils/.libs/libgslieeeutils.a ../err/.libs/libgslerr.a ../sys/.libs/libgslsys.a ../utils/.libs/libutils.a
Following advice here, I decided to run a ranlib in the ./siman/.libs directory on the libgslsiman.a file. Since that didn't work, I also tried to pack it myself using a call to ar -t libgslsiman.a.
However, this results in an identical error.
You manually forced use of the cross compiler. However, the rest of the build toolchain will still default to the 32-bit Cygwin versions instead of the 64-bit MinGW ones.
Instead of setting CC=..., pass --host x86_64-w64-mingw32 to ./configure to specify the host environment (ie where the library is going to be used).

Specifying Exact Library to Link with In Automake

I am having extreme trouble cross compiling a project related to gstreamer. I am trying to link it to a library on my cross compile machine's /usr/lib
If I do the standard linker flags -L{FILESYS_DIR}/usr/lib -lGLESv2 I get pthread complaints from my cross compile toolchain. Thus, I am trying to link to this library without using the -L flag.
No matter what I do, I am getting undefined symbol glFramebuffer2D. However a quick readelf -Wc $FILESYS_DIR/usr/lib/libGLESv2.so | glFrame shows me a glFramebuffer2D symbol.
I'm pulling my hair out because no matter what flags I specify to autoconf, something called libtool throws away my link request unless I use the -L -l approach...
Edit: I had another idea, I tried -Wl, $FILESYS_DIR/usr/lib/libGLESv2.so which worked in compiling and linking but not during runtime... Obvious to me (now) because the host machine root is $FILESYS_DIR. Anyways, this is on the right approach, but I guess I need relative names.
libtool: link: arm-none-linux-gnueabi-gcc -shared .libs/libgstbla_la-gstblaoverlay.o
.libs/libgstbla_la-gstblastabilize.o .libs/libgstbla_la-gles2_utilities.o -Wl,-
rpath -Wl,/home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib -Wl,-rpath -
Wl,/home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib -L/home/z3/z3-
netra/filesys/fs/opt/gstreamer/lib /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libgstbase-0.10.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libgstreamer-0.10.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libgstvideo-0.10.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libgobject-2.0.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libgmodule-2.0.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libgthread-2.0.so -lrt /home/z3/z3-netra/filesys/fs//opt/gstreamer-
0.4/lib/libglib-2.0.so -pthread -Wl,-soname -Wl,libgstbla.so -Wl,-version-script -
Wl,.libs/libgstbla.ver -o .libs/libgstbla.so
If needed, in one line as well:
libtool: link: arm-none-linux-gnueabi-gcc -shared .libs/libgstbla_la-gstblaoverlay.o .libs/libgstbla_la-gstblastabilize.o .libs/libgstbla_la-gles2_utilities.o -Wl,-rpath -Wl,/home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib -Wl,-rpath -Wl,/home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib -L/home/z3/z3-netra/filesys/fs/opt/gstreamer/lib /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libgstbase-0.10.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libgstreamer-0.10.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libgstvideo-0.10.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libgobject-2.0.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libgmodule-2.0.so /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libgthread-2.0.so -lrt /home/z3/z3-netra/filesys/fs//opt/gstreamer-0.4/lib/libglib-2.0.so -pthread -Wl,-soname -Wl,libgstbla.so -Wl,-version-script -Wl,.libs/libgstbla.ver -o .libs/libgstbla.so
/usr/lib should already be on the library search path, so you shouldn't need to specify an RPATH. What you do need to do though, is to tell your (cross-)linker where to find the libraries. I think that includes transitively dependencies, such as libpthread. Do you have $FILESYS_DIR/usr/lib/libpthread.so? Does it point to /lib/libpthread.so.N? Oh wait, I see something now that I wrote it out: notice the (likely) absence of $FILESYS_DIR there: so it's possible that your linker is looking for libpthread transitively needed by libGLESv2, but not finding it, since $FILESYS_DIR/lib is not on the library include path. Add -L $FILESYS_DIR/lib to your linker flags and try again.
All, this was related to the following question: set global gcc default search paths
The problem here is related to the pthread.so (also glib.so). /usr/lib/pthread.so on a lot of systems is an ASCII script which then further links to the system's /lib/pthread.so.0 (which is a soft link). When compiling, my $(FILESYS_DIR) was correct, however the the libpthread.so there pointed to the host systems pthread.so
I made a HUGE mistake here which could have been easily avoided with correct cross compilation management. When compiling for a target system, do not use files on the target system filesystem (if it's a NFS as mine was.) Use local libraries compiled for that target system. FURTHERMORE, specify -Wl,-rpath-link=/[local location where your *.so reside]
That compiler/linker flag allows for the runtime path to be on the local system during compile and link, but maintain the standard runtime path during runtime.... Hope that made sense.

Resources