I am using OpenSSL-Win32 library on an x86_64 win7 machine, with MinGW gcc compiler. I am linking the libeay32.a and ssleay32.a statically to my program. No warning or error code is generated.
However, after the compiling and linking, the executable file exit with
The application was unable to start correctly, 0xc0000013
I checked my destination executable with dependency walker and it shows
C:\windows\system32\libeay32.lib
is linked to my program! Then I renamed that file to something like ~libeay32.lib and, without recompile my program and reopen it with dependency walker, now
c:\python27\lib\site-packages\pyqt4\LIBEAY32.DLL
is linked to the program. Clearly static library libeay32.a is not working and my program is dynamically searching for the library.
Related
I've tried compiling an SDL2 program on windows using mingw gcc in Code::Blocks, but the only way I can get the produced binary to work is by stripping the symbols with the -s option. Even with just a simple printf program, but only when SDL.h is included.
What is going wrong and how can I fix it?
Produced output differs depending on how the binary is run.
Using the terminal I get:
Program 'main.exe' failed to run: The specified executable is not a valid application for this OS platform
Using Code::Blocks to build and run, the produced binary runs, but without any output and exits immediately with:
Process terminated with status 32760
Looking up the status code produces no results, both in mingw and SDL2.
Trying to compile with -static causes a bunch of output with ld returned 1 exit status and Dwarf Error: Can't find .debug_ranges section.
This seems to imply that debug info is missing from the linked dll file as I understand it.
SDL2 is included and linked from the extracted SDL2-devel-2.24.0-mingw folder from the libsdl github releases.
The same errors can be reproduced by creating a SDL2 project with Code::Blocks and compiling the given code in debug and release, since only the release strips the symbols it runs fine, but the debug build does not. Enabling the -s option in debug produces a working binary.
Edit: Compiling SDL2 from source seems to have fixed the issue, so this seems to only be a problem with the precompiled binaries downloaded from the release page. I'm assuming it was because of the missing debug symbols, but it would be appreciated if anyone can confirm that this was the case and explain why stripping symbols creates a working binary?
Edit 2: The main problem seems to be with the outdated mingw compiler included with Code::Blocks which is on version 8.1.0. Using a more recent version of mingw64 such as 12.2.0 from mingw-w64 also fixes the issue.
I added to Visual studio Project->Properties->Linker->Input->Additional Dependencies the x.lib file. My build was successful but program didnt start because after start it wrotes: The program cant start because of x.dll is missing from your computer. Why is it looking for x.dll and not x.lib?
For dynamic linking:
x.lib is used for compiling, which contains the linking information of library functions. When compiling, compiler just check whether these functions exist. To understand it simply, compiling will give the way to locating these functions in dll files.
While x.dll is dynamic link library which contains the implementations (maybe not that accurate) of these functions. If you didn't set dll right, the program cannot execute the corresponding functions. dll is the actually executable file, not lib.
I'm trying to statically link glib into my C program. I'm not sure what's the best way to do this. I downloaded the code and put it in a subdirectory called glib-2.36.4. I added "-Iglib-2.36.4" when using gcc. The glib.h is in the glib-2.36.4/glib directory and in that file there are references to other header files under the glib directory (such as #include ).
I'm not sure why that is since both glib.h and these other header files are at the same level (in glib subdirectory). I got a compile error due to galloca.h not being found (even though it's there). So I copied glib.h up one level and those errors went away. I then got an error about a missing glibconfig.h. I copied that from my usr directory and that error went away. I compiled my project and now I'm getting an error about undefined reference to g_ptr_array_new. I guess this must be because I haven't actually compiled glib. I had tried to build glib, but when I typed "./configure", but I got this message:
checking if arpa/nameser_compat.h is needed... configure: error: could not compile test program either way
I did install glib using yum, but I really want this code to run even if glib is not installed on a machine.
You need to install both glib and glib-dev via yum, compile using ./configure, (take a look in the ./configure script to see if there are any flags you need to supply or defines you need to produce the static build), without moving any files about, and then you need to compile your code using -i path/to/glib/includes and link with -L path/to/built/static/library
In the process of porting a C project from Linux to Windows
Have installed MinGW
Have compiled my shared library using a Makefile
This produces libExample.so
Now I'm trying to link this shared library to a test harness so I can see if everything is working as expected
In the harness Makefile I specify the location of the library, e.g. -LE:/libExample_dir and the name of the library -lExample
but its complaining it cannot find the library, i.e. linker is failing with cannot find -lExample - is there some difference with windows regarding .so and .dll or perhaps pathnames that I am missing?
You need to fix the make file so shared libraries are generated with a .dll extension.
If I had to guess, I'd say that while renaming the generated file is enough to make the linker happy, the loader still expects the .so extension because that's the name that was compiled in...
Using MinGw to compile C code to produce a shared library, remember to rename the output from libExample.so to libExample.dll otherwise the linker will fail to find your library
I've been trying to link glew to my c++ CodeLite project on Windows with little success. First I used MinGW to compile the glew source into libglew32.a and glew32.dll. These are inside C:/glew-1.6.0/lib.
Inside the project settings, the include path in the compiler tab is C:/glew-1.6.0/include and inside the linker tab I have C:/glew-1.6.0/lib under the library paths. For the linker options I have -lglew.
At this point I haven't even included glew inside main.cpp or written any code relating to glew. But when I run the program it gets stuck, leaving me the single output message: "Running program: ./TestProgram" while nothing happens.
When I remove the -lglew flag from the linker options, the program runs fine. Something seems to be wrong with how I've linked glew, but I don't know what.