On OS X Yosemite, this works:
gfortran main.f90
But this:
MACOSX_DEPLOYMENT_TARGET=10.5 gfortran main.f90
yields to the error:
ld: library not found for -lcrt1.10.5.o
collect2: error: ld returned 1 exit status
Why?
gfortran has been installed from http://hpc.sourceforge.net/, file gfortran-4.9-bin.tar.gz .
I use MACOSX_DEPLOYMENT_TARGET=10.5 in order to create binaries that run on OS X from 10.5 to 10.10
I have the file /Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o
Maybe something related to statically linked binary: apple doc.
Edit:
This works:
MACOSX_DEPLOYMENT_TARGET=10.5 gfortran -o main -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib main.f90
But is it the right way? Is it a problem that crt1.10.5.o is linked statically?
I solved this for compiling with gfortran by installing XCode command-line tools as described http://hpc.sourceforge.net
Not sure it will solve your problem.
Good luck.
Jon
Related
I am on Windows, and I am using the version of g++ that comes with mingw-64. I have a file on my computer called lua51.dll. When I try to run the following command :
g++ -shared -fPIC -o stuff.dll -llua51 stuff.cpp
I get the following error:
C:/Program Files/LOVE/lua51.dll: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
make: *** [main] Error 1
How can I fix this? Please let me know if more information is needed; I am a complete beginner to compilation.
This is an issue you get when you try to include a 64-bit library when running a 32-bit version of g++ or even gcc.
I thought that that the version of g++.exe that comes with mingw-64 would produce 64-bit code, but it turns out this isn't true; it still only produces 32-bit code. In my case, lua51.dll is 64-bit, which is an issue since I was using the version of g++ that produces 32-bit code.
Instead, you need to use x86_64-w64-mingw32-g++.exe, which can be found in the same folder as g++.exe. This is the version of g++ that will produce 64-bit code.
I am new to g++ and lapack, and attempting to use them. I encountered a problem when I tried to compile the following naive code
#include <lapackpp.h>
int main()
{
LaGenMatDouble A;
return 0;
}
If I run the command
$g++ -L/usr/local/lib -llapackpp test2.cpp
where test2.cpp is the name of the cpp file, the terminal would give an error:
test2.cpp:1:22: fatal error: lapackpp.h: No such file or directory
But if I run the command:
$g++ -I/usr/local/include/lapackpp -L/usr/local/lib -llapackpp test2.cpp
the terminal would give an error:
/tmp/ccUi11DG.o: In function `main':
test2.cpp:(.text+0x12): undefined reference to `LaGenMatDouble::LaGenMatDouble()'
test2.cpp:(.text+0x23): undefined reference to `LaGenMatDouble::~LaGenMatDouble()'
collect2: ld returned 1 exit status
BTW, if I run the command
$pkg-config lapackpp --libs
the result is
-L/usr/local/lib -llapackpp
Could you please help me solve this? Thanks in advance!
Lapack requires fortran libraries, so that's where the -lgfortran comes from. Moreover, it appears the exact way to provide that library for the compiler depends on the Linux distriburion. From the documentation:
Requirements
This package requires the packages "blas", "lapack" (without the "++"), and a Fortran compiler. On most Linuxes these are available as pre-compiled binaries under the name "blas" and "lapack". For SuSE 10.x, the Fortran compiler is available as package "gfortran". For SuSE 9.x, the Fortran compiler is available as package "gcc-g77".
Not sure why pkg-config lapackpp --libs does not list -lgfortran
The -I/usr/local/include/lapackpp specifes the lapackpp-related header files. Without it the compiler cannot find lapackpp.h when you try to include it (#include <lapackpp.h>) -- see the compiler error in your question
I finally solved the problem but would still wonder why it has to be so.
The only command that can link cpp file to lapackpp library is:
g++ foo.cpp -o foo -lgfortran -llapackpp -I/usr/local/include/lapackpp
It would not work without -lgfortran, or with -I/usr/local/include/lapackpp replaced by -L/usr/local/lib.
Does anyone have an answer?
hope someone can me help. I need to compile some code. I installed everything I needed with macports, in /opt/local/. And it's working how it should, except gFortran. I get this error:
ld: library not found for -lgfortran
collect2: ld returned 1 exit status
make[2]: *** [vigranumpy/private/graph/tws/svs.dylib] Error 1
make[1]: *** [vigranumpy/private/graph/tws/CMakeFiles/svs.dir/all] Error 2
make: *** [all] Error 2
I want everything to be installed in /opt/local/, because I don't want to touch the system (/usr/). gFortran isn't available for macports. You can install it with gcc46 as a variant. But if I use the gcc46 instead the default compilers, then the code before want compile.
How can I fix that?
Kind regards
See the CMake FAQ on how to use a different compiler:
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F
To use gfortran from macports as the fortran compiler, you should:
export FC=/opt/local/bin/gfortran
export CC=/opt/local/bin/gcc
export CXX=/opt/local/bin/g++
...prior to calling CMake. Then, after calling CMake with such environment variables set, it will cache the compiler paths in the CMakeCache.txt file, so for subsequent runs, you do not need the environment variables set anymore.
For mixed language (C, C++, Fortran) projects, it's important that the compilers all play nicely with each other.
This advice only works with the "Unix Makefiles" generator. I do not know of anybody who is using fortran via Xcode in conjunction with CMake.
Using: windows xp, g++ 3.4.4 with cygwin and g++ 3.4.5 with mingw.
I'm compiling a simple unit test class with cppunit.
When I link using g++ 3.4.5 I get a lot of linking errors. When I link with g++ 3.4.4 I don't get any errors and the exe links fine and runs.
I can't seem to trace down the errors, so any thoughts?
Thanks.
EDIT: linking errors: Unreferenced function errors. Like:
SimpleTest.cpp:(.text+0x313): undefined reference to `CppUnit::Message::Message(std::string const&, std::string const&)'
EDIT: cmd line:
g++ -I g:\projects\thirdparty\cppunit-1.12.1\include -L g:\projects\thirdparty\cppunit-1.12.1\lib -l cppunitd -o main.exe main.cpp SimpleTest.cpp
Update: Same code in Visual Studio: No error, unit test runs as expected.
Your problem is likely incorrect link line. The order of sources/object files and libraries on the link line matters. Correct link line:
g++ -I g:\projects\thirdparty\cppunit-1.12.1\include \
-L g:\projects\thirdparty\cppunit-1.12.1\lib \
-o main.exe main.cpp SimpleTest.cpp -lcppunitd
As g++ matures, I'm on 4.2.3, it's type checking has gotten more pedantic and for that matter better. With the little information I'd say it's likely that you should look closely at your calls to these methods. I suspect that the types are not quite right. 3.4.4 doesn't catch it, 3.4.5 does.
....JW
One thing you could perhaps try is to compile with g++ 3.4.5 and/or 3.4.4 on Linux. If the result then is the same, then it is clearly a property of gcc. Otherwise it more sounds like a mingw issue.
When I try to compile a simple c++ file using Magick++ and cygwin, I keep getting this result:
$ g++ -o imageTest imageTest.cpp `GraphicsMagick++-config --cppflags --cxxflags --ldflags --libs`
g++: unrecognized option `-no-undefined'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -ldpstk
collect2: ld returned 1 exit status
I installed ImageMagick through the cygwin gui setup.
GraphicsMagick and ImageMagick are two different libraries. If you want to build your program using ImageMagick, as you state, it's just a matter of changing
GraphicsMagick++-config
into
Magick++-config
This should work. As for GraphicsMagick, it looks like the current -devel library in Cygwin is broken, as it requires a library (libdpstk) which is no longer available. (Have a look here if you are interested.)