* Fedora 24, x86_64 * thinlinc-tlmisc-4.7.0post-5309.r31926.x86_64 > $ cd tl-4.7.0post-server/sources > $ tar -xzf tlstunnel-linkkit-x86_64.tar.gz > $ cd tlstunnel-linkkit > $ make > gcc -o tlstunnel tlstunnel.o libgnutls.a libhogweed.a libnettle.a libgmp.a libtasn1.a -lz -lrt > libgnutls.a(secure_getenv.o): In function `secure_getenv': > /home/hean01/Development/cenbuild/repo/rpmbuild/BUILD/gnutls-3.5.6/gl/secure_getenv.c:39: undefined reference to `__secure_getenv' > collect2: error: ld returned 1 exit status > Makefile:4: recipe for target 'tlstunnel' failed > make: *** [tlstunnel] Error 1 https://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv has a few notes about secure_getenv vs __secure_getenv.
See bug 3513 for client linkkit problems
(In reply to Karl Mikaelsson from comment #0) > > https://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv has a few > notes about secure_getenv vs __secure_getenv. TL;DR; Things built with glibc < 2.17 cannot be linked with glibc >= 2.17. They have fixes in place for already linked binaries, but not when trying a new link. This is probably not something we can fix in the link kit, but we can continue to track the issue here until we've upgraded our glibc to 2.17 or newer.
Also note that this is an issue with the included gnutls, not our proprietary objects files. One option could be to not include the open source components and grabbing those from the user's system instead. That is how we do it for the client.
