i'm trying to compile a simple test-program with libnuma (only numa_available is called) and i get a undefined reference error for this function.
At first, i used apt-get to install libnuma-dev and then simply used gcc -lnuma -o test test.c to compile the test program.
This led to 'undefined reference of numa_available'.
Then, I used dpkg -L libnuma-dev to make sure that the lib is actually installed (and just be sure I used strings to check whether the interface has changed or something - I know, this method is crap, but there were some "numa_available" strings in the lib, so i thought is rather safe to assume that the interface has not changed)
Then i also tried -l:/usr/lib/x86_64-linux-gnu/libnuma.so and -L/usr/lib/x86..gnu, however this always led to the undefined reference error.
Finally, i tried to statically link it (simply gcc -lnuma .... test.c /usr/lib../libnuma.a) and fortunately it works now...
However, can anyone tell me why it does not work dynamically linked?
best regards
Judging from your link command ("gcc -lnuma .... test.c /usr/lib../libnuma.a"), the most likely reason is that you need to move -lnuma to after test.c. --as-needed flag is enabled by default in modern distros and will not link in library unless it has been referred by preceeding objects.
Related
I install ceres in ubuntu and use the all of the command line in http://ceres-solver.org/installation.html Linux part from
sudo apt-get install libgoogle-glog-dev
all the way to
make install
Seems I have installed ceres solver and it dependency without problem.
But when I try to run the test file
bin/simple_bundle_adjuster ../ceres-solver-1.12.0/data/problem-16-22106-pre.txt
It shows
unable to open file ../ceres-solver-1.9.0/data/problem-16-22106-pre.tx
Then I try to compile helloworld in tutorial use command
g++ -I/usr/include/eigen3 helloworld.cpp -o helloworld
It gives me a bunch of problems.
undefined reference to google::InitGoogleLogging(char const*)'
helloworld.cpp:(.text+0x104): undefined reference toceres::Problem::Problem()'
helloworld.cpp:(.text+0x155): undefined reference to `ceres::Problem::AddResidualBlock(ceres::CostFunction*, ceres::LossFunction*, double*)'
I didn't list them all. But seems it cannot find things about google at all.
Hope you can help me!!
it gives me a mountain of problems.
Sounds like you're not linking to the library; this would cause references to be undefined. If you are calling the linker (G++ can be the linker), then add -lglog add the end, it should then link it to glog.
Similarly, you should also link to ceres.
Here's a snippet from the things I need to link to use a library which uses Ceres. In CMake. I suggest you start at the bottom/end and add things to the top to fix, you may need to prefix with -l to indicate that you need to link them.
I recommend using cmake, so that you can simply paste this list in a target_link_libraries(myexecutable listhere) and remove unnecessary/unused libraries;
umfpack
cxsparse
stlplus
glog
gomp
ccolamd
btf
klu
cholmod
lapack
blas
camd
amd
pthread
ceres
I'm trying to compile an example programme using tk. I have nearly all of the libraries sorted, but I think I'm missing one.
Command:
gcc ./tk.c -I/usr/include/tcl8.5/ -ltk8.5 -ltcl8.5 -lm -lpthread -lfontconfig -lX11 -lXft -lXss
Output:
/tmp/cc78MM6w.o: In function `Tk_AppInit':
tk.c:(.text+0xf5): undefined reference to `ClockCmd'
tk.c:(.text+0x120): undefined reference to `ClockObjDestroy'
tk.c:(.text+0x130): undefined reference to `ClockObjCmd'
There's nothing on Google -- anyone recognise ClockCmd? Thanks.
I think those are part of the implementation of Tcl, and should not be referred to outside the Tcl library itself. (The linker is instructed to remove the external reference to them when building the DLL/shared object.) Either that or they are part of your code, and you've simply not supplied them for some reason, but I think you'd know if that was the case.
It would be far easier to work out what's going on if we could actually see the code of tk.c; it's clearly not part of any Tcl or Tk code distribution.
Something wrong with the example code I think; none of the other examples had a problem.
I am trying to build a tool called sscep (http://www.klake.org/~jt/sscep/) for Windows. It does not run natively and I have a "patch" that changes sscep to make it compile on Windows.
After applying the patch, it does compile perfectly but the linker screws. I am using gcc in minGW/msys
The original messsage was that it couldn't find the crypto lib so I added the library with "-L../openssl-mingw/lib" which then didn't create any more errors. I also have the command line switch -lcrypto in my command: gcc -L../openssl-mingw/lib -lcrypto sscep.o init.o net.o sceputils.o pkcs7.o ias.o fileutils.o -o sscep.In this directory is a libcrypto.a. OpenSSL itself was compiled with the exact same compiler just running ./config && make && make test && make install. Also the sources were extracted using the minGW tar and not 7-zip.
After following all documentation this is my (truncated) output:
sscep.o:sscep.c:(.text+0x83): undefined reference to `WSAStartup#8'
sscep.o:sscep.c:(.text+0xa5): undefined reference to `WSACleanup#0'
sscep.o:sscep.c:(.text+0x3d5): undefined reference to `BIO_new_mem_buf'
sscep.o:sscep.c:(.text+0x3e0): undefined reference to `ASN1_INTEGER_new'
sscep.o:sscep.c:(.text+0x414): undefined reference to `a2i_ASN1_INTEGER'
sscep.o:sscep.c:(.text+0x432): undefined reference to `ASN1_INTEGER_to_BN'
sscep.o:sscep.c:(.text+0x448): undefined reference to `BN_bn2dec'
sscep.o:sscep.c:(.text+0xb7e): undefined reference to `EVP_des_cbc'
sscep.o:sscep.c:(.text+0xbaf): undefined reference to `EVP_bf_cbc'
sscep.o:sscep.c:(.text+0xbda): undefined reference to `EVP_des_cbc'
sscep.o:sscep.c:(.text+0xc02): undefined reference to `EVP_des_ede3_cbc'
sscep.o:sscep.c:(.text+0xc48): undefined reference to `EVP_md5'
sscep.o:sscep.c:(.text+0xc79): undefined reference to `EVP_md5'
sscep.o:sscep.c:(.text+0xca1): undefined reference to `EVP_sha1'
This goes on for every file in there and supposedly every function called.
Searching here and google resulted in a missing library but omitting the -L directive from above I get another error about not finding libcrypto. So I assume that the library is actually found but somewhat with wrong addresses or something?
Here my compiler/linker knowledge actually ends.
If it is possible that the patch is responsible for that (which I do not believe since these are all openssl functions and the compiling works) then I can provide you with it.
Edit: Is there any information that I should provide so someone can help me? The version of openssl is 1.0.1 if this makes any difference.
On this topic: If it does make a difference, could this error occur because of a wrong version. As far as I understand linker theory, this error should not originate from a wrong version unless all of the below functions were replaced by differently named ones (but then the compiler would have complained, I guess?).
Another addition: Since I am on a 64 bit Windows 7, I tried to compile it with -m32 flag but that did not help. I assume since mingw is already 32 bit only, I can't even build x64. Another question is whether it is a problem that I am running in a virtualized environment on an AMD Opteron while openssl is built with the command "-march=i486"?
With some help I could finally figure this out! It was a problem of the order AND a problem of missing libraries. The combination killed me.
The libraries had to be -lcrypto -lws2_32 -lgdi32 not just -lcrypto. Furthermore, I had to append the libraries after the object files, so: $(CC) $(CFLAGS) $(OBJS) -lcrypto -lws2_32 -lgdi32 -o $(PROG) was the right make line.
Finally with this, it compiles fine. I didn't even need any architecture flags and such.
I am trying to link a C++ module using GCC, essentially like this:
gcc -c hello.c
g++ -c world.cpp
gcc -ohello -lstdc++ hello.o world.o
Note that I use -lstdc++ to link the C++ module in, so that I can use gcc instead of g++. The problem is that I'm getting the error:
undefined reference to `operator new(unsigned long)'
(Assuming that world.cpp contains at least one call to new.)
This error is fixed if I put -lstdc++ at the end of the linker line, like this:
gcc -ohello hello.o world.o -lstdc++
I am aware that this question has been asked many times here, but I have a special requirement. I am not directly calling GCC. I am using a build system for a different programming language (Mercury) which is calling GCC on my behalf, and I can't easily modify the way it calls GCC (though I can specify additional libraries using the LDFLAGS environment variable). So I have two additional requirements:
I cannot use g++ to link (only gcc) -- that is why I am doing the -lstdc++ trick above rather than simply linking with g++).
I don't think that I can control the order of the linker commands -- Mercury will put the .o files on the command-line after any libraries.
I understand the basic reason why the order is important, but what is baffling me is why did this break now? I just updated to Ubuntu 11.10 / GCC 4.6.1. I have been successfully compiling this program for years using precisely the above technique (putting -lstdc++ first). Only now has this error come up. An unrelated program of mine links against OpenGL using -lgl and that too broke when I upgraded and I had to move -lgl to the end of the command-line. I'm probably going to discover that dozens of my programs no longer compile. Why did this change? Is there something wrong with my new system or is that the way it is now? Note that these are ordinary shared libraries, not statically linked.
Is there anything I can do to make GCC go back to the old way, where the order of libraries doesn't matter? Is there any other way I can convince GCC to link libstdc++ properly without moving it after the .o files on the command-line?
If Mercury puts object files after libraries, Mercury is broken. Libraries belong after object files - always. You may sometimes get away with the reverse order, but not reliably. (Static libraries must go after the object files that reference symbols in the static library. Sometimes, a linker will note the symbols defined by a shared library even when none of the symbols are used; sometimes, the linker will only note the shared library symbols if the shared library provides at least one symbol.)
I'm extremely new to using Makefiles and autoconf. I'm using the Camellia image library and trying to statically link my code against their libraries. When I run "make" on the Camellia image library, I get libCamellia.a, .so, .la, and .so.0.0.0 files inside my /usr/local/lib directory. This is the command I use to compile my code with their libraries:
gcc -L/usr/local/lib -lCamellia -o myprogram myprogram.c
This works fine, but when I try to statically link, this is what I get:
gcc -static -L/usr/local/lib -lCamellia -o myprogram myprogram.c
/tmp/cck0pw70.o: In function `main':
myprogram.c:(.text+0x23): undefined reference to `camLoadPGM'
myprogram.c:(.text+0x55): undefined reference to `camAllocateImage'
myprogram.c:(.text+0x97): undefined reference to `camZoom2x'
myprogram.c:(.text+0x104): undefined reference to `camSavePGM'
collect2: ld returned 1 exit status
I want to statically link because I'm trying to modify the Camellia source code and I want to compare my version against theirs. So after some googling, I tried adding AM_DISABLE_SHARED into the configure.in file. But after running ./configure, I still get the exact same Makefile. After I "make install", I still get the same results above.
What is an easy way to get two versions of my code, one with the original Camellia source code compiled and one with my modified version? I think static libraries should work. There is an easy way to get static libraries working or are there other simple solutions to my problem? I just don't want to re-"make" and re-"make install" everytime I want to compare my version against the original.
Did you re-run autoconf after adding AM_DISABLE_SHARED and before configure, make, make install? You also can just use configure --disable-dynamic to stop it building the shared libraries. Make sure you delete any previously installed ones - make uninstall should do that. I can't see anything else obviously wrong. Try being explicit:
gcc -static -o myprogram myprogram.c /usr/local/lib/libCamellia.a
or break it down into two steps and check the symbols in myprogram.o are what you expect with nm myprogram.o.
I am not skillful with autoconf and I don't know why your attempt to link statically fails, but if linking dynamically works I think using shared libraries would actually solve your problem a little better.
Just make two shared libraries, one with the original Camellia code and one with your modified version. Put them in two different directories, and when you run myprogram you can choose between them either by switching LD_LIBRARY_PATH (or whatever you're using to find libraries) or by keeping a symbolic link in /usr/local/lib and switching it between libraries. The advantage of this over static libraries (apart from the fact that this works) is that you can tinker with your modified code, rebuild the shared library and run without having to rebuild myprogram (as long as you don't modify the signatures).
P.S. An experiment: try removing the shared libraries from /usr/local/lib and rebuilding without the -static flag, just as if you were using the shared libraries. In theory this should cause gcc to use the static libraries instead. The results may give a clue to why the static link is failing.