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.
Related
Im trying to link with a game library that has already been compiled using mingw, called Raylib. However; whenever I use MSYS's gcc 10.2 it gives me the following undefined reference error:
gcc main.c -Iraylib-3.7.0_win64_mingw-w64/include -Lraylib-3.7.0_win64_mingw-w64/lib -lraylib -lopengl32 -lgdi32 -lwinmm
/usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: raylib-3.7.0_win64_mingw-w64/lib/libraylib.a(core.o):core.c:(.text+0x1f6e): undefined reference to '_assert'
It seems that I maybe missing a library? This is just one of many similar errors. The majority of these undefined references are for assert like the one listed above. Some deal with GLFW and other libraries. Has anyone experienced something like this on MSYS?
Looks like I needed to be directly in MSYS2 mingw64 environment (cmd prompt). I was using the regular MSYS2 MSYS environment.
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.
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.
This is strange because I was able to get the error below to go away by removing the reference to libm.
gcc -o example example.o -Wl -L/home/kensey/cdev/lib -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -L/usr/lib/x86_64-linux-gnu -lm -lrt -ldl -lcdev -L/home/kensey/www.tools/gplot-lib -lgplot -L/home/kensey/www.tools/gd1_3ret -lgd -lxml2 -lcurl
/usr/bin/ld: /home/kensey/www.tools/gplot-lib/libgplot.a(set.o): undefined reference to symbol 'floor##GLIBC_2.2.5'
/usr/bin/ld: note: 'floor##GLIBC_2.2.5' is defined in DSO /usr/lib/x86_64-linux-gnu/libm.so so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
So, if I remove the -lm part of the command, I do not get the error. However, I wonder if anyone knows as to why removing a reference to a library that is needed would fix this. How does the linker know which library to look in? Also - is there a way to query a built executable and say 'which library did you resolve the reference to 'floor'? obviously, there is something going on that I don't understand, and that bothers me...
The explanation to what's happening is very simple:
Your libgplot.a depends on libm.so, yet the order of -lm and -lgplot on the link line is wrong.
The order of libraries on the link line does matter. In general, system libraries (-lpthread, -lm, -lrt, -ldl) should follow everything else on the link line.
When you remove -lm from the link line, libm.so.6 is still pulled into the link by some other library that appears later on the link line (libgd, libxml2 or libcurl) because that library depends on libm.so.6. But now libm.so.6 is in correct place on the link line, and so everything works.
if I put -lm at the end of the link command, listing it as the last library, I do not get the error.
That confirms above explanation.
I've solved the same problem with export LDFLAGS="$LDFLAGS -lm"
Perhaps, your library search paths (/usr/local/lib/ or /usr/lib/, ...) do not contain 64bit libm so gcc cannot locate it if you specify with l flag. If you only specify only the directory it looks like it can find the right one. So you can try:
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
and use -lm
Hard to tell. Because there are custom library directories in the command line it's conceivable that -lm links an incompatible alternative version. Without -lm the linker could pull in another version of it because it's needed by one of the libraries you link.
To make sure strace both invocations and see where libm.so is coming from in both cases.
BTW, -Wl switch seems to do nothing and -L/usr/lib/x86_64-linux-gnu is mentioned twice.
Just to add to the list of answers, http://fedoraproject.org/wiki/UnderstandingDSOLinkChange It is informative. It isn't relevant to the question asked above, but, the explanation relates to the error message /usr/bin/ld: note: 'some_reference' is defined in DSO some.so so try adding it to the linker command line
One explanation could be:
It's possibly there is a weakly linked function foo defined outside of libm that is replaced by a strongly linked version of foo defined inside libm, and it is this strongly linked version that calls the undefined function.
This would explain how adding a library can cause an undefined function error.
I just ran into a similar problem; I remember that the order of the libraries did not matter (at least not in the cases I worked with) in the past for gcc. In this question here somebody noticed that the behaviour seems to have changed between 4.4 and 4.5 .
In my case, I got rid of the error message by doing the linking at:
g++ -Wl,--copy-dt-needed-entries [options] [libraries] [object files] -o executable-file
I faced the similar issue because I had manually updated the dev toolchain on my centOS machine to solve a VScode Remote dependency and was linking C++ library with c code.
In my case, I solved this by adding in the Makefile:
LDFLAG=-Wl,--copy-dt-needed-entries
I also pointed my gcc to the version I wanted (After updating toolchain, gcc pointed to the toolchain : /opt/rh/devtoolset-2/root/usr/bin/gcc)
CC=\usr\bin\gcc which is (gcc version 4.4.7)
Use this:
administrator#administrator-Veriton-M200-H81:~/ishan$ gcc polyscanline1.cpp -lglut -lGLU -lGL -lm
I'm doing a opengl program, and found an example that does what I want, but when I try to compile it, using
gcc -o picksquare picksquare.c -lglut
I get:
/tmp/cchE9Z0Y.o: In function `pickSquares':
picksquare.c:(.text+0x41d): undefined reference to `gluPickMatrix'
picksquare.c:(.text+0x442): undefined reference to `gluOrtho2D'
/tmp/cchE9Z0Y.o: In function `reshape':
picksquare.c:(.text+0x508): undefined reference to `gluOrtho2D'
collect2: ld returned 1 exit status
And the code example is here:
http://www.opengl.org/resources/code/samples/redbook/picksquare.c
Thanx for your answer guys, but invoking with -lglu says it can't find glu, and invoking with -lGL gives the same undefined reference. What is this glu? Does anyone know?
Try this:
gcc filename_here -lglut -lGLU
This should work fine. The last word in the above sentence is lGLU (not one but l for lion) .
Because you're calling functions in the GLU library (which is not the same as GLUT), without linking to it.
Add -lglu to your command line.
Note that the functions failing have glu as their prefix, not glut.
If adding -lglu gives you a new error, that might mean you development system doesn't have the GLU library installed. It's an optionalal library independent of OpenGL, so just because you have installed development support for OpenGL there's no guarantee that you also have it for GLU.
Looks like you don't have the necessary libraries installed or you need to point your LD_LIBRARY_PATH to a correct location to pick up libglut.so.
AFAIK, for gluOrtho2D & co. you have to link against libGL, which means you have to add a -lGL switch on your command line.
Ok, found the problem, I wasn't adding the glu library to the gcc compiler, addind '-lGLU' solved the problem. Thanx anyways guys!!