I would like to compile my program linking to acml. In cygwin (win64) with gfortran linking to acml:
$ gfortran empty.f90 -L/c:/cygwin64/acml5.3.1/win64/lib/libacml_dll.lib
yields
/tmp/ccKechZN.o:empty.f90:(.text+0xff): undefined reference to `drandinitialize_'
/tmp/ccKechZN.o:empty.f90:(.text+0xff): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `drandinitialize_'
/tmp/ccKechZN.o:empty.f90:(.text+0x13b): undefined reference to `drandgaussian_'
/tmp/ccKechZN.o:empty.f90:(.text+0x13b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `drandgaussian_'
collect2: error: ld returned 1 exit status
I tried a few other things with the help of the documentation, but nothing has successfully allowed the compiler to link with acml. I also tried to link to the library by adding -l acml_dll and received the following error:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lacml_dll
collect2: error: ld returned 1 exit status
I have verified that the .lib exists in the directory specified. Perhaps a related problem, I am also trying to execute the output from ifort linked to acml on win64. I am using "Intel 64 Visual Studio 2013 mode" command prompt to compile an example program that calls subroutines from acml (see documentation for linking in win64):
ifort /libs:dll empty.f90 c:/AMD/acml5.3.1/ifort64_int64/lib/libacml__dll.lib
which yields
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.5.239 Build 20150212
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
Microsoft (R) Incremental Linker Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
-out:empty.exe
-subsystem:console
empty.obj
At least with ifort the program compiles successfully. Then when I execute empty.exe I get the following error:
The program can't start because libacml_dll.dll is missing from your computer. Try reinstalling the program to fix this problem.
I tried reinstalling acml 5.3.1 as well as trying acml 6.1.0, but encountered the same error upon execution.
Just specifying the library path alone is not sufficient. You have to tell the compiler to link against the library as well. Simply add -l acml_dll to the compile options.
Additionally, specifying the library path with -L expects a path, not a file. So the complete command should look like
gfortran empty.f90 -L/c:/cygwin64/acml5.3.1/win64/lib/ -lacml_dll
When you run the program, the library needs to be found at runtime as well. The easiest way to achieve this is to use rpath:
gfortran empty.f90 -L/c:/cygwin64/acml5.3.1/win64/lib/ -lacml_dll \
-Wl,-rpath=/c:/cygwin64/acml5.3.1/win64/lib/
Related
I'm trying to compile with a sysroot for Ubuntu 22.04 from a Ubuntu 20.04 image, and I'm having quite a bit of trouble, getting linker errors like these:
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_audit_symbind_alt#GLIBC_PRIVATE'
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_audit_preinit#GLIBC_PRIVATE'
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_fatal_printf#GLIBC_PRIVATE'
/usr/bin/ld: ../build_rootfs/x86_64_jammy/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `__nptl_change_stack_perm#GLIBC_PRIVATE'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The exact same invocation works fine from a Ubuntu 22.04, using the exact same compiler and exact same sysroot.
Here's my setup:
// test.cpp
int main(){}
Compile command:
clang++ --sysroot ../build_rootfs/x86_64_jammy test.cpp
Where ../build_rootfs/x86_64_jammy is a sysroot created with multistrap (I can share a minimized multistrap config if it's relevant, but considering the same sysroot works fine from Ubuntu 22.04, the sysroot seems to not be the issue.
Things I have tried:
Using lld--same result
Using clang 14, both from apt.llvm.org and from the binary tarball
Notably, GCC is able to compile it by passing -L/usr/lib/x86_64-linux-gnu/9 -L/usr/lib/x86_64-linux-gnu (yes, even when compiling with --sysroot), but this seems strange as this is linking to libraries on the host system. Adding these flags does let the compilation succeed, but compiling from clang on 22.04 works fine without loading any of the system libraries (allegedly).
I assume this is an issue with glibc verisons, but I can't see how the host glibc version would matter when compiling from a sysroot, and it doesn't seem like any of the linker inputs are actually from the host system, so what's going wrong?
This gist has the verbose logs from clang on focal, gcc on focal, and clang on jammy for reference.
I'm newbee with minGW. I'm trying to compile omniORB 4.2.3 with minGW in order to link the libraries with my applications developed on Dev-CPP 5.11 . I use the same toolchain for both. The gcc version is 4.9.2 (tdm64-1).
I googled everywhere as possible and found the linker option -municode. But the error persists. I tried the wrapper solution too.
Here is the lines of the error :
+ gcc -oomnicpp.exe -mthreads -Wl,--enable-runtime-pseudo-reloc -municode -L../../../../../lib/x86_win32 cexp.o cccp.o config.o alloca.o index.o
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_w.o): In function `wmain':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/crt0_w.c:23: undefined reference to `wWinMain'
collect2.exe: error: ld returned 1 exit status
Thanks for help.
I wish to setup Affectiva SDK 4.0.0 for Linux and hence, have started working on example apps from https://github.com/Affectiva/cpp-sdk-samples
I have Ubunutu 16.04, OpenCV 2.4.11, Boost 1.63, cmake 3.8.1, pre-installed gcc 5.5.0 and manually installed gcc 5.4.0 (because I could not find a proper setup for gcc 5.4.1 as required).
When I try to run below command to compile the code from video-demo folder:
g++ video_analyse.cpp -o video_analyse -std=c++11 -I$HOME/affdex-sdk/include -L$HOME/affdex-sdk/lib -I$HOME/sdk-samples/common -l affdex-native -l boost_program_options `pkg-config opencv --cflags --libs`
The error points to below line of code:
shared_ptr<PlottingImageListener> listenPtr(new PlottingImageListener(csvFileStream, draw_display));
And receive error:
/tmp/ccWtKCG0.o: In function `PlottingImageListener::PlottingImageListener(std::basic_ofstream<char, std::char_traits<char> >&, bool)':
video_analyse.cpp:(.text._ZN21PlottingImageListenerC2ERSt14basic_ofstreamIcSt11char_traitsIcEEb[_ZN21PlottingImageListenerC5ERSt14basic_ofstreamIcSt11char_traitsIcEEb]+0x148): undefined reference to `Visualizer::Visualizer()'
collect2: error: ld returned 1 exit status
The exact same error is received with gcc 5.5.0 as well.
If I comment everything starting from that line of code, then the compilation happens successfully.
Please guide me on this. Either on how to install the exact version of gcc 5.4.1 as expected by the SDK dependency OR anything which I might be missing.
I wrote an application on Windows using CPP and BASS, and now I have to get it running on Linux (UBUNTU).
I am using gcc version 4.5.2.
I have bass.lib in my directory from which I try to compile prog.cpp using the following command arguments:
gcc prog.cpp -L. -lbass.lib
But I get the following error:
/usr/bin/ld: cannot find -lbass.lib
collect2: ld returned 1 exit status
I figure that this is a linking error, the compiler is not finding Bass.lib but I have specified as an argument on the command line.
Not sure what to do, any help would be really great.
bass.lib sounds like the windows library. You cannot use libraries generated on windows, (likely generated with the MSVC compiler), on linux.
The linux version of the library seems to be named libbass.so , in which case you'd use -lbass as the linker argument , and possibly other compiler/linker flags as well depending on where on the system you install the library. The bass.txt in the linux download of libbass have a few notes on what to do on Linux.
I am trying to compile a linear system solver using PARDISO.
The test case (pardiso_sym.c) also downloaded from the same website above.
I have the following files inside the directory:
[gv#emerald my-pardiso]$ ls -lh
total 1.3M
-rw-r--r-- 1 gv hgc0746 1.3M Aug 7 11:59 libpardiso_GNU_IA64.so
-rw-r--r-- 1 gv hgc0746 7.2K Nov 13 2007 pardiso_sym.c
Then I try to compile it with the following command:
[gv#emerald my-pardiso]$ gcc pardiso_sym.c -o pardiso_sym -L . -llibpardiso_GNU_IA64.so -L/home/gv/.boost/include/boost-1_38 -llapack
But it gives this error:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/ld:
cannot find -llibpardiso_GNU_IA64.so
collect2: ld returned 1 exit status
What's wrong with my compilation method?
This is the additional info of my system:
[gv#emerald my-pardiso]$ uname -a
Linux gw05 2.6.18-92.1.13.el5 #1 SMP Wed Sep 24 19:32:05 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux
[gv#emerald my-pardiso]$ gcc --version
gcc (GCC) 4.3.2
Update:
The library is recognized using Dave Gamble's suggestion. But now it gives different
error:
$ gcc pardiso_sym.c -o pardiso_sym -L . -lpardiso_GNU_IA64 -L/home/gv/.boost/include/boost-1_38 -llapack
./libpardiso_GNU_IA64.so: undefined reference to `s_stop'
./libpardiso_GNU_IA64.so: undefined reference to `s_wsfe'
./libpardiso_GNU_IA64.so: undefined reference to `e_wsfe'
./libpardiso_GNU_IA64.so: undefined reference to `z_abs'
./libpardiso_GNU_IA64.so: undefined reference to `s_cat'
./libpardiso_GNU_IA64.so: undefined reference to `s_copy'
./libpardiso_GNU_IA64.so: undefined reference to `do_fio'
EDIT: I read the pardiso manual. Here's the fix:
gcc pardiso_sym.c -o pardiso_sym -L . -lpardiso_GNU_IA64 -L/home/gv/.boost/include/boost-1_38 -llapack
Here I've removed the "lib" from the start and the ".so" from the end of -lpardiso_GNU_IA64
EDIT:
For new errors you'll need -lg2c after -lapack (fortran compatibility library)
EDIT2:
Also add -lgfortran and anything else you might need. Googling for a missing symbol usually finds mentions of library it contains. Keep adding libraries one by one untill all dependencies are satisfied.
So in your case routine is like this:
linked lapack -- got unresolved symbol from g2c
added g2c -- got symbols from gfortran
added gfortran -- got some other symbols, look them up and add libs one by one.
Libray order matters, if you include g2c before lapak for example, linker will throw away all its symbols before it knows they are needed for lapak (MS linker does 2 passes to fix that). So if you see a missing symbol that is in a lib you already include, look at which library needs it and move the lib with the symbol to be after it.