I have a simple socket program that I'm trying to compile using g++ running in mingw (both the latest versions) on a Win8 system. I'm getting the common linker errors
undefined reference to `__imp_socket'
undefined reference to `__imp_gethostbyname'
I've tried adding -lws2_32 with no luck; i.e. it still can't find the references. Can someone suggest something else I might be missing?
Here's the full output:
G:\source\kak>g++ -o ./test_client -lws2_32 test_client.C
C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o:test_client.C:(.text+0x4f): undefined reference to `__imp_inet_addr'
C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o:test_client.C:(.text+0x6b): undefined reference to `__imp_socket'
C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o:test_client.C:(.text+0x8b): undefined reference to `__imp_connect'
d:/program files/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o: bad reloc address 0xc in section `.xdata'
collect2.exe: error: ld returned 1 exit status
Try putting the -lws2_32 after the test_client.C parameter. The linker of gcc (ld) is touchy about the order of linkable things, this is probably why it doesn't find your imported functions at link time.
Related
compiling c++ from linux to windows using g++ and got an error.
Error:
undefined reference to `FOLDERID_RoamingTiles'
collect2: error: ld returned 1 exit status
I'm guessing there is a library I have to reference but I don't know what the name is.
also if that's the case what are the ways I could find the name of the library I have to reference, if that happens again in the future?
thanks.
I'm compiling under msys2/gcc. linking to uuid helped me.
g++ -luuid -o ....
(FYI Yes I do know that a similar question exists, But I have already tried all the answers.)
I'm trying to setup SDL2 with MinGW and I have everything set up beside one thing. Whenever I try to compile G++ gives no errors but then LD gives me a: undefined reference to SDL_Init Error.
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\user\AppData\Local\Temp\cc28dE2R.o: in function `SDL_main':
C:\Users\user\Documents\SDL2/src/main.cpp:11: undefined reference to `SDL_Init'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\user\Documents\SDL2/src/main.cpp:14: undefined reference to `SDL_GetError'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\user\Documents\SDL2/src/main.cpp:18: undefined reference to `IMG_Init'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\user\Documents\SDL2/src/main.cpp:20: undefined reference to `SDL_GetError'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../libmingw32.a(main.o):(.text.startup+0xc0): undefined reference to `WinMain#16'
collect2.exe: error: ld returned 1 exit status
The terminal process "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command C:\MinGW\bin\g++.exe -g src\*.cpp -o build\game.exe -ID:C:\MinGW\include -LD:C:\MinGW\lib -mwindows -lmingw32 -lSDL2main -lSDL2_image -lSDL2" terminated with exit code: 1.
I have tried to move the args around. doing -mwindows, adding -lmingw32. I still keep getting the same errors.. I was able to fix the WinMain Error.. But everything else I couldn't fix.
The command I'm Running to compile:
C:\MinGW\bin\g++.exe -g src\*.cpp -o build\game.exe -ID:C:\MinGW\include -LD:C:\MinGW\lib -mwindows -lSDL2main -lSDL2_image -lSDL2
If i could get any help that would be amazing
The common cause of mysterious undefined reference errors on MinGW is using libraries compiled for x64 with an x32 compiler, or vice versa. SDL ships both x32 and x64 ones, try the other ones.
I was able to fix the WinMain Error
Be aware that the intended way of fixing undefined reference to WinMain#16 is not adding #define SDL_MAIN_HANDLED and not doing #undef main. Once you get the right libraries (see the first paragraph), the error should disappear by itself.
Make sure you use int main(int, char**) (and not int main() nor void main()), otherwise it won't work.
-ID:C:\MinGW\include -LD:C:\MinGW\lib
You shouldn't need those flags. Those directories will be searched automatically.
Since you didn't specify any other directories, I assume you placed the SDL files directly into the compiler directories, which isn't a good practice, IMO.
I assume D:C: a typo?
-mwindows
The only purpose of this flag (that I know of) is to prevent your app from automatically opening a terminal window for itself, for release builds.
I am fairly new to Fortran and this may sound like a silly question. I encounter an error when compiling the Fortran code that is posted as an example in the NLOPT Wiki.
I compile in Ubuntu 18.04 LTS using the following command:
gfortran example-nlopt.f90 -o example-nlopt -I/usr/local/include/
The following error is produced in the terminal:
/tmp/ccbAim6b.o: In function `MAIN__':
example-nlopt.f90:(.text+0x26): undefined reference to `nlo_create_'
example-nlopt.f90:(.text+0x42): undefined reference to `nlo_get_lower_bounds_'
example-nlopt.f90:(.text+0x67): undefined reference to `nlo_set_lower_bounds_'
example-nlopt.f90:(.text+0x8a): undefined reference to `nlo_set_min_objective_'
example-nlopt.f90:(.text+0xca): undefined reference to `nlo_add_inequality_constraint_'
example-nlopt.f90:(.text+0x10e): undefined reference to `nlo_add_inequality_constraint_'
example-nlopt.f90:(.text+0x12d): undefined reference to `nlo_set_xtol_rel_'
example-nlopt.f90:(.text+0x164): undefined reference to `nlo_optimize_'
example-nlopt.f90:(.text+0x305): undefined reference to `nlo_destroy_'
collect2: error: ld returned 1 exit status
Based on what I saw in nlopt's documentation (https://nlopt.readthedocs.io/en/latest/NLopt_Installation/#changing-the-installation-directory) it looks like you just need to specify the library to link against. Maybe try this:
gfortran -I/usr/local/include/ -L/usr/local/lib example-nlopt.f90 -o example-nlopt -lnlopt -lm
This assumes you have the libnlopt.so in /usr/local/lib, if not then point to its location with the -L option.
I'm attempting to compile this tutorial http://www.opengl-tutorial.org/beginners-tutorials/tutorial-1-opening-a-window/ with Cygwin. I'm getting the following errors:
$ g++ main.cpp -o main -lm -lgl -lglut -lglew -lglfw -lopengl32 -lglu32 -lglaux
-lodbc32 -lodbccp32
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11a0): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11c8): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11f0): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1394): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1661): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1696): more undefined references to `_imp___iob' follow
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: /usr/lib/gc
c/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o): bad reloc address 0x0
in section `.rdata'
collect2: error: ld returned 1 exit status
What may be causing this?
When you see unresolved symbols to _imp__, it implies you are trying to link against a library that was built to use a DLL at run-time. Technically, the problem is how the MSVC compiler mangles the import stub for __stdcall functions - it pre-fixes an underscore, which gcc is not expecting (e.g. _imp instead of imp).
cygwin/MinGW needs a little bit of extra help (either they must use a library that was compiled with gcc or the MSVC DLL-based import library must be altered). There is an article that explains this here.
However, the vast majority of the time the simpler solution is simply to link against the static linking version of your library. In the case of GLEW and glfw, they both ship with static libraries. You will need to define GLEW_STATIC and link against glew32s instead of glew. As for glfw, I am not as familiar - consult the documentation for glfw to find out how to do this.
Ok, newb question here.
I'm trying to compile simple_xy_wr.f90 -- a netCDF example program -- using gfortran on Ubuntu, and I must be doing something pretty silly; I don't have much experince compiling Fortran.
First, I've got the libnetcdf-dev package installed, which includes files like
/usr/lib/libnetcdf.a
/usr/lib/libnetcdff.a
/usr/include/netcdf.mod
So, I've tried to compile the code with (various command like)
f95 -o xy -I/usr/include/ -L/usr/lib/ -lnetcdff -lnetcdf simple_xy_wr.f90
and I get the following output
/tmp/ccE6g7sr.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccE6g7sr.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
I think that I'm including the right libraries. E.g. it seems that __netcdf_MOD_nf90_strerror should be there:
$ nm /usr/lib/libnetcdff.a | grep __netcdf_MOD_nf90_strerror
000000000004a100 T __netcdf_MOD_nf90_strerror
What am I doing wrong?
(FWIW, a few relevant references I've looked at are below.
undefined reference using netcdf library
Compiling problems with gfortran and NETCDF
Compiling and Running Fortran Programs - a basic guide
)
Ordering of object files and archives on the linker command line is very important on Unix systems since the default linker behaviour is to search for symbol definitions only in archives that follow the object file or archive, where an unresolved reference was found, referred to single pass linking.
This means that if your code references __netcdf_MOD_nf90_strerror, then the archive that contains the definition of this symbol (libnetcdff.a) must appear after the list of object files from your program. libnetcdff.a itself references symbols from the C library libnetcdf.a, hence it must be linked after libnetcdff.a. So the correct link order is:
/tmp/ccE6g7sr.o libnetcdff.a libnetcdf.a
where /tmp/ccE6g7sr.o is the temporary object file that the assembler produces from the compiled source file. The correct command line to compile your code is then:
f95 -o xy -I/usr/include/ simple_xy_wr.f90 -lnetcdff -lnetcdf
In this case the linker is not called directly, rather the compiler does it. GCC compilers pass all link-related things in the same order to an intermediate utility called collect2 which then calls the actual linker ld.
Note that if shared object versions of the netCDF library archives are also present (i.e. there are libnetcdff.so and libnetcdf.so), then the linker would prefer them to the static archives (unless static linking is enabled with the -static option) and the final link phase would be handled to the run-time link editor (RTLD) (/lib64/ld-linux-x86-64.so.2 on Ubuntu). In this case the same command line as in your question would actually succeed without link errors, despite the fact that both libraries are positioned before the code that references them, as the missing symbol references would be resolved by the RTLD while it is loading the executable file.
In Ubuntu 12.10, the order of the libraries is the trick (as Hristo suggested):
angelv#palas:~$ gfortran -o xy -I/usr/include/ -L/usr/lib/ -lnetcdf -lnetcdff simple_xy_wr.f90
/tmp/ccj95anF.o: In function `check.1847':
simple_xy_wr.f90:(.text+0x72): undefined reference to `__netcdf_MOD_nf90_strerror'
/tmp/ccj95anF.o: In function `MAIN__':
simple_xy_wr.f90:(.text+0x284): undefined reference to `__netcdf_MOD_nf90_create'
simple_xy_wr.f90:(.text+0x2b6): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x2e8): undefined reference to `__netcdf_MOD_nf90_def_dim'
simple_xy_wr.f90:(.text+0x432): undefined reference to `__netcdf_MOD_nf90_def_var_manydims'
simple_xy_wr.f90:(.text+0x468): undefined reference to `__netcdf_MOD_nf90_enddef'
simple_xy_wr.f90:(.text+0x4aa): undefined reference to `__netcdf_MOD_nf90_put_var_2d_fourbyteint'
simple_xy_wr.f90:(.text+0x4cb): undefined reference to `__netcdf_MOD_nf90_close'
collect2: error: ld returned 1 exit status
angelv#palas:~$ gfortran -o xy -I/usr/include/ simple_xy_wr.f90 -L/usr/lib/ -lnetcdf -lnetcdff
angelv#palas:~$ ./xy
0 12 24 36
*** SUCCESS writing example file simple_xy.nc!