Where is freeglut.a in cygwin? - c

I'm trying to implement a little OpenGL renderer in VSCode with cygwin's gcc, using freeglut as windowing system and I'm failing linking against freeglut. I have no clue what the library is called, according to what I found on the web, I should be able to link with -lfreeglut, but this gives me a the following:
/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lfreeglut
collect2: error: ld returned 1 exit status
I searched my cygwin folder for "glut" and found many things, but no library. Funny enough the headers are present. Btw, I installed the freeglut package (mingw64-x86_64-freeglut v 2.8.1-1) with cygwin's package installer. Also, I'm completely unexperienced in GNU systems, so the answer may be quite straightforward.

I think was never -lfreeglut but always -lglut
Try compiling with the normal GLUT library package
libglut-devel: OpenGL Utility Toolkit library
it includes the shared library
usr/lib/libglut.dll.a
both headers
usr/include/GL/freeglut.h
usr/include/GL/freeglut_ext.h
usr/include/GL/freeglut_std.h
usr/include/GL/freeglut_ucall.h
usr/include/GL/glut.h
In general you can use cygcheck for finding the needed package.
$ cygcheck -p libglut.dll.a
Found 5 matches for libglut.dll.a
libglut-devel-2.8.1-1 - libglut-devel: OpenGL Utility Toolkit librar
y (installed binaries and support files)
libglut-devel-3.0.0-1 - libglut-devel: OpenGL Utility Toolkit librar
y
libglut-devel-3.2.1-1 - libglut-devel: OpenGL Utility Toolkit librar
y
...

Related

Missing libgcc_s_dw2-1.dll

I have a Windows 7 64bit system with the latest MinGW (32bit) installed along with the Qt 5.5 SDK (again 32bit) which also ships with its own MinGW. Due to the fact that I'm not the only one using the system I can't remove the standalone MinGW.
My project is using qmake and is a plain C project (not C++). Everything builds fine but when I try to execute my binary in the command line I get that the application was unable to start due to a missing libgcc_s_dw2-1.dll on the system.
After looking into the issue I found that both the standalone MinGW and the one shipped alongside the Qt SDK have the mentioned DLL.
Standalone MinGW - libgcc_s_dw2-1.dll is located inside the bin subdirectory of the MinGW installation where the binaries are located (gcc, g++, gdb etc.)
Qt MinGW - libgcc_s_dw2-1.dll is located inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\lib subdirectory while the MinGW components' binaries are inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\bin.
I would like to know how to properly set my PATH variable so that:
The application starts properly
No conflicts with the standalone MinGW installation occur
Just a side-note: I've already checked other posts here on SO but was unable to find a solution (perhaps I've missed it). I have also tried LIBS += -static but the result is the same.
You just need to copy this dll with your executable, i.e.:
cp <path-to-qt-install-dir>\qt5.7.0\5.7\mingw53_32\bin\libgcc_s_dw2-1.dll <path-to-dest-dir>
You mat find that you have other dependencies, to see which other deps you have you can use: ldd <your-executable>. You only need to copy the qt specific dlls you can see these by:
ldd <executable> | grep -i qt
note
You can statically link it with:
linker commands like -static-libgcc or -static, but I think you start to hit LGPL issues and also you may need to statically compile qt from source - can't recall for this particular file.
note2
Sorry ldd is for linux, just realized you have windows, in which case you can use one or both of:
dependency walker: from here
<path-to-qt-bin-folder>\windeployqt.exe <path-to-your-executable>
I have mixed results with windeployqt, but if you have any plugins its quiet good for getting that part sorted.

arm-linux-gnueabi-gcc does not find library

I'm trying to compile a c program in the paparazzi autopilot environment with OpenGL ES support for an ARM Mali GPU. I've compiled the libGLESv2 libraries from the Mali SDK, and everything worked fine. Now I'm trying to get the cross-compiler to find such libraries, but it says:
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lGLESv2
I tried to add the -v option to check the library path and it says:
LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabi/5/:/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/lib/../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/lib/:/lib/:/usr/lib/
I've placed the libGLESv2.so library in the first of such directories but still it doesn't work. What do you suggest?
Thanks,
Davide
You can try the solution from here
add "link_directories(/home/davide/Scaricati/Mali_OpenGL_ES_SDK_v2.4.4/lib/arm)" in CMakeLists.txt

How do I use "unity" to unit test C code on Mac (Lion)?

Let me start out by saying that I'm not a C developer and I know very little about actually writing real world C code. I've been doing some research to find a xUnit framework that I can use to write tests for C code and based on what I've found it seems like Unity is the one that I want to go with. It seems simple enough, but I really just don't know what to do after I download the zip file from Unity's website. It doesn't seem to have the normal configure/make/make install, and if it did, I'm not sure that is what I should be using anyway. It does, however, ship with some rake tasks, but none of those seemed to be any kind of "install" task. As a last resort I tried to just copy the 3 source files in with my code (which I really hope is not the right thing to do), but when I try that I get an error trying to compile my c file with gcc, but I think this should be working. Here is my set up:
src/
mycode.c
unity.c
unity.h
unity_internals.h
Here is the source for mycode.c
/* mycode.c */
#include "unity.h"
void test_sample(void)
{
TEST_ASSERT_EQUAL_INT(0, 0);
}
When I run gcc mycode.c I get:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"_UnityAssertEqualNumber", referenced from:
_test_sample in ccyHByv6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(I get a similar error when I try to compile unity.c with gcc). Which I assume means that the code that ships with unity requires a different compiler than what I have which is:
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
or that maybe unity is not compatible with a 64 bit processor... (I'm running on Mac OS 10.7.3 with a 2.4 GHz Intel Core 2 Duo processor - another thing that may or may not be relavent is that I've got XCode Version 4.3 (4E109) and also Command Line Tools for XCode) At this point I'm just grasping at straws and I'm in way over my head.
My question is, what is the correct process to go through to take a 3rd party C library, such as Unity, and make it available to my C code? Do I need to install something like in Python or Ruby or add something to my path like in Java or something else? Shouldn't just dropping unity's code in with mine work? Am I doing something wrong or is Unity or both? I really just want to be able to test drive C code using Unity. Any help would be greatly appreciated. Thanks in advance!
First, try 'gcc *.c -o mytest'. This will compile all of the C source files into object files, and then link them together into the binary 'mytest'. Keep in mind that all C source files have to be compiled to object files before they can be linked together. (A library is just a bunch of packaged object files.)
If you had a unity library installed in /usr/lib, you could do something like 'gcc mycode.c -lunity -o mytest'. If you had a unity library sitting in the current directory, you might do 'gcc mycode.c ./unity.a -o mytest'. This tells the compiler to look for a file named 'unity.a' in the current directory. Some libraries build .so files ('shared object' files, similar to DLLs in Windows). Replacing 'unity.a' with 'unity.so' should work if that is the case. (I'm assuming a Unix/Linux environment here.)
As an alternative to Unity, look at Google Test, which can be used with C code. I know it is supported on the Mac as well. The primary benefit is a large and active community. More information on Google Test from another SO question: Is Google Test OK for testing C code?
I figured out my problem. It turns out that unity requires you to define a setup and a teardown function and if you do not, you will get errors similar to the one that I was running into.

Link with SDL and OpenGL under Ubuntu

I want to write a simple SDL OpenGL app, Codeblocks is the IDE I use.
When I create a new OpenGL project, it compiles fine, but if I try to use a function from the SDL header, le wild "undefined reference error" occurs. The same goes for the other direction, if I create a new SDL project, I can use the SDL functions without problems but I get a "undefined reference error" for the OpenGL functions...
NOTES:
I Use Ubuntu 11.10
I have installed the SDL and the OpenGL packages
You need to add the correct library. Headers just give the compiler sort of a index. But you need to tell the linker which libraries to actually pull in. You should find the linker options at the build settings. You need the following libraries for SDL + OpenGL
libGL.so ( -lGL linker switch )
libSDL.so ( -lSDL linker switch)
You may also require libGLU.so if you're using glu… functions.
Asking pkg-config is the preferable thing for obtain the particular flags and options needed for compilation and linkage against SDL and Mesa's GL+GLU. (Some GL implemenetations may not be shipping .pc files, but they should still be used where available.)

How can I mimic the GNU/linux C development environment on OSX Lion?

I just tried to write a simple C program on OSX Lion
#include <stdio.h>
int main() {
printf("hello world\n");
return 0;
}
Compiling with gcc
$ gcc hello.c
test.c:1:19: error: stdio.h: No such file or directory
test.c: In function ‘main’:
test.c:3: warning: incompatible implicit declaration of built-in function ‘printf’
Ok...fine
$ gcc -I /Developer/SDKs/MacOSX10.6.sdk/usr/include
ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
What? Let's see...
$ gcc -I /Developer/SDKs/MacOSX10.6.sdk/usr/include -L/Developer/SDKs/MacOSX10.6.sdk/usr/lib test.c
$ ./a.out
hello world
Finally!
That seems like a lot of effort just to get a hello world working, how do I make gcc find libraries and header files in the MacOSX10.6.sdk directory by default like it does on linux? On linux I find ldd and ldconfig quite useful, they don't seem to exist on OSX...is there an equivalent? What other useful tools are there for developing C on OSX?
Yes, I know xcode makes this easier, but suppose I wanted to use vim and the command line to work on an opensource c project.
I can think of three possibilities:
You had 10.6 installed and upgraded to 10.7. You need to install the new version of Xcode (4.1, get it from the app store) to get back the developer tools.
you installed Xcode, did a custom install, and unchecked "UNIX development" or something. Rerun the installer and install the missing parts.
You installed a broken third-party version of gcc. Try which gcc and see what you get.
On OS X 10.7, if you have downloaded Xcode 4.1 from the Mac App Store and then run the installer that it downloads (in /Applications), your first attempt should have worked just fine assuming you have not set some environment variables that are looked at and influence Apple's gcc tool chain. The object file that is produced in this case would be using the default 10.7 ABI (include files and libs). If you want to produce something that would be compatible with OS X 10.6, then you need to tell the tool chain to use the 10.6 SDK ABI, which is what you did in the third attempt. A standalone project typically handles this by setting up a Makefile to automate building. But, unless you are trying to build something on a version of OS X (10.7 here) that will also run on earlier versions of OS X (say 10.6), there is generally no need to use an SDK.

Resources