build static linked clang with gcc 4.8.3 on centos - gcc

I'm trying to build a static linked executable clang on centos 6. I'm using gcc4.8.3 compiled from source.
If I compile with cmake option -DLLVM_BUILD_STATIC=ON, the error is:
CMake Error at cmake/modules/CheckAtomic.cmake:52 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:307 (include)
CMakeLists.txt:590 (include)
If I add -static flag to CMAKE_EXE_LINKER_FLAGS directly, the error is:
ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in
`/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making
an executable; recompile with -fPIE and relink with -pie
If I add -fPIE to CMAKE_CXX_FLAGS, and -Wl,-pie to CMAKE_EXE_LINKER_FLAGS directly, the error is:
CMake Error at cmake/modules/CheckAtomic.cmake:52 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:307 (include)
CMakeLists.txt:590 (include)
Checking the error message in llvm_build/CMakeFiles/CMakeError.log, I found cmake use the following code the check atomic.
#include <atomic>
std::atomic<float> x(0.0f);
int main() { return (float)x; }
The command to compile this code is:
/home/hailin/gcc-4.8.3-boost-1.55/rtf/bin/g++ -std=c++11 -fPIC -fPIE -Wl,-pie -DHAVE_CXX_ATOMICS_WITH_LIB -std=c++11 main.cpp
/home/hailin/gcc-4.8.3-boost-1.55/rtf/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../../../x86_64-unknown-linux-gnu/bin/ld: /usr/lib/../lib64/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC
/usr/lib/../lib64/crt1.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
If I remove the flag -Wl,-pie, the error will gone.

Related

compilation error when installing Monero, unable to recognise boost version

I am trying to install Monero on Ubuntu 16.04 however I get an error on make. libboost-all-dev (>=1.58) however the current version is 1.58, can anyone explain why this is happening
-- Using C security hardening flags: -Wformat -Wformat-security -fstack-protector -fstack-protector-strong -mmitigate-rop
-- Using C++ security hardening flags: -Wformat -Wformat-security -fstack-protector -fstack-protector-strong -mmitigate-rop
-- Using linker security hardening flags: -pie -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
CMake Error at /usr/share/cmake-3.5/Modules/FindBoost.cmake:1677 (message):
Unable to find the requested Boost libraries.
Boost version: 1.55.0
Boost include path: /usr/local/include
Detected version of Boost is too old. Requested version was 1.58 (or
newer).
Call Stack (most recent call first):
CMakeLists.txt:929 (find_package)
CMake Error at CMakeLists.txt:105 (message):
Could not find Boost libraries, please make sure you have installed
Boost or libboost-all-dev (>=1.58) or the equivalent
Call Stack (most recent call first):
CMakeLists.txt:933 (die)
-- Configuring incomplete, errors occurred!
See also "/home/azureuser/monero/build/Linux/master/release/CMakeFiles/CMakeOutput.log".
See also "/home/azureuser/monero/build/Linux/master/release/CMakeFiles/CMakeError.log".
Makefile:102: recipe for target 'release-all' failed
make: *** [release-all] Error 1

gcc: confused about -static -shared -fPIE -fPIC -Wl,-pie

I'm trying to build clang, with all library static linked in. So that I can run it on CentOS 6 with ancient GCC 4.4 version.
At first, I think adding the option -static by turning on LLVM_BUILD_STATIC is enough. But in the link stage, it errors out.
dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
So, I add -fPIE -Wl,-pie to CMAKE_CXX_FLAGS, and it says
-- Performing Test HAVE_CXX_ATOMICS_WITH_LIB
-- Performing Test HAVE_CXX_ATOMICS_WITH_LIB - Failed
CMake Error at cmake/modules/CheckAtomic.cmake:49 (message):
Host compiler must support std::atomic!
Call Stack (most recent call first):
cmake/config-ix.cmake:307 (include)
CMakeLists.txt:590 (include)
I checked the cmake/modules/CheckAtomic.cmake file, It compiles the following code
#include <atomic>
std::atomic<float> x(0.0f);
int main() { return (float)x; }
with command
/home/hailin/gcc-4.8.3-boost-1.55/rtf/bin/g++ -fPIE -Wl,-pie -DHAVE_CXX_ATOMICS_WITHOUT_LIB -std=c++11 -static -lm
/home/hailin/gcc-4.8.3-boost-1.55/rtf/bin/g++ -fPIE -Wl,-pie -DHAVE_CXX_ATOMICS_WITH_LIB -std=c++11 -static -lm -latomic
The command with option -Wl,-pie reproduce the same error.
It seems like a dead end. Is there any conflict between -shared and -fPIE -Wl,-pie ?
Old question, but in case someone else hits it: apparently you need to pass -pie to the compiler driver (gcc/g++), not just the linker (-Wl,-pie). Some startup object files differ for PIE (e.g. Scrt1.o instead of crt1.o) and these are passed by the driver to the linker, so the driver needs to know that you're making a PIE.

Error in linking while creating a shared library of AES C file [duplicate]

This question already has answers here:
Linking OpenSSL libraries to a program
(4 answers)
Closed 5 years ago.
Encountering error while creating a shared library of AES. The following commands are used :
gcc -Wall Test1.c x64/libSESDAPI.a -fPIC -lssl -lcrypto
gcc -shared -o libfile.so a.out -nostartfiles
And I am getting the following errors:
/usr/bin/ld: error in a.out(.eh_frame); no .eh_frame_hdr table will be created.
/usr/bin/ld: libfile.so: No symbol version section for versioned symbol `AES_cbc_encrypt##OPENSSL_1.0.0'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
I am new to shared libraries so please help.
Edit: I have edited and added the lcrypto and lssl
Edit2: By adding a -c in the first command, the above errors are now resolved. But now accessing the .so file with python gives a new error
OSError: ./libfile.so: undefined symbol: SDSCListDevs
Please tell why this error is coming.
You should be creating your shared library from an object file, not from an executable program.
You also need to link with the SSL libraries.
Commands to use:
# Compile the source file, generate object file
gcc -Wall Test1.c -c -fPIC
# Link object file with libraries to create the shared object
gcc -shared -fPIC -o libfile.so Test1.o x64/libSESDAPI.a -lssl -lcrypto

how can I fix ld not ignoring bad system libraries in favor of my local libraries?

I'm trying to build the newest gcc on my redhat box. I've downloaded and built the latest gmp, mpfr and mpc, per requirements and installed them in my local libraries. From the config.log file I have the following given below. Clearly the system version of mpfr is broken, and I want the configure to ignore it. I have set LIBRARY_PATH and LD_LIBRARY_PATH to point to my local installation /u/victor/lib. Since I'm running a configure script, it's not reasonable for me to try to change command line options for gcc. How do I fix this?
gcc -o conftest -g -O2 conftest.c -L/u/victor/lib -L/u/victor/lib -L/u/victor/lib -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: warning: libmpfr.so.1, needed by /u/victor/lib/libmpc.so, may conflict with libmpfr.so.4
/usr/bin/ld: __gmpfr_cache_const_euler: TLS definition in /u/victor/lib/libmpfr.so section .tdata mismatches non-TLS definition in /usr/lib64/libmpfr.so.1 section .data
What's even more confusing, is that when I compile conftest.c and then
gcc -o conftest conftest.o -lmpc -lmpfr -lgmp
with export LD_LIBRARY_PATH=/u/victor/lib it gives the errors below. I've check libmfpr.so with nm and the three "undefined" symbols are there.
/u/victor/lib/libmpc.so: undefined reference to `mpfr_min_prec'
/u/victor/lib/libmpc.so: undefined reference to `mpfr_set_zero'
/u/victor/lib/libmpc.so: undefined reference to `mpfr_get_z_2exp'

linker --as-needed flag not pruning libraries

I'm running into an issue after upgrading gcc from 4.1.1 to 4.7.2. The problem is that the ld --as-needed flag is not pruning libraries that are not required if enough libraries with inter dependencies are listed.
For example, if I build a simple program that doesn't need any special libraries, but includes them on the build line, as such
gcc -m32 test.c -Wl,--as-needed -L/usr/local/lib -lrt -lprojcommon -lproj -lrte -o test
then it builds fine and the --as-needed flag does it's job pruning out all of the listed libs that are not needed.
ldd test
linux-gate.so.1 => (0x00bfc000)
libc.so.6 => /lib/libc.so.6 (0x001ac000)
/lib/ld-linux.so.2 (0x0018a000
However, if I add one more library (in this case crypto), then the build fails with undefined reference errors.
gcc -m32 test.c -Wl,--as-needed -L/usr/local/lib -lcrypto -lrt -lprojcommon -lproj -lrte -o test
/usr/local/lib/librte.so: error: undefined reference to 'tla_decap_data'
/usr/local/lib/librte.so: error: undefined reference to 'do_db'
collect2: error: ld returned 1 exit status
This exact same build worked with 4.1.1, but started failing with 4.7.2.
This is part of a general build infra and libraries included on the build line are generic and expected to be pruned via --as-needed. I could fix this with --allow-shlib-undefined, but I'd prefer to find real unresolved symbols at build time. If I do set --allow-shlib-undefined, then I end up with the same set of required libs as the build that worked.
Any insight would be appreciated.

Resources