I am trying to compile a program which includes the graphics.h header file for C. I have added the graphics.h and winbgim.h header files in the include folder and also libbgi.a to lib folder.
Just for testing, I made a simple hello world program and included the graphics.h header file.
But on compiling I got the following error:
In file included from firstc.c:2:0:
c:\mingw\bin../lib/gcc/mingw32/4.7.1/../../../../include/graphics.h:30:59:
fatal error: sstream: No such file or directory compilation
terminated.
I tried to search in other forums as well, where the same question had been asked, but could not get an answer.
Another question, I came across other graphic options for C and C++ like openGL and DirectX. Should I learn these instead of graphics.h?
graphics.h is a non-standard header. Most likely it refers to the old BGI graphics library of the Turbo C DOS compiler. It will only work on that particular compiler. And of course DOS is a completely obsolete OS nowadays.
If you are interested in 3D graphics programming, then OpenGL and/or DirectX are indeed better, modern alternatives, supported by many compilers.
If you try to compile the source code with including “graphics.h” in code::blocks IDE you have to setup winBGIm library.
Download WinBGIm from http://winbgim.codecutter.org/ or use (direct link)
Extract it.
Open graphics.h, go to line 302 change int right=0 to int top=0
Copy graphics.h and winbgim.h files in include folder of your compiler directory.
Copy libbgi.a to lib folder of your compiler directory
In code::blocks open Settings >> Compiler and debugger >> linker settings
Click Add button in link libraries part, browse and select libbgi.a file
In right part (ie. other linker options) paste commands
-lbgi -lgdi32 -lcomdlg32 -luuid -loleaut32 -lole32
Click Ok
You can also check this video tutorial.
When you're compiling a C source code having graphics.h header file, you'll need to change the file extension to .cpp. Without doing that, you'll get “fatal error: sstream : no such file directory” error.
So, simply change the .c extension to .cpp. Here's a step-by-step procedure to compiling graphics.h source code if you're using Code::Blocks to run the code.
The sstream error occurs only when you are compiling using gcc not g++ , try using g++ or converting the program to c++ , as far as i know ( since i'm new to this language but i've faced this error before ) so goodluck with that
If top answer doesn't work, and you are getting:
error: narrowing conversion of 'x' from 'int' to 'short unsigned int'
your graphics window just doesn't appear
following this tutorial and using the bug fixed headers/libraries (winBGIm(bug-free).rar) in the provided winBGIm source link, worked for me in Windows 10.
Mirror to winBGIm(bug-free_.rar)
compiling with: g++ example.cpp -Wall -m32 -std=c++11 -pedantic -g -lbgi -lgdi32 -lcomdlg32 -luuid -loleaut32 -lole32 -o example.exe
Related
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 have a JNI project, which I have to make work on Windows (I am working on Linux). This project actually depends on third-party library file which is static (archived i.e .a files). I am trying to create a JNI shared library file using i686-w64-mingw32-g++ and including -static followed by static third-party library name. Following is the command I am using
i686-w64-mingw32-g++ -v -L./ -L/home/user/jre1.8.0_40/lib/amd64/ -I/user/all/apps/Linux2/x86_64/gcc/4.8.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include -shared -o test.dll test.cpp -lstdc++ -static -thirdparty
In-spite of placing the third party library in the current working directory, I keep getting error
/user/all/apps/Linux2/src/mxe/2013_12_03/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64-mingw32/bin/ld: cannot find -thirdparty
Please note : I included -I/user/all/apps/Linux2/x86_64/gcc/4.8.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include to avoid the error cannot find jni.h which I hit before including the path.
I also tried to compile using gcc, in place of g++.
Do I need to create .dll of this third-party library(currently it is archived .a containing .obj files)?
Being a newbie in cross compilers, I might be doing something wrong. Please correct me and any suggestions with this will be very helpful. Thank you.
-Wl,--export-all-symbols -Wl,--add-stdcall-alias -v adding this solved my problem
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 want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.
I am trying to run someone else's (4 year old) code from sourceforge. I downloaded cygwin and checked out the project with CVS.
Here is the compile line which is failing:
gcc ../block_display/block_display.c -o block_display -lopengl32 -lglut32 -lm
Here is the relevant include statement in block_display.c:
#include <GL/glut.h>
When I try to run the above compile line, I get this compile error:
$ gcc ../block_display/block_display.c -o block_display -lopengl32 -lglut32 -lm
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lglut32
collect2: ld returned 1 exit status
I admit I am new/rusty with cygwin. I tried a few things to get to this point, but since I don't entirely know where to put files, I am stuck on this error. Here is what I have tried:
Downloading all results for 'glut' in cygwin setup: libglut-devel, freeglut, libglut3
Downloading glut 3.7.6, copying glut32.dll to C:\Windows\SysWOW64, and copying glut.h to C:\cygwin\usr\include. I still have glut.def and glut32.lib sitting around, but I do not know exactly where to place them. I tried following this install guide, but since I am not running VC++, I do not know what the cygwin equivalent of VC++ path is.
Any idea what I could do to get this code to compile successfully? I am running Windows 7 64-bit.
You should use freeglut instead. The original glut is far outdated. Freeglut on the other hand is binary and source compatible with the original glut, and it's also open source.
Since glut32.dll is a windows DLL and cygwin is for emulating a unix environment on windows, you can't easily use the original glut with cygwin without recompiling from source.