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.
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.
Im working on a program for my studies, that uses an open source library. It is meant to run on Raspberry Pi (Raspbian Kernel). Because of my intention to be also able to load it on a PLC i used mostly pure C. The Library itself comes with suitable header and .c files.
When i use the pre installed GCC compiler on the Raspberry my program compiles without any errors and works fine. Now here comes my problem:
I tried to get this projekt to work on windows using code::blocks IDE with MinGW installed. I revisited the library and downloaded the zip for windows (apperently same header and .c file, but also .lib and .dll included).
I set the search directories and linker settings within the project and included the header as usual with #include "header.h" for the relative path. It doesn't compile and gives alot multible definition and first defined here which usually indicate wrong linking and inclusion.
As i tried to identify some of this definitions i noticed that the functions which cause errors are defined one time in the library.c file. At the beginning of this .c file it also includes the header one time.
Short summary:
This works with raspbian GCC:
$ gcc -sdt=c99 main.c library.c -o executable
but gives errors with Windows IDE + MinGW
Am i missing something serious? The dynamic link lib should only be used by the executable afterwards. I thought maybe the libraby.c gets replaced by the library.lib but if i remove one of them the project doesn't know the functions. I also searched for wrong inclusions. I'm really at the end of my knowledge here, and also searched for posts that would help me, but those were mostly "where is the linker path" or "inclusion of .c files". It seems so an simple problem which i overlooked.
Any help Would be appriciated. I will supply more details if needed.
Thanks!
Edit (2):
obj\Debug\open62541.o:open62541.c:(.text+0x3152a): undefined reference to `__imp_shutdown'
obj\Debug\open62541.o:open62541.c:(.text+0x3153f): undefined reference to `__imp_closesocket'
obj\Debug\open62541.o:open62541.c:(.text+0x315a7): undefined reference to `__imp_send'
obj\Debug\open62541.o:open62541.c:(.text+0x315b9): undefined reference to `__imp_WSAGetLastError'
.....
Edit (3)
Answer 1!
Compiled good now, thanks everyone.
It looks like your library is open62541.
There are two ways to include the library in your source:
Build a shared/static lib and link it to your code
Enable Amalgamation which generates a single .c and .h file which you can directly compile with your code
You are combining both methods on mingw which adds the whole library two times.
Probably you only want to link the .c file without the .lib, thus your compile command should look something like this:
gcc -sdt=c99 main.c open62541.c -o test
Additionally, since open62541 needs the ws2_32 library on windows, the compiler should be called with:
gcc -std=c99 main.c open62541.c -o test -lws2_32
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.
I am trying to modify the source code to an open source application on windows that uses mingw.
I am having a problem linking the psapi library.
psapi.h and libpsapi.a are in the mingw directory and I have tested it using the standard
gcc -o program program.c -lpsapi
method, and it works.
However, when I try to compile the program using the
./configure
make
method, it doesn't work I have tried,
./configure LDFLAGS=-lpsapi
make
and that doesn't work
and I tried going into the makefile.am and putting -lpsapi in AM_LDFLAGS but that doesn't work
The error it gives is just a standard "undefined reference to [function]", implying that the library with the functions is not linked
I have even tried putting psapi.h in the source directory and including it as #include "psapi.h" and that STILL didn't work.
LDFLAGS is the wrong one.
LIBS=-lpsapi should do the trick.
The order is important for the linker. The libraries (LIBS) have to come after the objects, LDFLAGS can be before.
I am getting linking error when I try to compile a test code.
I'm using cygwin on windows 7.
Initial steps like ./configure, make, make test & make install went fine
I'm also able to generate .pb.cc and .pb.h with protoc command.
But when I try to compile my test code, it gets many linking errors. I'm sure those errors are because it is unable to link to library.
Cygwin has protobuf static library and linking library in /usr/local/lib
. include files are present in /usr/local/include
I tried with -lprotobuf, but it returns error saying -lprotobuf not found
It hard to say what the problem is since you don't include neither the makefile nor the errors, but my guess is that the path /usr/local/lib is not included in the search path when looking for libraries.
Try adding -L/usr/local/lib before -lprotobuf.