I want to compile nginx with CFI enforced by LLVM. I modify the Makefile in the objs directory. The modification includs:
1. change the compiler:cc--> clang
2. add parameters related with CFI: -flto -fvisibility=hidden -fsanitize=cfi
The modified Makefile is illusrated below
CC = clang
CFLAGS = -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -flto -fvisibility=hidden -fsanitize=cfi
CPP = cc -E
LINK = $(CC)
The compilation process is passed. However, there are some errors are reported during the link process:
/usr/bin/ld: unrecognized option '-plugin'
/usr/bin/ld: use the --help option for usage information
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
According to the document of clang 6.0.0, the CFI schemes relies on link-time optimization(LTO), and the linker used must support LTO (such as gold plugin).
There are some materials about LTO:
http://llvm.org/docs/GoldPlugin.html
I still do not know how to deal with this problem, Any one could give me some suggestion?
To help other freshman like me, I give more details:
Install the Gold linker(down load the binutils (>2.21.51.0.2) with ld.bfd).
Run CMake with -DLLVM_BINUTILS_INCDIR=/path/to/binutils/include (this path contain the file plugin-api.h), and make -j8. this step generate the LLVMgold.so.
For previous LLVM version, copy LLVMgold.so to /usr/local/lib. For the latest LLVM, we do not have to copy LLVMgold.so to /usr/local/lib. After make install, the file will be copy to the target directory (./install_dir/lib)
Related
I want to compile this C++ project to WASM using Emscripten. For this, I am following the documentation on building projects.
The project only has a Makefile, no Configure or CMake. It should be portable from what I can tell, and the project compiles fine using regular make, as described in the Readme.
Because there is no configure file, I skipped the emconfigure step. The documentation says that I have to edit the Makefile manually in that case, but I can't get it right.
Running emmake make works, and produces .o files in the bin directory, and an executable. This produces the same result as running make normally, from what I can tell. Both executables can be executed as normal (./zilch).
Running emcc bin\main.o is where I get issues though:
wasm-ld: error: unknown file type: bin/main.o
emcc: error: '/home/johannes/emsdk/upstream/bin/wasm-ld -o main.wasm bin/main.o -L/home/johannes/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -lGL -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --strip-debug --export-if-defined=main --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__main_argc_argv --export-if-defined=fflush --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_init --export=stackSave --export=stackRestore --export=stackAlloc --export=__wasm_call_ctors --export=__errno_location --export-table -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024' failed (returned 1)
Running file bin/main.o shows: bin/main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped. Running emmake clearly still compiled it to x86, not wasm.
In the flags.mk file that is imported into the Makefile, the CC variable is set to g++. Changing it to em++ gives this error:
em++: error: Passing any of -msse, -msse2, -msse3, -mssse3, -msse4.1, -msse4.2, -msse4, -mavx, -mfpu=neon flags also requires passing -msimd128 (or -mrelaxed-simd)!
But adding this to CFLAGS in flags.mk only throws another cryptic error message:
em++: error: '/home/johannes/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -fignore-exceptions -fvisibility=default -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -DEMSCRIPTEN -D__EMSCRIPTEN_major__=3 -D__EMSCRIPTEN_minor__=1 -D__EMSCRIPTEN_tiny__=18 -Werror=implicit-function-declaration -I/home/johannes/emsdk/upstream/emscripten/cache/sysroot/include/SDL --sysroot=/home/johannes/emsdk/upstream/emscripten/cache/sysroot -D__SSE__=1 -D__SSE2__=1 -D__SSE3__=1 -D__SSSE3__=1 -D__SSE4_1__=1 -D__SSE4_2__=1 -Xclang -iwithsysroot/include/compat -O3 -g3 -Wall -fmessage-length=0 -fopenmp -maes -mtune=native -mrelaxed-simd -std=c++11 -Isrc -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/framework/gadgetlib/gadgetlib/../. -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/libstark/src -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/algebra/algebralib/headers -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/algebra/FFT/src -I/mnt/c/Users/johan/source/repos/Zilch/Zilch/framework/zilch/src -c /mnt/c/Users/johan/source/repos/Zilch/Zilch/framework/zilch/main.cpp -o /mnt/c/Users/johan/source/repos/Zilch/Zilch/bin/main.o' failed (returned 1)
I also tried to replace every $(MAKE) with $(EMMAKE) in the Makefile without success.
I am aware that I probably have to convert the project to CMake, or include a Configure file, as the documentation says. But I can't figure out for the life of me how that should look. If it isn't obvious, I am not experienced with any of these tools, so please be kind if I'm missing something super obvious.
I recently installed LLVM v8.0.0 (on RHEL 7.4). I am going through the LLVM Kaleidoscope tutorial to learn how to use the system, but am running into an issue linking.
Per the tutorial (end of chapter 2), I run:
clang++ -g -O3 kld.cpp `llvm-config --cxxflags` -o kld
It compiles, but the linker fails on:
/tmp/kld-f7264f.o:(.data+0x0): undefined reference to `llvm::EnableABIBreakingChecks'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
I suspected this may have been an issue with llvm-config, so I also tried using the --ldflags and --system-libs flags, but no luck.
llvm-config --cxxflags gives (reformatted for readability)
-I~/project/llvm-src/include -I~/project/llvm-build/include
-fPIC -fvisibility-inlines-hidden
-std=c++11
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-g
-fno-exceptions -fno-rtti
-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
Where ~/... is just the path to my home directory (edited for privacy; the actual output is a fullpath). I am working on a shared system that requires I install new software locally.
The tutorial code never references ABI explicitly, so I assume this must be some kind of compiler-flags issue. greping for the missing symbol in non-binary files gives an extern declaration in include/llvm/Config/abi-breaking.h and the real declaration in lib/Support/Error.cpp:
#if LLVM_ENABLE_ABI_BREAKING_CHECKS
int EnableABIBreakingChecks;
#else
int DisableABIBreakingChecks;
#endif
I thought I would try re-compiling, then, with -DLLVM_ENABLE_ABI_BREAKING_CHECKS. That also does that work.
I'm not really clear what the ABI breaking checks are doing in the first place, and this may be way over my C++ comfort level. But how can I silence this error, if I don't need the referenced functionality; or fix it, if i do?
Thanks.
Turns out the answer was hidden in abi-breaking.h:
/* Allow selectively disabling link-time mismatch checking so that header-only
ADT content from LLVM can be used without linking libSupport. */
#if !LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING
I'm not sure if I'll need libSupport down the line, but compiling with LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 works for the time being.
Add linkage with LLVMSupport library will also solve this problem.
With this CMake snippet:
find_package(LLVM REQUIRED CONFIG)
message(STATUS "Found LLVM ${LLVM_PACKAGE_VERSION}")
message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}")
add_executable(main main.cpp)
target_link_libraries(main LLVMSupport)
Based on the discussion in llvm irc channel.
Try the following command to compile : clang++ -O3 -c $(llvm-config --cxxflags) source_file.cpp -o obj_code.
Then try linking with this command : clang++ obj_code $(llvm-config --ldflags --libs) -lpthread.
I think linking part doesn't mentioned in the kaleidoscope section. The above solution worked for me.
I don't know the influence and reason why it works. But when I add -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING, the errors disappear.
clang++ xxx -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING
ref:
https://www.coder.work/article/6278120
https://blog.csdn.net/qq_37887537/article/details/112790961
I am trying to use gdb to debug an hdf5 C++ application that I have written. The h5 package that I am using was installed using conda. The command that I am using is:
h5c++ hdf5.cpp
This generates an executable which I then run with gdb as follows:
gdb a.out
gdb launches alright. But when I add breakpoint using:
b 10
or any line number, it gives a message: No line 10 in file "init.c"
When I press run, it runs the whole program at once (which I don't want) and exits. The h5c++ -show command gives the following output:
x86_64-conda_cos6-linux-gnu-c++ -I/i3c/hpcl/sms821/software/tensorflow/anaconda2/include -D_FORTIFY_SOURCE=2 -O2 -g -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/i3c/hpcl/sms821/software/tensorflow/anaconda2/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_hl_cpp.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_cpp.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_hl.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5.a -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -g -lrt -lpthread -lz -ldl -lm -Wl,-rpath -Wl,/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib
I think this has to do with the compiler the compiler that it is using. I tried replacing x86_64-conda_cos6-linux-gnu-c++ with my native g++ compiler in the h5c++ script but that gives linker error.
Please suggest how should make my h5 application work with gdb. Should I install hdf5 from source since I don't have sudo access? I am working on a Linux machine.
I simply installed hdf5 from the source files. While configuring the installation I turned the --enable-build-mode and --enable-symbol switches. Hdf5 has a dependency on szip which I also installed from source code. My exact configuration was as follows:
./configure --prefix=<hdf5 install directory> --enable-cxx --enable-build-mode=debug --enable-symbols=yes --enable-profiling=yes --with-szlib=<szip install directory>
The above solution worked and I was able to compile my h5 application using h5c++ hdf5.cpp and also use gdb to debug it.
I'm trying to compile this source code from the makefile in a VPS, but its not working. The VPS is a 64 Cent OS
Here's the full error
# make
gcc -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c
g++ -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp
g++ -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp
g++ -O2 -fshort-wchar -shared -o "TCP_V1.so" *.o
/usr/bin/ld: TCP-LINUX_V1.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
TCP-LINUX_V1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [all] Error 1
Here's my makefile:
GPP=g++
GCC=gcc
OUTFILE="TCP_V1.so"
COMPILE_FLAGS=-c -O3 -w -DLINUX -I../SDK/amx/
all:
$(GCC) $(COMPILE_FLAGS) ../SDK/amx/*.c
$(GPP) $(COMPILE_FLAGS) ../SDK/*.cpp
$(GPP) $(COMPILE_FLAGS) *.cpp
$(GPP) -O2 -fshort-wchar -shared -o $(OUTFILE) *.o
Anyone know what's wrong?
Do what the compiler tells you to do, i.e. recompile with -fPIC. To learn what does this flag do and why you need it in this case, see Code Generation Options of the GCC manual.
In brief, the term position independent code (PIC) refers to the generated machine code which is memory address agnostic, i.e. does not make any assumptions about where it was loaded into RAM. Only position independent code is supposed to be included into shared objects (SO) as they should have an ability to dynamically change their location in RAM.
Finally, you can read about it on Wikipedia too.
In my case this error occurred because a make command was expecting to fetch shared libraries (*.so files) from a remote directory indicated by a LDFLAGS environment variable. In a mistake, only static libraries were available there (*.la or *.a files).
Hence, my problem did not reside with the program I was compiling but with the remote libraries it was trying to fetch.
So, I did not need to add any flag (say, -fPIC) to the compilation interrupted by the relocation error.
Rather, I recompiled the remote library so that the shared objects were available.
Basically, it's been a file-not-found error in disguise.
In my case I had to remove a misplaced --disable-shared switch in the configure invocation for the requisite program, since shared and static libraries were both built as default.
I noticed that most programs build both types of libraries at the same time, so mine is probably a corner case. In general, it may be the case that you rather have to enable shared libraries, depending on defaults.
To inspect your particular situation with compile switches and defaults, I would read out the summary that shows up with ./configure --help | less, typically in the section Optional Features. I often found that this reading is more reliable than installation guides that are not updated while dependency programs evolve.
Fixed it with -no-pie option in linker stage:
g++-8 -L"/home/pedro/workspace/project/lib" -no-pie ...
It is not always about the compilation flags, I have the same error on gentoo when using distcc.
The reason is that on distcc server is using a not-hardened profile and on client the profile is hardened. Check this discussion:
https://forums.gentoo.org/viewtopic-p-7463994.html
Simply cleaning the project solved it for me.
My project is a C++ application (not a shared library). I randomly got this error after a lot of successful builds.
I had the same problem. Try recompiling using -fPIC flag.
I'm getting the same solution as #camino's comment on https://stackoverflow.com/a/19365454/10593190 and XavierStuvw's reply.
I got it to work (for installing ffmpeg) by simply reinstalling the whole thing from the beginning with all instances of $ ./configure replaced by $ ./configure --enable-shared (first make sure to delete all the folders and files including the .so files from the previous attempt).
Apparently this works because https://stackoverflow.com/a/13812368/10593190.
We had the same problem. It turned out to be a mix-up in a Makefile. The error occurred when the linker was gcc, but the C++ compiler clang++. Changing the linker to clang++ fixed it.
I have two Executable generated with different gcc version
One is using gcc 3.4.2 and other using gcc 4.3.2 in my Linux box
Both has to be run in same environment i.e. having same LD_LIBRARY_PATH.
Currently path of 4.3.2 is placed before the 3.4.2 the 3.4.2 is giving error.
libstdc++.so.6: version 'GLIBCXX_3.4.9' not found (required by../../src/hello)
I am thinking about the solution where I can store the information in the exe where to find the
loadtime files needed.
I created below build scripts which are giving problem:
Basically O3 option is doing optimization.
/opt/gcc-4.3.2/bin/g++ -pipe -O3 -c hello4_3_2.cpp
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -L$/opt/gcc-4.3.2/lib64/libstdc++
/opt/gcc-3.4.2/bin/g++ -pipe -O3 -c hello3_4_2.cpp
/opt/gcc-3.4.2/bin/g++ -o hello3_4_2 hello3_4_2.o -L$/opt/gcc-3.4.2/lib64/libstdc++
Below script works for me:(With out O3 option)
/opt/gcc-4.3.2/bin/g++ -pipe -c hello4_3_2.cpp
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -L$/opt/gcc-4.3.2/lib64/libstdc++
/opt/gcc-3.4.2/bin/g++ -pipe -c hello3_4_2.cpp
/opt/gcc-3.4.2/bin/g++ -o hello3_4_2 hello3_4_2.o -L$/opt/gcc-3.4.2/lib64/libstdc++
Now:
I wanted to know if there is any other way to achieve it.
Is there is any draw back of doing in this way.
Specify an rpath when linking:
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -Wl,-rpath,/opt/gcc-4.3.2/lib64
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This will hardcode a library search path into the executable.
You can use ldd ./hello4_3_2 to check without running whether the correct libraries are being found.
The libstdc++ manual lists several options