I am able to make a shared library without problems. I create libcbitcoin.so (without any errors) and attempt to link against it with an executable as well as OpenSSL libraries. I use this command:
gcc -L/media/sf_BitEagle_Projects/cbitcoin/build/bin -lcbitcoin \
-Wl-rpath,/media/sf_BitEagle_Projects/cbitcoin/build/bin -lssl -lcrypto \
-L/usr/local/ssl/lib/ -o /media/sf_BitEagle_Projects/cbitcoin/build/bin/testCBAddress \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/testCBAddress.o \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/CBOpenSSLCrypto.o
The bin directory is the location of the library. The obj directory has the object files I wish to link into an executable. In the command I use the -L, -l and -rpath* options which I thought was all that is needed for linking in Linux. It seems I am wrong since I get errors like:
/media/sf_BitEagle_Projects/cbitcoin/test/testCBAddress.c:40:
undefined reference to `CBNewByteArrayFromString'
CBNewByteArrayFromString is found in the library. For some reason it is not being linked. OpenSSL too:
/media/sf_BitEagle_Projects/cbitcoin/dependencies/crypto/CBOpenSSLCrypto.c:37:
undefined reference to `SHA1'
How do I get the linking to work?
GCC version: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
It is on Linux Mint 13 (Maya).
Put the libraries after the object files on the link command line:
gcc /media/sf_BitEagle_Projects/cbitcoin/build/obj/testCBAddress.o \
/media/sf_BitEagle_Projects/cbitcoin/build/obj/CBOpenSSLCrypto.o \
-L/media/sf_BitEagle_Projects/cbitcoin/build/bin \
-lcbitcoin -Wl-rpath,/media/sf_BitEagle_Projects/cbitcoin/build/bin \
-L/usr/local/ssl/lib/ -lssl -lcrypto \
-o /media/sf_BitEagle_Projects/cbitcoin/build/bin/testCBAddress
If you don't do that, the linker may decide that it needs nothing from a particular library at the stage of the link where it scans the library, and then it won't rescan the library later after it finds some undefined symbols in the object files. If you put the object files first, you don't run into this problem.
I think it is caused by can not find symbol. GCC will first go through from the left and will try to put the library file at the end.
Related
I have a C99 shared library that I want to link in a few statically static libraries (via --whole-archive). Note: All the static libs are built with -fPIC
I also would like to build a universal linux binary and thus have decided to use musl. When I try to link in the static libc.a from musl I get the following error:
# Building shared library tgt/Linux-x86_64/mylib/lib/mylib.so
/root/mylib/./tgt/Linux-x86_64/libmusl/bin/musl-gcc -Wl,-whole-archive -L./tgt/Linux-x86_64/libmusl/lib -L./tgt/Linux-x86_64/libz/lib -L./tgt/Linux-x86_64/libssl/lib -L./tgt/Linux-x86_64/libsasl/lib -L./tgt/Linux-x86_64/librdkafka/lib -L./tgt/Linux-x86_64/libcurl/lib -L./tgt/Linux-x86_64/libgjalloc/lib -L./tgt/Linux-x86_64/libavro/lib -L./tgt/Linux-x86_64/libunwind/lib -l:libc.a -l:libpthread.a -l:libz.a -l:libssl.a -l:libcrypto.a -l:libsasl2.a -l:libm.a -l:librt.a -l:libcrypt.a -l:libunwind-x86_64.a -l:librdkafka.a -l:libcurl.a -l:libgjalloc.a -l:libavro.a -Wl,-no-whole-archive -shared -fPIC -o tgt/Linux-x86_64/mylib/lib/mylib.so ./tgt/Linux-x86_64/mylib/obj/myfile.o ./tgt/Linux-x86_64/mylib/obj/myotherfile.o ./tgt/Linux-x86_64/mylib/obj/cJSON.o
/usr/bin/ld: ./tgt/Linux-x86_64/libmusl/lib/libc.a(exit.lo): relocation R_X86_64_PC32 against undefined hidden symbol `__fini_array_start' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make: *** [tgt/Linux-x86_64/mylib/lib/mylib.so] Error 1
My musl build looks like:
cd mystatic_libs_build_dir/musl; \
./configure CFLAGS='-fPIC' \
--enable-shared \
--enable-static \
--prefix=/root/mylib/tgt/Linux-x86_64/libmusl; \
make; make install;
# libmusl is available
exit.lo will be written in assembler which is why your CFLAGS='-fPIC' is not having the effect you intend. This is either 1. a bug in 'musl' or 2. intentional and they do not support statically linking into .so's.
I would assume that it is unintentional and file a bug against 'musl'
You could also edit the asm yourself if you need a fix quickly.
Finally you might be able to configure musl to build with no asm?
Slightly off topic, but other options for a universal binary are:
Simply linking against glibc on the oldest version of Linux that you support.
Rather than struggling with a dependency on 'musl', simply use the Linux kernel api's directly.
Recompile musl as long as your own code with CFLAGS="-fPIC -Wa,-mrelax-relocations=no" (your binutils version must be >=2.27).
I would like to generate MIPS binaries using gcc on an x86 machine. In order to install MIPS cross-compiler I followed the directions on this page. I could install gcc and binutils successfully. I tried to to compile a simple hello world program using the cross compiler.
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -mips1 hi.c
I got the following error.
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find -lc
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
I did some research online to figure out what the problem was, and changed the command I used to the following.
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -B/usr/lib/i386-linux-gnu -mips1 hi.c
Now I get this error message:
/opt/cross/lib/gcc/mipsel-unknown-linux-gnu/4.8.2/../../../../mipsel-unknown-linux-gnu/bin/ld: /usr/lib/i386-linux-gnu/crt1.o: Relocations in generic ELF (EM: 3)
/usr/lib/i386-linux-gnu/crt1.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
I am not sure what the problem is. The only thing I can think of is the "--without-headers" option passed to configure program when building gcc. Configure command for gcc given on the linux-mips page is as below.
% ../gcc-3.8.2/configure --target=$TARGET --prefix=$PREFIX \
--enable-languages=c --without-headers \
--with-gnu-ld --with-gnu-as \
--disable-shared --disable-threads \
--disable-libmudflap --disable-libgomp \
--disable-libssp --disable-libquadmath \
--disable-libatomic
I would appreciate some help. The system on which I generated the cross compiler uses gcc4.7.2-5. I used the sources for gcc-4.8.2 and binutils-2.24 to generate the cross compiler.
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -mips1 hi.c
Add a SYSROOT to the compile command. It should look similar to:
/opt/cross/bin/mipsel-unknown-linux-gnu-gcc -mips1 --sysroot=/opt/cross/... hi.c
The SYSROOT will provide the header and library path automatically (rather than adding -I and -L individually).
You will know when you have a SYSROOT because there will be a bin/, include/ and lib/ in the path used. For example, here's a SYSROOT for arm-linux-gnueabi (i.e., arm-linux-gnueabi-gcc and arm-linux-gnueabi-g++):
$ ls /usr/arm-linux-gnueabi
bin include lib
So, in this example, you would use --sysroot=/usr/arm-linux-gnueabi.
If you need help with locating a SYSROOT, then perform a find:
$ find /usr -name crt1.o
/usr/arm-linux-gnueabi/lib/crt1.o
/usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o
/usr/lib/x86_64-linux-gnu/crt1.o
In your case, you would probably search from /opt/cross. Obviously, you would want the one for the target (arm-linux-gnueabi), and not the ones for the host (x86_64-linux-gnu).
Adding --sysroot= would resolve this issue.
As you are cross-compiling you shouldn't select just any other folder which has crt1.o or crtX.o as your sysroot directory. It could be your host-machine's files. (Which if you are running on a x86, it would be for x86). Again it varies from 32bit and 64bit.
With newer version's of GCC toolchain, you need to have a sdk part of it which has the appropriate sysroot and crt1.o. This should go with your ABI and your target architecture.
I would like to install the nccmp program to compare netCDF files.
Checking the documentation, the installation follows the typical structure:
./configure
make
make check
make install
make clean
However, I'm stuck in the first step because the configure is not able to find my netCDF libraries. But I don't know why.
My libs are not in the default folder, I've installed them in /opt. But I've included the path of the netCDF libs in my LD_LIBRARY_PATH variable.
I tried also to create a link in the default lib folder to my netCDF libs
ln /opt/netcdf-4.2.1.1/lib/libnetcdf.so /usr/lib/libnetcdf.so
ln /opt/netcdf-4.2.1.1/lib/libnetcdff.so /usr/lib/libnetcdff.so
ln /opt/netcdf-4.2.1.1/lib/libnetcdf.a /usr/lib/libnetcdf.a
ln /opt/netcdf-4.2.1.1/lib/libnetcdff.a /usr/lib/libnetcdff.a
But it doesn't work either. I explicitly used the path in the call
./configure --libdir=/opt/netCDF/
I set LIBS and LDFLAGS to
LDFLAGS=-L/opt/netcdf-4.2.1.1/lib/
LIBS=/opt/netcdf-4.2.1.1/lib/
and execute configure then, but with the same bad results:
checking for nc_open in -lnetcdf... no
configure: error: in `/opt/nccmp':
configure: error: Required NetCDF library not found!
In the config.log I see:
configure:3763: gcc -o conftest -g -O2 conftest.c -lnetcdf -lm >&5
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libnetcdf.a(libnetcdf4_la-nc4file.o): In function nc4_rec_read_types':
/opt/NETCDF_BUILD/netcdf-4.2.1.1/libsrc4/nc4file.c:1850: undefined reference toH5Gget_create_plist'
and many more similar lines like that one...
I don't know what else to try, so any help would be really appreciated.
Thanks.
I already found the problem... I needed, as expected, to define LDFLAGS and CFLAGS in my shell and export them to allow the access of configure to those variables.
I'm trying to cross-compile Qt5 for the Freescale i.MX6 processor. I've already built an image using the latest Yocto package.
Before compilation of qtbase, a test for OpenGL functionality is first ran by compiling an some OpenGL code. However, during this test the compiler complains that an incompatible libc.so.6 is found.
I've discovered in another post (which I can't find at the moment), that such an error occurs because /lib/libc.so.6 is actually a symbolic link which points to the actual shared object file. However, the compiler does not use the shared object file pointed to by libc.so.6, instead trying to link to the symbolic link itself, thus the compatibility issue.
Here is the output when the configure script is ran:
OpenGL ES 2.x auto-detection... ()
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -c -pipe -mfloat-abi=softfp -O2 -O2 -march=armv7-a -mfpu=neon -DLINUX=1 -DEGL_API_FB=1 -Wall -W -fPIE -I../../../mkspecs/devices/linux-imx6-g++ -I. -I/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/include -o opengles2.o opengles2.cpp
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -Wl,-rpath-link,/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/lib -Wl,-O1 -o opengles2 opengles2.o -L/home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/lib -lGLESv2 -lEGL -lGAL
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /lib/libc.so.6
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: skipping incompatible /usr/lib/libc_nonshared.a when searching for /usr/lib/libc_nonshared.a
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /usr/lib/libc_nonshared.a
/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.7.2/ld: cannot find /lib/ld-linux.so.3
collect2: error: ld returned 1 exit status
gmake: *** [opengles2] Error 1
OpenGL ES 2.x disabled.
The OpenGL ES 2.0 functionality test failed!
Here is the script I used to supply the proper options to the configure script:
#!/bin/sh
./configure -v -opensource -confirm-license -no-pch -opengl es2 \
-make libs -device imx6 \
-make examples -make demos \
-device-option CROSS_COMPILE=/home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
-sysroot /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint -no-gcc-sysroot \
-prefix /opt/qt5
At the moment, I'm considering just renaming the actual shared object file to libc.so.6, but that doesn't seem like a good way to fix things.
It seems that you are compiling against the wrong libc. The location of the correct libc should be: /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/lib/ Can you check that? Run in that folder:
file libc.so.6
Have a look if the architecture is fine. I do not have the sources in front of me, so please give feedback if things are going wrong.
Your application is compiled in a chroot environment (see man chroot). The folder /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint acts as the new rootfolder for your application. This is configured in the -sysroot option of your configure script. This is not valid for gcc, because the -no-gcc-sysroot is on. So the linker is looking to your native /lib/ folder to find the libraries. They are not there of course.
So, can you try the following things:
1) remove the -no-gcc-sysroot option in the configure script. Configure again and try to make.
2) This can possibly fail because the compiler does not find back it's own components. Please mount the directory of the compiler into your chroot enviroment. Run the next commands:
mkdir /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/bin -p
mount --bind /home/Desktop/poky-dylan-9.0.0/build/tmp/sysroots/x86_64-linux/usr/bin/ /home/Desktop/poky-dylan-9.0.0/build/tmp/deploy/images/mountpoint/usr/bin
Configure again and try again to make.
3) If it still is not working, the cross-compiler is not set properly. Change into the configure script argument list the CROSS_COMPILE argument:
CROSS_COMPILE=/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
I wish you good luck. Let me know if it is working or not.
Building and installing OpenSSL 1.0.0.e worked without problems, all I had to do was to setup the correct compiler in the Makefile.
Compiling libCURL without OpenSSL works fine but when compiling with OpenSSL using
./configure --host=mipsel-angstrom-linux PCRECONFIG=/usr/local/crosstoolchain/usr/local/bin/pcre-config --with-openssl
I get the following error message:
ld: libssl.a(s2_clnt.o): relocation R_MIPS_HI16 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
libssl.a: could not read symbols: Bad value
I tried to compile OpenSSL with -fPIC and also tried to use -fPIC for libCURL to no avail. How can I fix this problem?
I think this works best, since it doesn't involve hacking files.
./Configure linux-x86_64 -fPIC
I found this by running
./config -h
and making a few guesses. I confirmed it works by using
grep PIC Makefile
Open the OpenSSL file called Configure in the root of the tarball. Move down to around line 610 and you will see the following for MIPS (find a better match if this is poor):
"vxworks-mips","ccmips:-mrtp -mips2 -O -G 0 -B\$(WIND_BASE)/host/\$(WIND_HOST_TYPE)/lib/gcc-lib/ -D_VSB_CONFIG_FILE=\"\$(WIND_BASE)/target/lib/h/config/vsbConfig.h\" -DCPU=MIPS32 -msoft-float -mno-branch-likely -DTOOL_FAMILY=gnu -DTOOL=gnu -fno-builtin -fno-defer-pop -DNO_STRINGS_H -I\$(WIND_BASE)/target/usr/h -I\$(WIND_BASE)/target/h/wrn/coreip::-D_REENTRANT:VXWORKS:-Wl,--defsym,__wrs_rtp_base=0xe0000000 -L \$(WIND_BASE)/target/usr/lib/mips/MIPSI32/sfcommon::${mips32_asm}:o32::::::ranlibmips:",
Add -fPIC to the options used.
Alternately, open the OpenSSL file called Makefile.org in the root of the tarball. Move down to around line 60 and you will see the following:
CC= gcc
Add the following as CC:
CC= gcc -fPIC
Its kind of a hack because you want to do that for CFLAGS, but the Makefile does not intake the macro.
Or, you can wait until OpenSSL's configure is complete (i.e., after running ./config), and then open all the makefiles and add it to the CFLAGS created from the Makefile.org template. Be sure to visit makefiles in subdirectories like crypto and engines.
The final solution for OpenSSL is to add a custom line to config and Configure. Ben Laurie and other do it when they perform custom builds. Search config and Configure for "debug-ben" or "ben-debug" or similar.
For libcurl, I believe that's an automake project. Simply perform the following:
$ export CFLAGS="-fPIC"
$ ./config