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.
Related
I'm fairly new to programming in C. For my thesis I have to use the library "Libquantum" from the site http://www.libquantum.de/. I write my code in notepad and compile using the command window. I downloaded mingw and compile with gcc.
For normal C programs everything works fine. I use, for example, the command gcc -o HelloWorld HelloWorld.c and the program compiles fine. But I can't manage to compile programs where I use the library...
I downloaded the library and used the commands ./configure, make, ..., make install like they mentioned in the installation guide (https://github.com/jonbaer/libquantum/blob/master/INSTALL). After the last command the command window showed this:
I made sure to include #include <quantum.h> in the code and tried the linker flag -lquantum on different places when I try to compile but nothing works...
When I try to compile i get the following error
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lquantum
collect2.exe: error: ld returned 1 exit status
As the make install output says you need to tell the linker where the library is using a -L<path> option. The make install places the library in \usr\local\lib. If you are performing the build in MSYS, you can probably use -L\usr\local\lib, but if you have moved the file, change as necessary.
If you are building from cmd.exe (Windows's shell) rather than MSYS, you'll have to use its native a Windows path.
I am trying to compile a Matlab mex program that uses openmp on a mac. I would like to distribute this to other Matlab users so that they can use it, without them needing to install other software.
From what I can tell, xcode doesn't allow this, so I've installed gcc. I am able to compile the program fine, and run it locally, but it links to dependencies that are not available by default on a mac (I think). In particular, otool points to libgomp.1.dylib and libgcc_s.1.dylib, which from what I can tell, are not a part of the standard os installation.
I am able to link against libgomp.a statically, which from some testing (renaming the .dylib file) seems to have properly removed that dependency (i.e. the code still works when I rename the dylib file, and otool does not list it as well). However, I am unsure how to remove the libgcc_s.1.dylib dependency. In windows, copying the dll locally would fix the issue, but this doesn't work on a mac. I could not find a static library for that dependency. Instead, I am trying to get some version of rpath working (with a locally copied file), but otool consistently points to /usr/local/opt/gcc/lib/gcc/6/libgcc_s.1.dylib
The relevant parts of the Matlab command were:
'LDFLAGS="$LDFLAGS -fopenmp -Wl,-rpath,$ORIGIN/"' and
'-lgcc_s.1'
I found one solution here: Openmp with mex in Matlab on mac
However, for another project, I am using gcc specific commands so I'd really like to get this working with gcc.
So, I had some luck bypassing the mex compiling infrastructure and just passing the commands directly to gcc. To start, I ran what I currently had using the '-v' option to see the commands that Matlab was sending to the compiler. The 4 edits I then made were, 1) removed the crazy object output paths that Matlab creates (uses some temporary folder) 2) removed the reference to xcode 3) added a -L directive to the mex folder (although I will probably change this to the proper gcc directory - I'm just used to copying files locally to compile due to Matlab problems) and 4) added '-static-libgcc' (which I swear I had tried before ...) oh, and 5) I also updated the min osx version
This is the final line, the first two just had the -o options removed
/usr/local/Cellar/gcc/6.3.0_1/bin/gcc-6 -Wl,-twolevel_namespace -static-libgcc -L"/Users/jim/Documents/repos/matlab_git/matlab_sl_modules/plotBig_Matlab/+big_plot/private" -undefined error -arch x86_64 -mmacosx-version-min=10.12 -bundle -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/mexFunction.map" -fopenmp reduce_to_width_mex.o c_mexapi_version.o -O -Wl,-exported_symbols_list,"/Applications/MATLAB_R2017a.app/extern/lib/maci64/c_exportsmexfileversion.map" libgomp.a -L"/Applications/MATLAB_R2017a.app/bin/maci64" -lmx -lmex -lmat -lc++ -o reduce_to_width_mex.mexmaci64
Oh and finally I should mention I just ran these commands in the terminal, rather than in the Matlab command window ...
I installed MinGW on my Windows 8 laptop and tried to compile a C code file with
gcc test.c -o test.exe
the compiler gave no warnings or errors but it did not create test.exe
how do i get the compiler to create the file
test.c
My terminal session
An interesting observation:
When I deliberately introduce an error in the code and try to compile the compiler shows the error
Code with error
Compiler output
When I try compiling the same code using Command Prompt
This is what it shows
But the file does exist in the MinGW\bin directory
I moved the
test.c
file to
C:\
and started the command prompt in the
C:\MinGW\bin
directory
and here is what it outputs
Problem partially solved:
I disabled hybrid boot in windows 8 and restarted the computer. The compiler now works in Command Prompt but not in PowerShell.
Try to compile your code normally as
gcc test.c
If you get default output file a.exe,then go for
gcc test.c -o test.exe
I would suggest you go through this compilation instruction :-
gcc -o test.exe test.c
I believe this code runs perfectly on your windows system.Please inform if it doesn't!
I know this is an old question, but I came across this after having this same issue and managed to solve it.
When I installed MinGW on my computer, I didn't add the MinGW bin directory to my PATH (<mingw install dir>\bin). I had written some code that referred to the GNU compiler binaries by their full path, and when I tried to compile something I experienced the same behavior you described.
So it seems like MinGW won't work properly unless it is added to your PATH. I think it's weird that gcc didn't complain about it though.
One possibility is Microsoft's use of VirtualStore.
This can cause problems with "missing" files with Cygwin. See for example, Cygwin sees a file that windows can't--I want to access this file from python and https://superuser.com/questions/400600/file-only-visible-to-cygwin-not-windows.
To verify whether this is the case, try doing a search of your entire hard drive for the file test.exe. Or try MinGW's ls rather than dir.
And since the OP "partially solved" the problem by moving to another directory, this could be the cause.
I installed liblapack-dev and its dependencies using Synaptic, and I included <lapack.h> in my code.
If I try to compile my program like this...
mpicc program.c -llapack -o output
...I get the following error:
program.c:4:20: fatal error: lapack.h: No such file or directory
compilation terminated.
How can I fix this? I've already spent hours googling for a solution but nothing helped.
I'm using Linux Mint, but I tried the same thing on the latest version of Ubuntu and it still wouldn't work. Same thing when I try "eliminating" MPI from my program and compiling with gcc.
I experienced a similar issue on Debian. I noticed that
dpkg -L liblapack-dev
did not return a single header file. So I did some searching with apt-cache and found what appears to be C headers. After installing via
sudo apt-get install liblapacke-dev
(note the extra e!), I was able to compile a minimal working example, found here. Modifying the include at the top to read
#include <lapacke.h>
and compiling with
gcc -llapack lapack_example.c
successfully runs on my system. Hope this helps someone.
Answering because it doesn't fit in a comment:
The manual says:
Standard C language APIs for LAPACK
collaboration LAPACK and INTEL Math Kernel Library Team
LAPACK C INTERFACE is now included in the LAPACK package (in the lapacke directory)
LAPACKE User Guide
Updated: April 20, 2012
header files: lapacke.h, lapacke_config.h, lapacke_mangling.h, lapacke_utils.h
so perhaps you need to
#include <lapacke.h>
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.