I'm trying to compile C with gcc in command prompt but I'm getting this undefined reference to `wWinMain' error.
I was getting undefined reference to `WinMain' first but I fixed that by adding the argument:
-municode
Now `wWinMain' is undefined. How to fix this?
C:\Development\WA\Library\Backend\C\CB\CB>gcc CB.c -lssl -lcrypto -municode
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_w.o):crt0_w.c:(.text+0x21): undefined reference to `wWinMain'
collect2.exe: error: ld returned 1 exit status
gcc CB.c -lssl -lcrypto will compile and link an application, which on Windows defaults to a windowed application for which the entry point is WinMain (which your library obviously does not have nor need).
Adding the -municode just instructs the system to use the windows unicode API and then the entry point becomes wWinMain, and you still have the same problem.
To build a DLL, add -shared: gcc CB.c -shared -lssl -lcrypto
You didn't provide any of your code. And the problem I encountered is similar to this, so I'll describe the experience I had.
I was try out Dear ImGui library, and when I added the -municode option, the linker complained the same thing as yours. I did some searching, and found an answer to a similar question and another comment discussing a related problem, they both suggesting change "main" to "wmain". I did that, and the build was able to succeed.
I'm not knowledgeable enough to provide any deeper information about the source of the problem though.
Related
Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.
I'm getting a linker error whenever I #include in my program. I have downloaded libcurl from haxx.se, compiled libcurl.dll, and added -Icurl to my GCC options when compiling (as well as tried adding a direct path using -L to the dll). However, I still get the following errors:
undefined reference to `_imp__curl_easy_init'
undefined reference to `_imp__curl_easy_setopt'
undefined reference to `_imp__curl_easy_setopt'
undefined reference to `_imp__curl_easy_perform'
undefined reference to `_imp__curl_easy_strerror'
undefined reference to `_imp__curl_easy_cleanup'
My compile command includes this:
-Icurl -L"F:/GCCnew/lib/libcurl.dll"
What am I doing wrong? I suspect it's something simple but I can't work it out and searching hasn't given me a solution that doesn't use something like Code::blocks.
My compile command includes this:
-Icurl -L"F:/GCCnew/lib/libcurl.dll"
If you use mingw gcc, then:
First, -L must have a folder name, not a library name.
Second, there must be '-l' option. For example -lcurl.
Third, -Icurl is irrelevant to your linker error
So the command to build might look like:
gcc your-file.c -o executable_name -L"F:/GCCnew/lib" -lcurl
Useful links:
http://www.mingw.org/wiki/sampleDLL (Building a client executable)
http://www.mingw.org/wiki/Specify_the_libraries_for_the_linker_to_use
http://www.mingw.org/wiki/LibraryPathHOWTO
I am trying to build an example program which uses WinPcap-functions. I’m working under Windows 7 64 Bit edition with MinGW. I am able to compile the C-code to an object file, but I can’t link against wpcap.lib.
My linker call looks like this:
gcc -L ../../lib/x64 send_packet.o -lwpcap -o WinPcapTest.exe
With this call I get the following errors:
undefined reference to pcap_open
undefined reference to pcap_sendpacket
undefined reference to pcap_geterr
Obviously I am not linking against wpcap.lib, but I don’t know why. The library is definitely found. If I change the lib include path for example, I get this error:
cannot find -lwpcap
Why does the linker find the lib but does not link against it? Thanks for your help.
Try listing you libraries after binary definition. As far as I remember, with provided gcc command, ld would be symbol matching for pcap symbols between send_packet.o and libwpcap.lib but not with WinPcapTest.exe. I would suggest moving -lwpcap at the end:
gcc -I ..\..\..\Downloads\WpdPack_4_1_2\WpdPack\Include ..\send_packet.c -L ..\..\..\Downloads\WpdPack_4_1_2\WpdPack\Lib\x64 -O0 -g3 -Wall -o WinPcapTest.exe -lwpcap
I am working on a project written in a mix of Fortran 90 and Fortran 77 and now need to link the LAPACK/BLAS libraries, from netlib.org, to the project, all in a Linux environment. I used the gfortran compiler flags OPTS = -O2 -fPIC -m64 in the given Makefile, and then made it using
make blaslib
make
And it finished normally, or at least I think so.
Then, I copied the files in /usr/local/lib and /usr/local/bin/ and /usr/local/lib64/
but it didn't work. I even used the option -L/path/to/lapack/liblapack.a and it didn't work also.
When I compile my code, I get the following error:
qrB.o: In function `qrfactorizeb_':
qrB.f90:(.text+0x64f): undefined reference to `zgeqp3_'
collect2: ld returned 1 exit status
make: *** [run] Error 1
I am really unsure what to make of this error. I tested it in 3 other workstations and it didn't help! Can anyone help me?
I had the same problem some time ago! Dual working with Windows and Linux and also ease of playing with options in Windows taught me something interesting!
Try compiling such as:
[...]$
ifort liblapack.a libblas.a libslatec.a *.o -o profmm
and as you know, it means that I want to use 3 libraries to compile and link my files into profmm output file. It has no syntax error, but it leads to a lot of errors like:
preconditioner3.o: In function factorb_':
preconditioner3.f:(.text+0x1add): undefined reference tozgetrf_'
.
.
preconditioner.o: In function factorpre_':
preconditioner.f:(.text+0x13a2): undefined reference tozgetrf_'
preconditioner.f:(.text+0x18bb): undefined reference to zgetri_'
zbesh.o: In functionzbesh_':
zbesh.f:(.text+0xb3): undefined reference to d1mach_'
zbesh.f:(.text+0xcf): undefined reference toi1mach_'
.
.
.
and many more errors indicating that ifort is unable to read my libraries even though they are here in my current directory!
But simply change the command as follow:
[...]$ ifort *.o liblapack.a libblas.a libslatec.a -o profmm
and it works fine with no error! So it means that now ifort can read my library (local ones)! Also note that changing the order of libraries are very important, and it depends on the order of usage of those subroutines inside the program. So always try to reorder the library chain to check for possible errors.
Hope it helps.
I'm using MinGW. I have some code which calls malloc and a few other general purpose functions. When I type:
gcc TestCode.c
I get an a.exe file, it works perfect, and I don't get any warnings.
If I type this:
gcc -c TestCode.c -o TestCode.o
ld *.o
I get a whole bunch of warnings such as:
TestCode.o:TestCode.c:(.text+0xa): undefined reference to `__main'
TestCode.o:TestCode:(.text+0x2e): undefined reference to `printf'
TestCode.o:TestCode:(.text+0x42): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0x69): undefined reference to `snprintf'
TestCode.o:TestCode:(.text+0x7e): undefined reference to `malloc'
TestCode.o:TestCode:(.text+0x93): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0xb1): undefined reference to `sprintf'
TestCode.o:TestCode:(.text+0xcf): undefined reference to `free'
I'm assuming this is an issue with how I'm calling the linker. As such, I'll only post the code if it isn't clear what the problem is. I'm hoping this is an easy fix and that I simply forgot to include some super obvious library when linking.
It appears that your ld doesn't link any libraries by default. From your error messages, it looks like you need at least the C runtime and libc. Use gcc to link to get some handy defaults linked in for you:
gcc -c TestCode.c -o TestCode.o
gcc *.o
If you really want to use ld directly, you're going to need to figure out the names of your C runtime library and libc. For example (assuming libraries named libcrt and libc):
ld *.o -lcrt -lc
As Carl Norum said, you can pass object files to gcc and it'll know it doesn't need to compile them - it just passes them on to the linker (whether or not you're compiling other source files in the same invocation).
And you should probably do that because there's a fair amount of detail that goes into linking in the CRT and windows support libraries (unless you have a very specific need to not use the default runtime). My current MinGW setup links in the following items along with my object files:
crt2.o
crtbegin.o
-ladvapi32
-lshell32
-luser32
-lkernel32
-lmingw32
-lgcc
-lmoldname
-lmingwex
-lmsvcrt
crtend.o
Use the --verbose option to see how gcc links for you.