Undefined references when linking mariadb C connector - c

I've had some (too many) hours trying to make mariadb C connector to work with my own code. MySQL C connector worked fine, but I decided to migrate to mariadb.
Finally I decided to try a minimal code to check if the problem was with my code or the environment, and I got the same error. The code is from this question at SO: Using MariaDB in C.
#include <my_global.h>
#include <mysql.h>
int main(int argc, char **argv)
{
MYSQL *con = mysql_init(NULL);
if (con == NULL)
{
fprintf(stderr, "%s\n", mysql_error(con));
exit(1);
}
if (mysql_real_connect(con, "localhost", "root", "root_pswd",
NULL, 0, NULL, 0) == NULL)
{
fprintf(stderr, "%s\n", mysql_error(con));
mysql_close(con);
exit(1);
}
if (mysql_query(con, "CREATE DATABASE testdb"))
{
fprintf(stderr, "%s\n", mysql_error(con));
mysql_close(con);
exit(1);
}
mysql_close(con);
exit(0);
}
and tried to compile it with
gcc -v -o mysql-test mysql-test.c $(mariadb_config --libs)
expanded to
gcc -v -o mysql-test mysql-test.c $(mariadb_config --libs)
The output I got is
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-o' 'mysql-test' '-L/usr/local/lib/mariadb' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.3/cc1 -quiet -v mysql-test.c -quiet -dumpbase mysql-test.c -mtune=generic -auxbase mysql-test -version -o /tmp/ccISncmQ.s
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/4.3/include
/usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
GNU C (SUSE Linux) version 4.3.4 [gcc-4_3-branch revision 152973] (x86_64-suse-linux)
compiled by GNU C version 4.3.4 [gcc-4_3-branch revision 152973], GMP version 4.2.3, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 91a878d77972b76d647d592fefc786fc
COLLECT_GCC_OPTIONS='-v' '-o' 'mysql-test' '-L/usr/local/lib/mariadb' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/as -V -Qy -o /tmp/ccD2nseu.o /tmp/ccISncmQ.s
GNU assembler version 2.20.0 (x86_64-suse-linux) using BFD version (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9
COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'mysql-test' '-L/usr/local/lib/mariadb' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.3/collect2 --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o mysql-test /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/4.3/crtbegin.o -L/usr/local/lib/mariadb -L/usr/lib64/gcc/x86_64-suse-linux/4.3 -L/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.3/../../.. /tmp/ccD2nseu.o -lmariadb -lssl -lnsl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib64/gcc/x86_64-suse-linux/4.3/crtend.o /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_get_error#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_get_peer_certificate#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_CTX_load_verify_locations#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_set_ex_data#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `X509_STORE_CTX_get_error_depth#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_get_ex_data#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_write#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_clear#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `CRYPTO_THREADID_set_numeric#OPENSSL_1.0.0'
/usr/local/lib/mariadb/libmariadb.so: undefined reference to `SSL_COMP_get_compression_methods#OPENSSL_1.0.0'
...
LibOpenSSL 1.0.0 is installed and library in library path. I had to install libopenssl-devel, too.
At $LD_LIBRARY_PATH there is a libssl.so link to /lib64/libssl.so.1.0.0. If I execute
nm -g /usr/lib64/libssl.so
I get
nm: /usr/lib64/libssl.so: no symbols
libopenssl 0.9.8 is also installed
# rpm -qa | grep libopenssl
libopenssl0_9_8-0.9.8h-30.27.11
libopenssl-devel-1.0.0c-17.1
libopenssl0_9_8-32bit-0.9.8h-30.27.11
libopenssl1_0_0-1.0.0c-17.1
Any clue? Thanks!
Updated: Output of ldd
# ldd /usr/local/lib/mariadb/libmariadb.so
/usr/local/lib/mariadb/libmariadb.so: /lib64/libcrypto.so.1.0.0: no version information available (required by /usr/local/lib/mariadb/libmariadb.so)
/usr/local/lib/mariadb/libmariadb.so: /lib64/libssl.so.1.0.0: no version information available (required by /usr/local/lib/mariadb/libmariadb.so)
/usr/local/lib/mariadb/libmariadb.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/lib/mariadb/libmariadb.so)
linux-vdso.so.1 => (0x00007fff2d90f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f08bc078000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f08bbe73000)
libm.so.6 => /lib64/libm.so.6 (0x00007f08bbc1d000)
libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f08bb9c1000)
libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f08bb60f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f08bb2b1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f08bc521000)
libz.so.1 => /lib64/libz.so.1 (0x00007f08bb099000)
glicbc_2.14 not found, but it seems that libc.so.6 should be fine. At OpenSuse 11.4 repository glibc version is glibc-2.11.3-12.15.1.x86_64.rpm
Update 2: I succeeded in showing the symbos with
objdump -tT /usr/lib64/libssl.so
and the symbols are there
Update 3 and solution (workaround):
main problem is that libmariadb.so requires glibc 2.14, while at opensuse 11.4 glibc version is 2.11. Installing glibc 2.14 from opensuse 12.1 involved a severe upgrade of the system I could not do.
I also tried to use the connector from 2.0 series. It also failed with similar messages.
Next, I looked for 1.0 series. I read that previously the connector was named libmariadbclient and remembered that I installed a libmariadbclient package, so I changed linker flags to -lmariadbclient and... it worked!
But the linker didn't use the library from the libmariadbclient package, but the static library included with the connector (libmariadbclient.a). So linking statically the connector worked for me.

MariaDB Connector/C requires OpenSSL 1.0.1 or newer.
See Prerequisites For Building Connector/C From Source
Please also note, that OpenSSL versions < 1.0.2 are eoled and might be vulnerable.

Related

Mingw64 / Msys2 - gcc unable to find headers in its own include dir

I recently installed MSYS2 following Steely Wing's answer on this thread: How to install MinGW-w64 and MSYS2?
The final goal is to compile a project on Windows in order to create an executable that I can use with an installer.
But here comes the problem: when I use make, gcc does not find err.h:
src/debug/error_handler.c:2:10: fatal error: err.h: No such file or directory
2 | #include <err.h>
| ^~~~~~~
compilation terminated.
make: *** [Makefile:26: imagin] Interrupt
After some searching I found out that it could come from the MinGW's default Include path. Thus following this: http://mingw.org/wiki/IncludePathHOWTO, I created an empty foo.c and executed gcc -v foo.c:
Configured with: ../gcc-9.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --enable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 9.2.0 (Rev2, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/cc1.exe -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/ -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o C:\msys64\tmp\ccXlDSUc.s
GNU C17 (Rev2, Built by MSYS2 project) version 9.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP
warning: GMP header version 6.1.2 differs from library version 6.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/include-fixed"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/include-fixed
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C17 (Rev2, Built by MSYS2 project) version 9.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP
warning: GMP header version 6.1.2 differs from library version 6.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3bcdf03344e3ad7cb057c2ec82f696e6
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/as.exe -v -o C:\msys64\tmp\cckgYpTe.o C:\msys64\tmp\ccXlDSUc.s
GNU assembler version 2.33.1 (x86_64-w64-mingw32) using BFD version (GNU Binutils) 2.33.1
COMPILER_PATH=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/;C:/msys64/mingw64/bin/../lib/gcc/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/;C:/msys64/mingw64/bin/../lib/gcc/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/collect2.exe -plugin C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/liblto_plugin-0.dll -plugin-opt=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe -plugin-opt=-fresolution=C:\msys64\tmp\cch1aQIi.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -m i386pep -Bdynamic C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/crtbegin.o -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0 -LC:/msys64/mingw64/bin/../lib/gcc -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../lib -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib -LC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../.. C:\msys64\tmp\cckgYpTe.o -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/default-manifest.o C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/crtend.o
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): in function `main':
D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18: undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
This is a bit messy but I think the interesting part is there:
#include "..." search starts here:
#include <...> search starts here:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/include-fixed
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/include
Considering the fact that err.h comes from openssl that I installed using https://packages.msys2.org/package/mingw-w64-x86_64-openssl, openssl folder is included in /mingw64/include. But gcc does not find it.
I tried to use -I/mingw64/include in my CFLAGS, but it did not work. I tried with -I/mingw64/include/openssl and it worked, but now gcc considers errx function as unititialized, as if, before, gcc never went in the openssl folder. I tried to add -L/mingw64/lib but it did not work.
Any help is appreciated, thank's by advance. DO NOT hesitate to ask for any precision I could have miss here.
After hours of searching I found out that there was no err.h on MSYS2, see https://github.com/cliffordwolf/icestorm/issues/85 and resolved my case by replacing all my errx() function calls following these method https://github.com/cliffordwolf/icestorm/pull/88/commits/9acaac752ac53b51b9b33290394b7811048221fa.

undefined reference to "readline" in c file on ubuntu 18.04 (libreadline-dev installed, linked with "-lreadline"

I'm aware that there are many threads about this on Stackoverflow but non of the solutions helped me. I'm using Ubuntu 18.04 with all the stuff that a dev typically needs: build-essential, libreadline-dev, ...
I had a look in /usr/include/readline but readline is definitely there!
gcc always tells me:
undefined reference to "readline"
This happens by the way independently if i'm linking with "-lreadline" or not.
Edit
As user #Kamil Cuk already provided the simple solution I'd like to add some more information:
$ gcc -lreadline -o code code.c
works on MacOS with apple-gcc (which uses clang) as well as with gnu-gcc (installed via brew). Only on Ubuntu the linker-flag has to be after "code.c"
(perhaps because Ubuntu uses gcc-7 and on my Mac I'm using gcc-8)
Edit end
code.c
#include <stdlib.h>
#include <stdio.h>
#include <readline/readline.h>
int main(void) {
char * buffer = readline("enter sth: ");
printf("%s\n", buffer);
printf("bye!\n");
}
libreadline-dev package info
dpkg -L libreadline-dev
/.
/usr
/usr/include
/usr/include/readline
/usr/include/readline/chardefs.h
/usr/include/readline/history.h
/usr/include/readline/keymaps.h
/usr/include/readline/readline.h
/usr/include/readline/rlconf.h
/usr/include/readline/rlstdc.h
/usr/include/readline/rltypedefs.h
/usr/include/readline/tilde.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libhistory.a
/usr/lib/x86_64-linux-gnu/libreadline.a
/usr/share
/usr/share/doc
/usr/share/info
/usr/lib/x86_64-linux-gnu/libhistory.so
/usr/lib/x86_64-linux-gnu/libreadline.so
/usr/share/doc/libreadline-dev
gcc command
$ gcc -L/usr/lib/x86_64-linux-gnu -lreadline -Wall -Werror -v -o code code.c
gcc err output
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-L/usr/lib/x86_64-linux-gnu' '-Wall' '-Werror' '-v' '-o' 'code' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/cc1 -quiet -v -imultiarch x86_64-linux-gnu code.c -quiet -dumpbase code.c -mtune=generic -march=x86-64 -auxbase code -Wall -Werror -version -fstack-protector-strong -Wformat-security -o /tmp/ccLBo26t.s
GNU C11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c8081a99abb72bbfd9129549110a350c
COLLECT_GCC_OPTIONS='-L/usr/lib/x86_64-linux-gnu' '-Wall' '-Werror' '-v' '-o' 'code' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccqaH7jD.o /tmp/ccLBo26t.s
Die GNU-Assembler-Version 2.30 (x86_64-linux-gnu) benutzt die BFD-Version (GNU Binutils for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-L/usr/lib/x86_64-linux-gnu' '-Wall' '-Werror' '-v' '-o' 'code' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccYuIgyM.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o code /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. -lreadline /tmp/ccqaH7jD.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
/tmp/ccqaH7jD.o: In Funktion »main«:
code.c:(.text+0x10): Warnung: undefinierter Verweis auf »readline«
collect2: error: ld returned 1 exit status
I tried several solutions provided on the internet, such as the following links but none of them worked:
How do I properly reference the GNU readline library to scan terminal input?
-L/usr/local/lib -I/usr/local/include
https://www.linuxquestions.org/questions/programming-9/undefined-reference-to-readline-494533/
#include "/usr/include/readline/readline.h"
does anyone have an idea?
(by the way, probably don't important: readline works on my Mac but not in my Ubuntu Virtual Machine)
gcc .... code.c .... -lreadline
From gcc link options:
-l library
-llibrary
...
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file foo.o but before bar.o. If bar.o refers to functions in ‘z’, those functions may not be loaded.

Call `atexit` when linking to libc dynamically on Linux

If I have the following program written in C (compiled with GCC on Debian 8.7), I am able to call atexit() as you would expect:
#include <stdlib.h>
void exit_handler(void) {
return;
}
int main () {
atexit(exit_handler);
return 0;
}
And when I compile and run it:
$ gcc test.c
$ ./a.out
Outputs nothing, just as you would expect. In fact, when I run ldd, I get:
$ ldd a.out
linux-vdso.so.1 (0x00007fffbe592000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe07d3a8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe07d753000)
However, libc does not seem to have any symbols for atexit, amd only has__cxa_atexit and __cxa_threaded_atexit_impl:
$ nm --dynamic /lib/x86_64-linux-gnu/libc.so.6 | grep 'atexit'
0000000000037d90 T __cxa_atexit
0000000000037fa0 T __cxa_thread_atexit_impl
As you would then expect, if I try to link to libc dynamically, I cannot actually call atexit(), such as in the following Racket program which links to libc and tries to find atexit:
#lang racket
(require ffi/unsafe)
(get-ffi-obj 'atexit (ffi-lib "libc" '("6")) (_fun (_fun -> _void) -> _int))
Giving the output:
$ racket findatexit.rkt
ffi-obj: couldn't get "atexit" from "libc.so.6" (/lib/x86_64-linux-gnu/libc.so.6: undefined symbol: atexit)
What I want to know here is:
If libc does not have any symbol for atexit on Linux, why can I still call it from a C program?
Is there any way I can call atexit or a similar function dynamically on Linux?
(I should note that atexit does appear to be a symbol on OS X, so its just Linux that seems unusual here.)
Edit:
At the suggestion of #Jonathan, I also ran:
$ gcc -c test.c
$ nm test.o
U atexit
0000000000000000 T exit_handler
0000000000000007 T main
Which seems to indicate the atexit symbol is there somewhere, but it does not appear in any of the libraries ldd is showing.
I did some poking around on a Centos 7 virtual machine, and I think I found it — but it was anything but obvious!
Found it!
In /usr/lib64/libc_nonshared.a:
$ nm /usr/lib64/libc_nonshared.a | grep -i atexit
atexit.oS:
0000000000000000 T atexit
U __cxa_atexit
$
Why look in that library? Good question — and a long story. Are you sitting comfortably? Then I'll begin…
Steps taken to get there
Use the test.c code from the question.
Compile it with gcc -v test.c:
$ gcc -v test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/cc1 -quiet -v test.c -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -o /tmp/ccPHTer7.s
GNU C (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-11) (x86_64-redhat-linux)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-11), GMP version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=124992
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
/usr/local/include
/usr/include
End of search list.
GNU C (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-11) (x86_64-redhat-linux)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-11), GMP version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=124992
Compiler executable checksum: 356f86e67978d665416e07d560c8ba0d
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/cc5WHEA4.o /tmp/ccPHTer7.s
GNU assembler version 2.25.1 (x86_64-redhat-linux) using BFD version version 2.25.1-22.base.el7
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/:/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.8.5/:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/collect2 --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. /tmp/cc5WHEA4.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o
$
The interesting part is the collect2 command line at the end. Written with one argument per line, that is:
/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/collect2
--build-id
--no-add-needed
--eh-frame-hdr
--hash-style=gnu
-m
elf_x86_64
-dynamic-linker
/lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.5
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64
-L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../..
/tmp/cc5WHEA4.o
-lgcc
--as-needed
-lgcc_s
--no-as-needed
-lc
-lgcc
--as-needed
-lgcc_s
--no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o
So, there are a bunch of cr*.o files, plus three libraries: -lc, -lgcc and -lgcc_s to look for, and a bunch of directories to look in:
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.5, -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64, -L/lib/../lib64, -L/usr/lib/../lib64, -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../... The /tmp/cc5WHEA4.o is the object file created from test.c.
Applying some clean-up code to the path names, and then using ls to help find the libraries yields a list of files to examine further:
/lib64/ld-linux-x86-64.so.2
/usr/lib64/crt1.o
/usr/lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbegin.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o
/usr/lib64/crtn.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.a
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so
/usr/lib64/libgcc_s.so.1
/lib64/libgcc_s.so.1
/usr/lib64/libgcc_s.so.1
/usr/lib64/libc.so
/usr/lib64/libc.so.6
/lib64/libc.so
/lib64/libc.so.6
/usr/lib64/libc.so
/usr/lib64/libc.so.6
That list of files was saved in a file yy (unimaginative name), and then used in:
$ nm -o $(<yy) | tee nm.log | grep -i atexit
nm: _trampoline.o: no symbols
nm: __main.o: no symbols
nm: _ctors.o: no symbols
nm: /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc_s.so: no symbols
nm: /usr/lib64/libgcc_s.so.1: no symbols
nm: /lib64/libgcc_s.so.1: no symbols
nm: /usr/lib64/libgcc_s.so.1: no symbols
nm: /usr/lib64/libc.so: File format not recognized
/usr/lib64/libc.so.6:00000000003bcc00 b added_atexit_handler.9157
/usr/lib64/libc.so.6:0000000000038c90 T __cxa_atexit
/usr/lib64/libc.so.6:0000000000038c90 t __cxa_atexit_internal
/usr/lib64/libc.so.6:00000000003b6838 d __elf_set___libc_atexit_element__IO_cleanup__
/usr/lib64/libc.so.6:0000000000038c40 t __internal_atexit
/usr/lib64/libc.so.6:00000000003b6838 d __start___libc_atexit
/usr/lib64/libc.so.6:00000000003b6840 d __stop___libc_atexit
nm: /lib64/libc.so: File format not recognized
/lib64/libc.so.6:00000000003bcc00 b added_atexit_handler.9157
/lib64/libc.so.6:0000000000038c90 T __cxa_atexit
/lib64/libc.so.6:0000000000038c90 t __cxa_atexit_internal
/lib64/libc.so.6:00000000003b6838 d __elf_set___libc_atexit_element__IO_cleanup__
/lib64/libc.so.6:0000000000038c40 t __internal_atexit
nm: /usr/lib64/libc.so: File format not recognized
/lib64/libc.so.6:00000000003b6838 d __start___libc_atexit
/lib64/libc.so.6:00000000003b6840 d __stop___libc_atexit
/usr/lib64/libc.so.6:00000000003bcc00 b added_atexit_handler.9157
/usr/lib64/libc.so.6:0000000000038c90 T __cxa_atexit
/usr/lib64/libc.so.6:0000000000038c90 t __cxa_atexit_internal
/usr/lib64/libc.so.6:00000000003b6838 d __elf_set___libc_atexit_element__IO_cleanup__
/usr/lib64/libc.so.6:0000000000038c40 t __internal_atexit
/usr/lib64/libc.so.6:00000000003b6838 d __start___libc_atexit
/usr/lib64/libc.so.6:00000000003b6840 d __stop___libc_atexit
$
There's no evidence of a plain atexit function there. Where's it hiding, and what's with those 'File format not recognized' messages?
$ file /usr/lib64/libc.so
/usr/lib64/libc.so: ASCII text
$
ASCII text? What?
$ cat /usr/lib64/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
$
OK; what's in /usr/lib64/libc_nonshared.a?
$ nm /usr/lib64/libc_nonshared.a | grep -i atexit
atexit.oS:
0000000000000000 T atexit
U __cxa_atexit
$
Bingo! Found it!
So, it seems that the collect2 linker used by GCC is able to load files not listed on the command line, and that one of those files is /usr/lib64/libc_nonshared.a, and that this library has atexit() in it. Consequently, you should be able to invoke atexit() because it is statically linked into the executable … unless there's some more black magic hidden away here that I've not sussed out.

Gradle Native Binary linker error: bad rpath option

I have a C++ library that is being cross-compiled by Gradle on a Mac for Windows, using mingw-w64. I get a "bad -rpath option" when the linker tries to link the binaries.
There are a complicated linker search paths in the debug output below that I have removed for clarity, but they are all ok. However, there is one part which seems to be wrong - it looks like something is being added to the search paths by mistake.
:linkWindows-x8664DebugTestSharedLibrary
Using built-in specs.
COLLECTGCC=/usr/local/bin/mingw-w64/mingw-w64-x8664/mingw/bin/g++
Target: x8664-w64-mingw32
Configured with: ../source/gcc-4.8.3/configure --build=x8664-apple-darwin13.2.0 --target=x8664-w64-mingw32 --disable-nls --disable-multilib --prefix=/usr/local/bin/mingw-w64/mingw-w64-x8664 --with-sysroot=/usr/local/bin/mingw-w64/mingw-w64-x8664 --with-mpc=/usr/local/bin/mingw-w64/pkgs/mpc/mpc-1.0.2-x8664 --with-mpfr=/usr/local/bin/mingw-w64/pkgs/mpfr/mpfr-3.1.2-x8664 --with-gmp=/usr/local/bin/mingw-w64/pkgs/gmp/gmp-6.0.0a-x8664 --with-host-libstdcxx='-lstdc++ ' --with-cloog=/usr/local/bin/mingw-w64/pkgs/cloog/cloog-0.18.0-x8664 --with-isl=/usr/local/bin/mingw-w64/pkgs/isl/isl-0.11.1-x8664 --enable-languages=c,c++ --enable-threads=win32 --enable-fully-dynamic-string --enable-lto
Thread model: win32
gcc version 4.8.3 (GCC)
COMPILERPATH=/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/bin/
LIBRARYPATH=/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/:/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/:/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/lib/../lib/:/usr/local/bin/mingw-w64/mingw-w64-x8664/mingw/lib/../lib/:/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/lib/:/usr/local/bin/mingw-w64/mingw-w64-x8664/mingw/lib/
COLLECTGCCOPTIONS='-shared' '-o' '/Users/john/git/test/build/binaries/testSharedLibrary/windows-x8664Debug/libtest.dylib' '-L/Users/john/git/test/build/nar-dependencies/compiletestWindows-x8664Debug/lib' '-v' '-fno-use-linker-plugin' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/bin/ld --sysroot=/usr/local/bin/mingw-w64/mingw-w64-x8664 -m i386pep --shared -Bdynamic -e DllMainCRTStartup --enable-auto-image-base -o /Users/john/git/test/build/binaries/testSharedLibrary/windows-x8664Debug/libtest.dylib /usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/lib/../lib/dllcrt2.o /usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/lib/../lib/crtbegin.o -LseriesOfSearchFoldersHereEachWithMinusLFlag **#/var/folders/75/fsklv28523d2gx1wth3rc7y0000101/T//ccOUlRAe** -lmingw32 -lgccs -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgccs -lgcc -lmoldname -lmingwex -lmsvcrt /usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/lib/../lib/crtend.o
Error message reads:
/usr/local/bin/mingw-w64/mingw-w64-x8664/x8664-w64-mingw32/bin/../lib/gcc/x8664-w64-mingw32/4.8.3/../../../../x8664-w64-mingw32/bin/ld: bad -rpath option
FAILED
This appears to be the offending bit that is causing the problem: #/var/folders/75/fsklv28523d2gx1wth3rc7y0000101/T//ccOUlRAe
What is that and why is it there?
Did you already solve it?
Most probably the paths to search for libraries is generated by Gradle Native as well. I have no clue about the directory structure. Which version of Gradle are you using? Did you read the user guide about native binaries? Are you able to share the gradle file? (As native support is incubating, it is likely to change quite a bit. It did for me, over the past versions)

Manually compile using gcc -v

Is it possible to compile a simple Hello World program that only uses provided gcc/glibc files rather than using the default ones provided by the OS ? (Therefore, when executed, the program will only use the provided files rather than the ones the OS provides.) I've looked everywhere on the net but cannot get any to work:
I tried to manually do what this does gcc -v simple.c but I cannot reproduce it myself.
This is what I tried: (all provided files are on the Desktop)
/home/myuser/Desktop/cc1 -quiet -v simple.c -quiet -dumpbase simple.c -mtune=generic -auxbase simple -version -o /tmp/temp1.s
How can the below paths be changed to custom ones rather than default ones ?
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C (Debian 4.4.5-8) version 4.4.5 (x86_64-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dac4d891d068d1bed01868869b00bd17
as -V -Qy -o /tmp/temp2.o /tmp/temp1.s
GNU assembler version 2.20.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.20.1-system.20100303
/home/myuser/Desktop/collect2 --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker ld-2.11.2.so crt1.o crti.o crtbegin.o /tmp/temp2.o libgcc.a --as-needed libgcc_s.so.1 --no-as-needed libc.a libgcc_s.so.1 --as-needed libgcc.a --no-as-needed crtend.o crtn.o
Why is the below /usr/bin/ld used instead of the provided ld-2.11.2.so ?
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
collect2: ld returned 1 exit status
Can anybody modify it to work ?
-v shows you the actions performed by the compiler driver. It does not affect what standard libraries you get.
To run with all custom libraries, use -nostdlib.
How can the below paths be changed to
custom ones rather than default ones ?
Simply add -I path to the compiler call. This path will be added before the internal paths.
Why is the below /usr/bin/ld used
instead of the provided ld-2.11.2.so ?
The first one is an executable binary, the second one is a shared object. You can't use a shared object in a place of a binary.

Resources