I'm doing some experiments on linux kernel, I add two global variables in init/main.c shown below.
#define CODE_COUNT 1100
unsigned code_counter[ASM_CODE_COUNT];
unsigned code_counter_overflow[ASM_CODE_COUNT];
EXPORT_SYMBOL(code_counter);
EXPORT_SYMBOL(code_counter_overflow);
After this I want to use them in other files, but I got the following error:
ld: arch/x86/entry/vdso/vgetcpu.o: in function `vdso_read_cpunode':
linux-5.17.2/./arch/x86/include/asm/segment.h:255: undefined reference to `code_counter'
ld:linux-5.17.2/./arch/x86/include/asm/segment.h:255: undefined reference to `code_counter_overflow'
objdump: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
ld: arch/x86/entry/vdso/vgetcpu-x32.o: relocation R_X86_64_PC32 against undefined symbol `code_counter' can not be used when making a shared object; recompile with -fPIC
ld: final link failed: bad value
I add extern unsigned code_counter[] extern unsigned code_counter_overflow[] to these files.
Related
I'm building a static library for a small project, and when I compile it with ar, it correctly links.
When I go to include the relevant header file and link the test script to the archive;
LINK = -lpthread -lcryptopp -L./path/to/archive/ -luttu
r: ../inc/uttu.hpp
g++ -std=c++20 rnet.cpp -o r.out $(LINK)
I get linker errors;
/usr/bin/ld: /tmp/cc7h6RHu.o: in function `main':
rnet.cpp:(.text+0x263): undefined reference to `np::np()'
/usr/bin/ld: rnet.cpp:(.text+0x317): undefined reference to `np::np()'
/usr/bin/ld: ./../exe//libuttu.a(peer.o): in function `Peer::Connect(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)':
/home/uton/code/Concord/uttu/src/peer.cpp:43: undefined reference to `void np::target<np::_tf>(np::_tf)'
/usr/bin/ld: ./../exe//libuttu.a(relay.o): in function `Relay::Foward()':
/home/uton/code/Concord/uttu/src/relay.cpp:40: undefined reference to `np::np()'
collect2: error: ld returned 1 exit status
make: *** [Makefile:8: r] Error 1
Running ar t libuttu.a returns
linux.o
uttu.o
timeout.o
peer.o
relay.o
sec.o
np.o
My test script includes the main header file, uttu.hpp, which itself refers to the np header file, under the name of protocols.hpp
The path to the archive file is correct, the archive itself contains the correct object file, and the test script refers to the main header file, which includes the correct definitions.
I'm stuck on what could be going wrong.
After reading this SO question, I realized that I had missed an overridden virtual member.
This question already has answers here:
How to use the fmt library without getting "Undefined symbols for architecture x86_64"
(3 answers)
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed last year.
I'd like to make a python-like dynamic integer class in C++ as an experiment. It requires me to change many integers to string types. As in here: https://www.zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html it states that fmt format_int will be best for that kind of job.
So I installed fmt with command sudo apt-get install libfmt-dev
I added a header #include <fmt/format.h>
Used it in a simple test main
int main()
{
std::cout<<fmt::format_int(124236695253045068).str();
}
And tried to compile with g++ -lfmt -std=c++17 dynamic\ mem.cc
Output of the compiler is as follows:
/usr/bin/ld: /tmp/ccLBcSNm.o: in function `fmt::v6::format_int::format_decimal(unsigned long long)':
dynamic mem.cc:(.text._ZN3fmt2v610format_int14format_decimalEy[_ZN3fmt2v610format_int14format_decimalEy]+0x94): undefined reference to `fmt::v6::internal::basic_data<void>::digits'
/usr/bin/ld: dynamic mem.cc:(.text._ZN3fmt2v610format_int14format_decimalEy[_ZN3fmt2v610format_int14format_decimalEy]+0xad): undefined reference to `fmt::v6::internal::basic_data<void>::digits'
/usr/bin/ld: dynamic mem.cc:(.text._ZN3fmt2v610format_int14format_decimalEy[_ZN3fmt2v610format_int14format_decimalEy]+0xfa): undefined reference to `fmt::v6::internal::basic_data<void>::digits'
/usr/bin/ld: dynamic mem.cc:(.text._ZN3fmt2v610format_int14format_decimalEy[_ZN3fmt2v610format_int14format_decimalEy]+0x113): undefined reference to `fmt::v6::internal::basic_data<void>::digits'
/usr/bin/ld: /tmp/ccLBcSNm.o: in function `std::make_unsigned<long>::type fmt::v6::internal::to_unsigned<long>(long)':
dynamic mem.cc:(.text._ZN3fmt2v68internal11to_unsignedIlEENSt13make_unsignedIT_E4typeES4_[_ZN3fmt2v68internal11to_unsignedIlEENSt13make_unsignedIT_E4typeES4_]+0x2b): undefined reference to `fmt::v6::internal::assert_fail(char const*, int, char const*)'
collect2: error: ld returned 1 exit status
Do you have any ideas what went wrong? I don't usually link non-standard libraries so I don't have any idea what to do about it.
Use
$ g++ -std=c++17 dynamic\ mem.cc -lfmt
fmt is provided as a static library (.a). With those, the order is important as the linker takes out of a library only the objects which are needed to provide symbols to other objects or libraries which precede them in the command line. If you start with a library, there is only main which is missing and usually libraries don't provide main, so they are ignored. When putting the library after your source code, the symbols missing in your code are searched in the library.
(In case of circular dependencies, you may even have to provide a library several times)
a C++ code built into a shared library for HELib is using NTL and GMP static library. But it gets following error:
/usr/bin/ld: /usr/local/lib/libntl.a(FFT.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libntl.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
It was suggested int the post Click here
to recompile NTL and GMP with "-fPIC " flags.
I'am not able to find how I should do that.
Edit:
I'm able to build the shared library now after :
recompiling GMP and NTL by:
./configure --enable-shared
for gmp and
./configure SHARED=on
After make Install of HELib. I get error when I run the example codes.
The link to the Makefile : click to see makefile
Error:
g++ -g -O2 -std=c++11 -pthread -DFHE_THREADS -DFHE_BOOT_THREADS -DFHE_DCRT_THREADS -o Test_General_x Test_General.cpp -L/usr/local/lib -lntl -lgmp -lm -lfhe
/usr/local/lib/libfhe.so: undefined reference to write_raw_int(std::ostream&, long, long)'
/usr/local/lib/libfhe.so: undefined reference toread_raw_ZZ(std::istream&, NTL::ZZ&)'
/usr/local/lib/libfhe.so: undefined reference to void write_raw_vector<long>(std::ostream&, std::vector<long, std::allocator<long> > const&)'
/usr/local/lib/libfhe.so: undefined reference towriteEyeCatcher(std::ostream&, char const*)'
/usr/local/lib/libfhe.so: undefined reference to write_raw_xdouble(std::ostream&, NTL::xdouble)'
/usr/local/lib/libfhe.so: undefined reference toread_ntl_vec_long(std::istream&, NTL::Vec&)'
/usr/local/lib/libfhe.so: undefined reference to void read_raw_vector<long>(std::istream&, std::vector<long, std::allocator<long> >&)'
/usr/local/lib/libfhe.so: undefined reference toreadEyeCatcher(std::istream&, char const*)'
/usr/local/lib/libfhe.so: undefined reference to read_raw_int(std::istream&, long)'
/usr/local/lib/libfhe.so: undefined reference toread_raw_xdouble(std::istream&)'
/usr/local/lib/libfhe.so: undefined reference to write_raw_ZZ(std::ostream&, NTL::ZZ const&)'
/usr/local/lib/libfhe.so: undefined reference towrite_ntl_vec_long(std::ostream&, NTL::Vec const&, long)'
collect2: error: ld returned 1 exit status
Makefile:179: recipe for target 'Test_General_x' failed
make: *** [Test_General_x] Error 1
For NTL v11.5.1 atleast, doing ./configure --help | grep -i pic (as suggested in one of the comments for GMP) did not help at all - it found no matches. However, making a one line change in the file ntl-11.5.1/src/DoConfig (on line 17) from:
'CXXFLAGS' => '-g -O2'
to:
'CXXFLAGS' => '-g -O2 -fPIC',
solved the problem for me.
Marc Glisse provided the answer for the first two parts of the question.For the third part "Undefined Reference error" the answer is I'd not compiled and linked a x.cpp containing the functions that caused the undefined reference into my shared library. hence check : nm -CD /usr/local/lib/libfhe.so to see if these functions are listed with a linking address or not. If not then check which code provides this functionality. Link that code to the shared library.
I'm currently trying to build a simple IceCast supplier using libshout.
Unfortunately, I am unable to resolve some linker errors:
Invoking: Cygwin C++ Linker
g++ -L"D:\Programme\Cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\ogg" -L"D:\Programme\Cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include" -L"D:\Programme\Cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\vorbis" -o "LibshoutJavaAdapter.exe" ./src/LibshoutJavaAdapter.o -lshout -lvorbis -logg -lssl -lcrypto
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/../../../../lib/libshout.a(tls.o): In function `tls_setup_process':
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:200: undefined reference to `SSL_is_init_finished'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:200:(.text+0x74): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `SSL_is_init_finished'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:203: undefined reference to `SSL_is_init_finished'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:203:(.text+0x8f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `SSL_is_init_finished'
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/../../../../lib/libshout.a(tls.o): In function `tls_setup':
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:66: undefined reference to `OPENSSL_init_ssl'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:66:(.text+0x4ad): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `OPENSSL_init_ssl'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:67: undefined reference to `OPENSSL_init_ssl'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:67:(.text+0x4b9): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `OPENSSL_init_ssl'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:68: undefined reference to `SSLeay_add_all_algorithms'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:68:(.text+0x4be): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `SSLeay_add_all_algorithms'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:69: undefined reference to `OPENSSL_init_ssl'
/cygdrive/d/Programme/utility/libshout-2.4.1/src/tls.c:69:(.text+0x4c7): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `OPENSSL_init_ssl'
collect2: error: ld returned 1 exit status
I'm using CygWin's GCC 64 bit version, butalso got a 32 version to compile with if needed.
The build is triggered using make
My actual code up to now is pretty basic (I'm only just getting started with this library)
#include <iostream>
#include <shout/shout.h>
int main() {
shout_init();
std::cout << "!!!Hello World!!!" << std::endl; // prints !!!Hello World!!!
return 0;
}
I use the following libraries for the linker in this Order(-l):
shout -> the actual library i try to use
vorbis
ogg
ssl
crypto
From the look of the error I suppose, that this is related to ssl somehow, but i did include those didn't I ?
I already tried rotating the order, but that only created more errors, so I suppose the order is correct ...
Edit 1:
As nnovich-OK suggested, I altered my code like this to check OpenSSL:
#include <iostream>
//#include <shout/shout.h>
#include <ctype.h>
#include <openssl/ssl.h>
int main() {
//shout_init();
OPENSSL_init();
OPENSSL_INIT_SETTINGS * test = NULL;
OPENSSL_init_ssl(0,test);
//SSL_is_init_finished();
std::cout << "!!!Hello World!!!" << std::endl; // prints !!!Hello World!!!
return 0;
}
There resulting Linking error looks like this:
g++ -L"D:\Programme\Cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\ogg" -L"D:\Programme\Cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include" -L"D:\Programme\Cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\vorbis" -o "LibshoutJavaAdapter.exe" ./src/LibshoutJavaAdapter.o -lshout -lvorbis -logg -lssl -lcrypto
./src/LibshoutJavaAdapter.o: In function `main':
/cygdrive/d/Install und andere Sachen/Eclipse/C++/LibshoutJavaAdapter/Debug/../src/LibshoutJavaAdapter.cpp:18: undefined reference to `OPENSSL_init_ssl'
/cygdrive/d/Install und andere Sachen/Eclipse/C++/LibshoutJavaAdapter/Debug/../src/LibshoutJavaAdapter.cpp:18:(.text+0x27): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `OPENSSL_init_ssl'
collect2: error: ld returned 1 exit status
I see that there is a problem with OPENSSL_init_ssl from ssl.h but not with OPENSSL_init from crypto.h (witch intern is included by ssl.h)
Does that gives anyone any idea?
Any hints to resolving this Problem appreciated
I don't have the same setup to try, but provided info seems clear enough. Linker can't find functions from ssl library, so you need to focus on linking ssl. I think, issue scenario can be reduced to simple main function calling OPENSSL_init_ssl() (parameters doesn't matter, since you aren't going to execute it) and build process involving linking only openssl. Resolving this linking failure will help to resolve your current case. So let the Google and SO be with you :)
PS I'd rather put all this into comment, but SO newcomers aren't allowed to.
Edit:
Subsequent troubleshooting (check comments below) revealed actual root cause. System has several libssl instances (e.g. some app installation brought another version) and linker used instance not suitable for current build (e.g. 32bit version in building 64bit app). So the solution was to put linker into verbose mode and to check whether library paths are as expected.
GCC 4.5 added support for decimal floating points in the runtime library (http://gcc.gnu.org/gcc-4.5/changes.html). I'm able to compile code including , using namespace std::decimal, then using decimal64 and so on in the code.
Unfortunately, I'm missing some library for linking the code. I've not been able to find out which libraries should be required. DFP support is enabled in gcc (--enable-decimal-float=dpd)
Additionally, should there be some fast way of providing decimal literals in the code? By fast, I mean user defined literals that are handled by templates and translated at compile time. I do not want to provide doubles that are converted at runtime (despite performance and the fact that I really can't stand moving evaluations from compile time to runtime there are still rounding issues...). I've already found the suffix "df" but that does not seem to be recognized by the compiler.
I'm using gcc version 4.7.1 on target powerpc-ibm-aix7.1.0.0.
Linker error messages:
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatsisd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatsidd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatsitd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_mulsd3
ld: 0711-317 ERROR: Undefined symbol: .__dpd_muldd3
ld: 0711-317 ERROR: Undefined symbol: .__dpd_multd3
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatdisd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatunsdisd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatdidd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatunsdidd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatditd
ld: 0711-317 ERROR: Undefined symbol: .__dpd_floatunsditd
TIA.
I've recently compiled gcc4.7.1 from source and had trouble with missing symbol __floatunsidf. This turned out to be a symbol required by libstdc++.so and defined in libgcc_s.so. Given that both Libraries are provided by gcc they should be compatible. In my case i still had a linker include to an old version of libgcc_s that i'd lifted from my target platform. Its probably worth doing
# to find out where libstdc++.so is:
gcc -print-file-name=libstdc++.so
# see if it references the symbol you're missing
readelf -a "path to libstdc++.so" | grep "symbol name"
and then doing the same for libgcc_s to see if they both define the symbol you are missing. Nb one will mark the symbol as undefined - thats how the linker knows its required.