Author Topic: code::blocks not linking to *.a file  (Read 3391 times)

Offline cluelessnoob

  • Multiple posting newcomer
  • *
  • Posts: 18
code::blocks not linking to *.a file
« on: July 09, 2022, 06:51:05 pm »
I am trying to write a program using the Enet library and running into problems. When I put the enet .dll file into the file with the executable, the program runs fine but when I try linking to the static (.a) file, I get an error "The code execution cannot proceed because libenet.dll was not found. Reinstalling the program may fix this problem.". I've checked my search directories, the libenet.a was present, the file name was spelled properly. I also tried using the absolute path to the file, the linker is still looking for the enet.dll file. I checked the compiler settings, the -static option is selected. Is there another setting I should be looking for or is the enet.a file corrupted somehow?

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3352
Re: code::blocks not linking to *.a file
« Reply #1 on: July 09, 2022, 11:23:16 pm »

Offline gd_on

  • Lives here!
  • ****
  • Posts: 800
Re: code::blocks not linking to *.a file
« Reply #2 on: July 10, 2022, 12:05:15 am »
Are you sure that your .a file is a static library? and does not only contain references to the content of the dll.
I think it's the case if you use enet_dll.cbp included in enet-1.3.17 distribution.
« Last Edit: July 10, 2022, 10:39:13 am by gd_on »
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.5 (tests with 3.3), Msys2 Compilers 14.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline cluelessnoob

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: code::blocks not linking to *.a file
« Reply #3 on: July 10, 2022, 01:43:25 pm »
Thanks for the replies. Here is a copy of the build log:


-------------- Build: Debug in Enet Server (compiler: GNU GCC Compiler)---------------

gcc.exe -Wall -g -IC:\Users\abk45\OneDrive\Documents\Mingw\winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64-9.0.0-r3\mingw64\include -IC:\Allegro5\Allegro5271GIT_2021-12-12_x86_64-w64-mingw32_gcc11.2_posix_seh\Allegro5271GIT_2021-12-12\include -IC:\Allegro5\Allegro5271GIT_2021-12-12_x86_64-w64-mingw32_gcc11.2_posix_seh\Allegro5271GIT_2021-12-12\include\allegro5 -IC:\Users\abk45\Documents\enet-1.3.17\enet-1.3.17 -I"C:\Users\abk45\OneDrive\Documents\Enet Server" -c "C:\Users\abk45\OneDrive\Documents\Enet Server\main.c" -o obj\Debug\main.o
gcc.exe -LC:\Users\abk45\OneDrive\Documents\Mingw\winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64-9.0.0-r3\mingw64\lib -LC:\Users\abk45\OneDrive\Documents\Mingw\winlibs-x86_64-posix-seh-gcc-11.2.0-mingw-w64-9.0.0-r3\mingw64\x86_64-w64-mingw32\lib -LC:\Allegro5\Allegro5271GIT_2021-12-12_x86_64-w64-mingw32_gcc11.2_posix_seh\Allegro5271GIT_2021-12-12\lib -LC:\Users\abk45\Documents\enet-1.3.17\enet-1.3.17\bin\Debug -o "bin\Debug\Enet Server.exe" obj\Debug\main.o  -static-libstdc++ -static-libgcc -static  -lallegro_monolith-debug-static -lallegro_monolith-static -ljpeg -ldumb -lwebp -lFLAC -ltheora -lvorbisfile -lvorbis -logg -lphysfs -lfreetype -lpng16 -lzlibstatic -lopenal32 -ldsound -lgdiplus -luuid -lkernel32 -lwinmm -lpsapi -lopengl32 -lglu32 -luser32 -lcomdlg32 -lgdi32 -lshell32 -lole32 -ladvapi32 -lws2_32 -lshlwapi -lpthread -lstdc++ -lgcc -liphlpapi -lenet
Output file is bin\Debug\Enet Server.exe with size 102.75 KB
Process terminated with status 0 (0 minute(s), 33 second(s))
0 error(s), 0 warning(s) (0 minute(s), 33 second(s))

There is a code::blocks project to build the library included in the download. I ran it and found the libenet.a file in the folder with the .dll and am assuming that is the static library. This is on windows 10 btw.
 

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3352
Re: code::blocks not linking to *.a file
« Reply #4 on: July 10, 2022, 02:21:00 pm »
If you use the provided .cbp file to build, you get a dynamic library. The .a file references only to the .dll file.
Now, to link it statically you have multiple options:

1) Compile enet to static libraray with codeblocks:
1.1) Open the provided project
1.2) Go to Project->Properties->Build targets-> change "Type" from "dynamic library" to "static libraray" for release and debug target (on the left)
1.3) Close the dialog with ok and rebuild the project with Build->Rebuild
the new .a file should have something about 120kB

2) Use the provieded .lib file with your project: https://stackoverflow.com/questions/7241047/linking-lib-files-with-mingw
2.1) Open your project
2.2) Project->Build options->select your project on the left
2.3) linker settings->library remove the enet and provide the full name of the lib, or follow the naming convetntions described in the stack overflow thread

Offline cluelessnoob

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: code::blocks not linking to *.a file
« Reply #5 on: July 10, 2022, 11:30:27 pm »
Getting closer. I followed these instructions:

1) Compile enet to static libraray with codeblocks:
1.1) Open the provided project
1.2) Go to Project->Properties->Build targets-> change "Type" from "dynamic library" to "static libraray" for release and debug target (on the left)
1.3) Close the dialog with ok and rebuild the project with Build->Rebuild
the new .a file should have something about 120kB

but I get errors when building a program to test (attached). I've added the winsock2.h header to the project for fun, no help.



Offline sodev

  • Lives here!
  • ****
  • Posts: 500
Re: code::blocks not linking to *.a file
« Reply #6 on: July 11, 2022, 03:10:05 pm »
On GCC, static library link order does matter, you have to specify libraries in the order from dependent to independent. At least you have to move the Enet library before the platform libraries, especially before ws2_32, which is the reason for your current linker errors.

Offline cluelessnoob

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: code::blocks not linking to *.a file
« Reply #7 on: July 11, 2022, 11:26:36 pm »
That worked. Thanks.