From: Samuel H. <sam...@gm...> - 2013-08-26 09:00:27
|
On 25 Aug 2013, at 23:36, Earnie Boyd wrote: > On Sun, Aug 25, 2013 at 1:17 PM, Sam Halliday wrote: >> The full parameter list is a bit verbose. Btw, I'm building a shared lib: >> >> gcc -o mylib.so -shared -static-libgfortran -lgfortran ... .o files ... > ^^^ > You problem as I tried to point out is you use GCC instead of GFORTRAN > to try to link the fortran objects. I had made the assumption that > you were using gcc instead of the correct frontend already. > > gfortran -shared -o mylib.dll -static-libgfortran mylib.o Hmm, that is interesting. I tried this, but there are still some lingering dynamic references: DLL Name: libgcc_s_seh-1.dll DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL Name: libquadmath-0.dll DLL Name: USER32.dll A -static-libgcc gets rid of the libgcc_s_seh-1.dll reference, but there doesn't appear to be an equivalent for libquadmath. As a workaround, I tried to pass the full path to the libquadmath: gfortran -shared -o mylib.dll -static-libgfortran /opt/mingw32/mingw/lib/libquadmath.a -static-libgcc ... <object files> I'm am falling back to my previous workaround using the following parameters to the gcc linker: -shared /opt/mingw64/mingw/lib/libgfortran.a /opt/mingw64/mingw/lib/libquadmath.a -static-libgcc Also, I should note that my .o files are not all Fortran files. Some are also C files. Hence it feels very strange to be using gfortran as the linker. On OS X, the -static-libgfortran works with gcc (but the full path to libquadmath must be called, also with -static-libgcc). |