I am getting a linker error building a simple project using scons. The example commands show integrated compiling and linking of program binaries, which scons does not do (though I probably could force it to, I'd rather not if possible).
This command works fine:
gcc -o main.exe main.cpp C:\raylib\raylib\src\raylib.rc.data -s -static -Os -IC:\raylib\raylib\src -DPLATFORM_DESKTOP -lraylib -lopengl32 -lgdi32 -lwinmm
Whereas these two fail:
g++ -o main.o -c -DPLATFORM_DESKTOP -Os -static -IC:\raylib\raylib\src main.cpp
ld -o mains.exe c:\raylib\raylib\src\raylib.rc.data -s -static main.o -LC:\raylib\raylib\src -lraylib -lopengl32 -lgdi32 -lwinmm
Resulting in:
c:\raylib\w64devkit\bin\ld: cannot find -lopengl32
c:\raylib\w64devkit\bin\ld: cannot find -lgdi32
c:\raylib\w64devkit\bin\ld: cannot find -lwinmm
Any insights? I'm not particularly familiar with the .rc.data files.
I would try to get gcc's library search path:
]$ gcc -x cpp-output -E -v /dev/null 2>&1 | grep LIBRARY_PATH | sed 's/:/\n/g'
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/11/
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/
/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib/
/lib/x86_64-linux-gnu/
/lib/../lib/
/usr/lib/x86_64-linux-gnu/
/usr/lib/../lib/
/usr/lib/gcc/x86_64-linux-gnu/11/../../../
/lib/
/usr/lib/
see if the missing libraries are in any of those directories, and if they are then add them to the ld invocation as -L<path> option.
EDIT
To see ld search path when it is called on its own, I think this should work:
]$ ld --verbose | grep SEARCH_DIR | sed 's/;/\n/g'
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu64")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
When you eliminate duplicates you'll notice that /usr/lib/gcc/x86_64-linux-gnu/11/ is an additional directory that is being searched when linking with gcc (your first command) but not when linking directly with ld.
But that's on my machine. On yours it will probably be a bit different.
Related
I'm running make and ld will not find libraries that I have verified to exist using dnf provides '*/libpthread.so' for example. I get the following error code:
g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o
/bin/ld: cannot find -lpthread
/bin/ld: cannot find -lm
/bin/ld: cannot find -ldl
/bin/ld: cannot find -lpthread
/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: bayescan_2.1] Error 1
These libraries all are found in /usr/lib64 on my chair's computing cluster. However the ld.so.conf file does not include a path that only goes to /usr/lib64 and I don't have admin permissions to create a new .conf file in /etc/ld.so.conf.d/.
Is there any way I can force make to search for the libraries in /usr/lib64?
Here is the actual Makefile in question:
# BayeScan makefile
bayescan_2.1: start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o
g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o
start.o: start.cpp errors.cpp anyoption.h global_defs.h
g++ -fopenmp -c start.cpp errors.cpp
beta.o: beta.cpp global_defs.h
g++ -fopenmp -c beta.cpp
dirichlet.o: dirichlet.cpp global_defs.h
g++ -fopenmp -c dirichlet.cpp
RJupdates.o: RJupdates.cpp global_defs.h
g++ -fopenmp -c RJupdates.cpp
MHupdates.o: MHupdates.cpp global_defs.h
g++ -fopenmp -c MHupdates.cpp
likelihood.o: likelihood.cpp global_defs.h
g++ -fopenmp -c likelihood.cpp
read_write.o: read_write.cpp errors.cpp global_defs.h
g++ -fopenmp -c read_write.cpp errors.cpp
anyoption.o: anyoption.cpp anyoption.h
g++ -fopenmp -c anyoption.cpp
clean:
rm *.o bayescan_2.1
EDIT:
Turns out ld was trying to find static libraries with the -static flag. Removing this flag from the Makefile fixed the issue.
Simply add -L/usr/lib64 to the link command. See Directory Options in the GCC manual:
-Ldir
Add directory dir to the list of directories to be searched for -l.
If you can't or don't want to edit the Makefile, you can supply additional search directories through an environment variable
LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cannot find them using GCC_EXEC_PREFIX. Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first).
For example, run this in your shell before invoking make:
$ export LIBRARY_PATH="$LIBRARY_PATH:/usr/lib64"
I'm trying to build Open CASCADE (6.7.1) library with 64bit mingw on Windows 7 (I am using x86_64-4.9.1-release-posix-seh-rt_v3-rev1 from mingw-w64 project).
When it comes to linking, it fails with an error and I have no idea what could be wrong. The linker command generated by cmake is:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E remove -f CMakeFiles\TKernel.dir/objects.a
C:\msys64\mingw64\bin\ar.exe cr CMakeFiles\TKernel.dir/objects.a #CMakeFiles\TKernel.dir\objects1.rsp
C:\msys64\mingw64\bin\g++.exe -shared -o ..\out\bin\libTKernel.dll -Wl,--out-implib,..\out\lib\libTKernel.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles\TKernel.dir/objects.a -Wl,--no-whole-archive -LC:\msys64\home\user\tcl8.5.16\build -LC:\msys64\home\user\freetype-2.5.3 -ladvapi32 -lgdi32 -luser32 -lkernel32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
And the produced error:
Linking CXX shared library ..\out\bin\libTKernel.dll
CMakeFiles\TKernel.dir/objects.a: member CMakeFiles\TKernel.dir/objects.a(FSD_BinaryFile.cxx.obj) in archive is not an object
collect2.exe: error: ld returned 1 exit status
TKernel\CMakeFiles\TKernel.dir\build.make:11422: recipe for target 'out/bin/libTKernel.dll' failed
This is how the files are compiled:
Building CXX object TKernel/CMakeFiles/TKernel.dir/__/__/src/FSD/FSD_BinaryFile.cxx.obj
cd /d TKernel && C:\msys64\mingw64\bin\g++.exe -DCSFDB -DTKernel_EXPORTS -DWNT -D_OCC64 -D_SCL_SECURE_NO_WARNINGS -MP -Wall -O3 -DNDEBUG -DNo_Exception #CMakeFiles/TKernel.dir/includes_CXX.rsp -MM -D__FSD_DLL -D__MMgt_DLL -D__OSD_DLL -D__Plugin_DLL -D__Quantity_DLL -D__Resource_DLL -D__SortTools_DLL -D__Standard_DLL -D__StdFail_DLL -D__Storage_DLL -D__TColStd_DLL -D__TCollection_DLL -D__TShort_DLL -D__Units_DLL -D__UnitsAPI_DLL -D__IncludeLibrary_DLL -D__Dico_DLL -D__NCollection_DLL -D__Message_DLL -o CMakeFiles\TKernel.dir\__\__\src\FSD\FSD_BinaryFile.cxx.obj -c ..\..\src\FSD\FSD_BinaryFile.cxx
If I check the objects.a file with nm, the contents are .obj, but "File format not recognized" doesn't look good... but don't know what exactly does that mean...
$ nm objects.a
C:\msys64\mingw64\x86_64-w64-mingw32\bin\nm.exe: FSD_BinaryFile.cxx.obj: File format not recognized
C:\msys64\mingw64\x86_64-w64-mingw32\bin\nm.exe: FSD_CmpFile.cxx.obj: File format not recognized
...
Output from file command:
$ file objects.a
objects.a: current ar archive
$ file __/__/src/FSD/FSD_BinaryFile.cxx.obj
__/__/src/FSD/FSD_BinaryFile.cxx.obj: ASCII text, with CRLF line terminators
I also tried to remove the --whole-archive option from the linker command, but that leads to another error:
Linking CXX shared library ..\out\bin\libTKernel.dll
CMakeFiles\TKernel.dir/objects.a: error adding symbols: Archive has no index; run ranlib to add one
collect2.exe: error: ld returned 1 exit status
If I run ranlib on the file, it doesn't help.
Any ideas are appreciated.
edit: Ok, so I guess that the problem is caused by -MM flag, that was used for the build. So it didn't really compile the files, if I understand it correctly.
However I found OCE project, which is some sort of community edition of OCC and it is quite mingw-ready, so I'm gonna use that version and see how it goes...
I am compiling a C++ application using GNU g++. The project takes advantage of OpenSSL libraries.
Background
On my machine (a 64 bit CentOS quad core) I compile and link my files.
g++ -g -c -L/usr/local/lib/ -L/usr/lib64/
-I/usr/local/include/ -I/usr/local/ssl/include/
-lcrypto mysrc1.cpp mysrc2.cpp mysrc3.cpp
g++ -L/usr/local/lib/ -L/usr/lib64/ -lcrypto
*.o -o ./myapp.out
My application uses function MD5 which is contained in libcrypto.so. As you can see I specify to g++ the dirs where to search using the -L, -I options and which libraries to look for with the -l<lib-name> option. There are some trivial paths like /usr/local/lib which can be omitted of course, but I specified them because the makefile is parametric.
The problem
My problem is that I can successfully compile my stuff (first command), but linking fails (second command):
/usr/bin/ld: cannot find -lcrypto
collect2: ld returned 1 exit status
make: * [cppsims_par] Error 1
But I did check folders and everything... libcrypto.so is inside /usr/lib64/. What is going on?
It may help if you try strace to find why it failed the file lookup
strace -f -e trace=file g++ -L/usr/local/lib/ -L/usr/lib64/ -lcrypto
*.o -o ./myapp.out
I did find the problem and it is related to this question: ld cannot find an existing library
Actually I had no symlink libcrypto.so and the compiler was not able to find the library...
I had related issue, and resolved it after inspecting the trace.
I had
-L<my/path/to/lib> -llib_some_library
when it should have been
-L<my/path/to/lib> -lsome_library
Can anyone give me the correct command to build glew on windows with mingw?
I have tried:
gcc -static glew.c glewinfo.c visualinfo.c -I/path/to/glew/include
but I am getting thousands of linker errors (missing reference).
I can't build with Make because unfortunately the makefile has lots of unix only commands and i don't have cygwin or anything at work.
(alternatively if anyone can point me to a windows 32b build i would be very grateful)
To build it with MinGW, you should do (copied from the make log, with slight modifications and additional explanations):
mkdir lib/
mkdir bin/
gcc -DGLEW_NO_GLU -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32.dll -Wl,--out-implib,lib/libglew32.dll.a -o lib/glew32.dll src/glew.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
# Create library file: lib/libglew32.dll.a
ar cr lib/libglew32.a src/glew.o
# Create pkg-config file (optional if you just want a lib)
sed \
-e "s|#prefix#|/usr|g" \
-e "s|#libdir#|/usr/lib|g" \
-e "s|#exec_prefix#|/usr/bin|g" \
-e "s|#includedir#|/usr/include/GL|g" \
-e "s|#version#|1.6.0|g" \
-e "s|#cflags#||g" \
-e "s|#libname#|GLEW|g" \
< glew.pc.in > glew.pc
gcc -DGLEW_NO_GLU -DGLEW_MX -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.mx.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32mx.dll -Wl,--out-implib,lib/libglew32mx.dll.a -o lib/glew32mx.dll src/glew.mx.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
# Create library file: lib/libglew32mx.dll.a
ar cr lib/libglew32mx.a src/glew.mx.o
# Create pkg-config file (optional if you just want a lib)
sed \
-e "s|#prefix#|/usr|g" \
-e "s|#libdir#|/usr/lib|g" \
-e "s|#exec_prefix#|/usr/bin|g" \
-e "s|#includedir#|/usr/include/GL|g" \
-e "s|#version#|1.6.0|g" \
-e "s|#cflags#|-DGLEW_MX|g" \
-e "s|#libname#|GLEWmx|g" \
< glew.pc.in > glewmx.pc
# Make the glew visualinfo program. Skip this if you want just the lib
gcc -c -O2 -Wall -W -Iinclude -o src/glewinfo.o src/glewinfo.c
gcc -O2 -Wall -W -Iinclude -o bin/glewinfo.exe src/glewinfo.o -Llib -lglew32 -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
gcc -c -O2 -Wall -W -Iinclude -o src/visualinfo.o src/visualinfo.c
gcc -O2 -Wall -W -Iinclude -o bin/visualinfo.exe src/visualinfo.o -Llib -lglew32 -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
You should then have a lib folder and a bin folder with the desired executables and libraries
I got it working (with MinGW), i didn't compile the glew32mx but glew32 instead. Just download the source .zip from GLEW website. And remember create "lib" directory in the the glew-1.xx directory, otherwise it will complain about "can't find /lib/glew32.dll" when trying to compile the second line of code below:
gcc -DGLEW_NO_GLU -O2 -Wall -W -Iinclude -DGLEW_BUILD -o src/glew.o -c src/glew.c
gcc -shared -Wl,-soname,libglew32.dll -Wl,--out-implib,lib/libglew32.dll.a -o lib/glew32.dll src/glew.o -L/mingw/lib -lglu32 -lopengl32 -lgdi32 -luser32 -lkernel32
# Create glew32.dll
ar cr lib/libglew32.a src/glew.o
The precompiled binaries in GLEW website doesn't work with mingw, because they're compiled with visual studio, i think.
Found another solution that works with Code::Blocks. Steps:
1) Obviously you will need glew source code ;)
2) Open glew_shared.dsw files with C::B, edit project properties and, for each build target you need, change it's type from "Dynamic library" to "Static library" (it's right there, at Build targets tab). You can also change the destination directory as .dll files are built into bin\ directory.
3) Add #define GLEW_STATIC before #include
4) Build the target and it will result in proper libglew32*.a being created
Glew build system try to detect automatically your environment using config/configure.guess. You may overload this behaviour by specify $SYSTEM to make. See config/Makefile.* for all supported build configuration. Glew already include configuration to use MinGW.
So, you may just have to launch:
make SYSTEM=linux-mingw64
On my Fedora, I had to tune some variables of config/Makefile.linux-mingw64:
$CC and $LD was not correct
I had to specify directory where system libraries was located
I had to specify where glew should be installed
Finally, I launched:
make SYSTEM=linux-mingw64 \
CC=x86_64-w64-mingw32-gcc LD=x86_64-w64-mingw32-ld \
LDFLAGS.EXTRA=-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib \
GLEW_DEST=/usr/x86_64-w64-mingw32/sys-root/mingw install
Further to PoL0's answer, i found those steps did work for me with MinGW on Code::Blocks but with one further alteration required - the default project has a lot of microsoft nonsense set in the "other options" under compiler options. Clear these and you'll have a good result (project build options -> [each target] -> compiler settings tab -> other options subtab)
You may also wish to enable optimisation for the two release targets (-O2 or -O3).
Additionally, the static libraries will be built in "bin" by default, you'll need to copy / move them to replace the ones in "lib".
Here is how VLC builds glew (static) on mingw:
https://github.com/videolan/vlc/tree/master/contrib/src/glew (they apply that patch). Guess glew has no easy option to "just" build a static library so you have to go through various hurdles (or manually compile, as the other answers allude to).
See also http://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Windows#GLEW
and step 7 here: http://sujatha-techie.blogspot.com/2008/10/glsl-with-mingw.html
This is how mx does it: https://github.com/mxe/mxe/blob/master/src/glew.mk (looks like they basically just manually build everything, glew's Makefile seems weak...)
I believe the main Glew website has a link to the binaries on the front page, for 32-bit and 64-bit windows systems.
if you have MingW installed just run Msys and make and make install there once you finish copy the libs and include folders to the bin libs and include folders in MingW and it should all work fine
simple and fast solution
I am trying to build some software on a brand new install of CentOS 5.5
My compile line is :
g++ -I ../common/ -I ../readers/ -I ../writers/ -I /home/dcole/software/xerces-c-3.1.1/src -O3 -Wall -fopenmp -fPIC -o chipper chipper.cpp -L/usr/lib64/ ../../lib/IDT.a ../../lib/Linux/libxerces-c.a -lcurl -lidn -ldl -lssl ../../lib/Linux/libfftw3f.a -lpthread -lm
and I am getting
[exec] /usr/bin/ld: cannot find -lcurl
[exec] collect2: ld returned 1 exit status
Even though I can actually see the lib
$ /sbin/ldconfig -p | grep curl
libcurl.so.3 (libc6,x86-64) => /usr/lib64/libcurl.so.3
libcurl.so.3 (libc6) => /usr/lib/libcurl.so.3
So why cant g++ see it?
At link time, -lcurl tells the linker to look for libcurl.so.
From there, the SONAME within the library (libcurl.so.3) is embedded into the executable, and that's the filename that is searched for when executing.
You have libcurl.so.3 but may be lacking libcurl.so, which is needed for development.
What is your distribution? Usually there will be a second package with development headers/libraries, separate from the runtime bits.
Copy the file from any source /usr/lib/libcurl.so and place it in /usr/lib/, then try to compile. It will work out.