I used to compile a code with ifort and the following options:
-openmp -O2 -i-static -i8 -g -mkl -p -132
I want to compile with gfortran now, but the options are different. I know that -openmp equivalent is -fopenmp, but if someone could help me with the rest that would be greatly appreciated.
-mkl option will be recognized by Intel Fortan compiler only.
In the case of gnu fortran, to link with Intel MKL, please check how to do that with MKL linker Adviser follow the link: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor
e.x – static linking: -L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_gf_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl
Related
I did not get response from Qualcomm forum so I decided to post here. When I was trying to run examples of Halide for Hexagon by running make run as written in the document. Then I got the following issue. The -lc++abi is missing.
clang++ -std=c++11 -I /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/include -stdlib=libc++ -O3 -g -fno-rtti -rdynamic conv3x3_generator.cpp /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/lib/libHalide.a /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/tools/GenGen.cpp -o /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/Examples/build/offload/hexagon_benchmarks/bin/conv3x3.generator -lz -lrt -ldl -lpthread -lm
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked the /usr/lib and find. So it should be there?
./x86_64-linux-gnu/libc++abi.so.1.0
./x86_64-linux-gnu/libc++abi.so.1
./llvm-10/lib/libc++abi.so.1.0
./llvm-10/lib/libc++abi.so.1
Did I miss anything or make anything stupid? Thanks!
ld is your system's host linker -- that's GNU BFD ld. clang++ must be in your PATH but it's the host clang++ and not the hexagon-clang++ that would be with Halide/Hexagon tools.
I contacted the person from Qualcomm. I am not supposed to use either /usr/bin/clang++ nor hexagon-clang++. I downloaded clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz from https://releases.llvm.org/7.0.1/. You should use clang++ under the bin folder after you extract it. Now it works for me.
I facing some trouble compiling my programming assignment on my local machine. The program is distribute to us with makefiles and compilation commands that are known to work on the school's Scientific Linux servers. My local machine is Mac OS X El Capitan.
When I compile my program running make on my Mac, I get the following error that prevents compilation from proceeding:
myid-MacBook-Pro:mp6 myid$ make
gcc -g -lm -std=c99 -Wall -Werror -c lodepng.c
clang: error: -lm: 'linker' input unused
make: *** [lodepng.o] Error 1
But when I push that very same code as work in progress to the Linux servers and compile there, everything works fine. The linux servers use gcc and not clang:
[netid#linux-a2 mp6]$ make
gcc -g -lm -std=c99 -Wall -Werror -c functions.c
gcc -g -lm -std=c99 -Wall -Werror main.o lodepng.o imageData.o functions.o -o mp6 -lm
gcc -g -lm -std=c99 -Wall -Werror -c test.c
gcc -g -lm -std=c99 -Wall -Werror test.o lodepng.o imageData.o functions.o solution.o -o test -lm
In the makefile, these are the variable definitions:
CC=gcc
CFLAGS=-g -lm -std=c99 -Wall -Werror
and the target definition for loadpng.o
lodepng.o: lodepng.c
$(CC) $(CFLAGS) -c lodepng.c
I would appreciate any help on understanding this error and overcoming it.
Thank you very much.
Also, on this note, I thought I would say that I've noticed a subtle difference between Clang and GCC. It seems to me that even warnings generated by Clang would prevent the compilation to proceed so the warnings behaves like errors. But for GCC, if it generates warnings, it still compiles the object file. Please correct me if I'm mistaken.
Right now you're getting a compilation error on your Mac because you're trying to pass linker commands (i.e. -lm) into a compilation(i.e. -c). Do not give link flags when you compile (-c flag) your source files.
In the other compilation snippet you provided, the unused linker command seems to pass by unnoticed which isn't a good thing.
For your last question, the flag -Werror should force all compilation warnings to become errors -- which is exactly what you are describing.
I am try to do a QT opensource cross compiling, using standard arm-linux-gnueabi tool set which is installed via Ubuntu apt-get, but get these errors, and I have stuck here for 1 week:
arm-linux-gnueabi-ld -Wl,--gc-sections -Wl,-O1 -fuse-ld=gold -Wl,--enable-new-dtags -o ../../../bin/rcc .obj/rcc.o .obj/main.o -L/home/charlie/qt-everywhere-opensource-src-5.5.0/qtbase/lib -lQt5Bootstrap -lpthread
arm-linux-gnueabi-ld: unrecognized option '-Wl,--gc-sections'
arm-linux-gnueabi-ld: use the --help option for usage information
Makefile:194: recipe for target '../../../bin/rcc' failed
Is there anything wrong in the configure or tool set?
Thanks
The -Wl is used to pass options to linker from gcc. So your usage should be either
arm-linux-gnueabi-ld --gc-sections
or
arm-linux-gnueabi-gcc -Wl,--gc-sections
I'm trying to load a library to Firefox, and I get the following error in the terminal:
http://pastebin.com/ZLryd20D,
gcc -Wall -fPIC -c 11.cpp ,
gcc -shared -o libshared.so 11.o -ldl ,
LD_PRELOAD=$PWD/libshared.so firefox ,
/bin/sh: symbol lookup error: /home/enigma/Desktop/compilacionproceso/libshared.so: undefined symbol: __gxx_personality_v0
gcc -shared -o libshared.so 11.o -ldl -lstdc++
That's the wrong solution, that happens to work on Linux by accident.
The correct command line to build your shared library is:
g++ -shared -o libshared.so 11.o
(contrary to popular belief, gcc and g++ are not the same thing).
Answer from the OP himself, taken from a revision of the question:
I solved the problem adding a flag -lstdc++ for create the library
thanks to this post
What is __gxx_personality_v0 for?
cd /directory
gcc -Wall -fPIC -c 11.cpp
gcc -shared -o libshared.so 11.o -ldl -lstdc++
LD_PRELOAD=$PWD/libshared.so program
I'm trying to use std.net.curl on 32-bit Ubuntu Linux (11.10 Ocelot) using DMD 2.058.
When I build (dmd source.d) I get:
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/libphobos2.a(curl.o): In function `_D3std3net4curl4Curl19_sharedStaticCtor30FZv':
std/net/curl.d:(.text._D3std3net4curl4Curl19_sharedStaticCtor30FZv+0x6): undefined reference to `curl_global_init'
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/libphobos2.a(curl.o): In function `_D3std3net4curl4Curl19_sharedStaticDtor31FZv':
std/net/curl.d:(.text._D3std3net4curl4Curl19_sharedStaticDtor31FZv+0x4): undefined reference to `curl_global_cleanup'
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/libphobos2.a(curl_12fd_140.o): In function `_D3std3net4curl4HTTP4Impl6__dtorMFZv':
std/net/curl.d:(.text._D3std3net4curl4HTTP4Impl6__dtorMFZv+0x12): undefined reference to `curl_slist_free_all'
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/libphobos2.a(curl_12fd_140.o): In function `_D3std3net4curl4HTTP3dupMFZS3std3net4curl4HTTP':
std/net/curl.d:(.text._D3std3net4curl4HTTP3dupMFZS3std3net4curl4HTTP+0x53): undefined reference to `curl_slist_append'
[snip]
I added -L-lcurl to my command line (full command: dmd source.d -L-lcurl) but I get the exact same result. I have libcurl4-openssl installed. I can build a simple C curl program on this computer without issue (gcc simple.c -lcurl). I'm not sure where to look from here to figure this out.
Update: Here is how the linker is invoked according to dmd -v:
gcc source.o -o source -m32 -lcurl -Xlinker -L/usr/lib -Xlinker -L/usr/lib64 -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic -lphobos2 -lpthread -lm -lrt
As you yourself discovered, the order of libraries is incorrect. A quote from "An Introduction to GCC": "A library which calls an external function defined in another library should appear before the library containing the function." In your case libphobos calls external library's (libcurl) function(s), so I guess libphobos should go before libcurl.
The book is available online. Chapter related to the OT is here: http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
The DMD compiler is clearly broken in this respect. I published a patch to fix it (maybe not the best) but the maintainer of the compiler is not convinced this needs to be fixed at all so there is no much discussion about it.
https://github.com/D-Programming-Language/dmd/pull/497
http://d.puremagic.com/issues/show_bug.cgi?id=7044
Seemingly the simplest way to fix the phobos2/curl linker order problem, as mentioned elsewhere in this thread:
dmd source.d -L-lphobos2 -L-lcurl
Works like a charm for me.
I figured out if I obtain the linker command through -v and reorder it so the -lcurl is at the end it links without issue.
gcc source.o -o source -m32 -Xlinker -L/usr/lib -Xlinker -L/usr/lib64 -Xlinker --no-warn-search-mismatch -Xlinker --export-dynamic -lphobos2 -lpthread -lm -lrt -lcurl
I'm still curious if there is a way to fix this without manually running the linker.