Menu
▾
▴
mingw-users
|
From: Samuel H. <sam...@gm...> - 2013-08-23 18:44:02
|
Hi all, I am author of https://github.com/fommil/netlib-java/ and I am trying to build native fortran binaries using Mingw. My binaries are building, but they are referencing the libgfortran.dll which means they are failing on the target platform, because it doesn't have that library. Because of the way that Java Native libraries are packaged, I need a single self-contained binary that I can load. It is possible to create such a binary on OS X (no cross-compiling) by passing the following command line arguments to a macports gcc (Xcode doesn't have gfortran): -dynamiclib -lgfortran -static-libgfortran /opt/local/lib/gcc48/libquadmath.a -static-libgcc (note the awkwardness with libquadmath) This results in a single dynamic library/application that can be run on any OS X machine without the need for fortran or gcc libraries (i.e. Joe Public). I've failed to repeat this process in Linux as the libgfortran.a is not compiled with -fPIC (allowing it to be included as part of a dynamic library). I am also completely lost how this would be achieved with MinGW. Any help to get a single library / application file that includes the libgfortran would be greatly appreciated! (NOTE: this is not the same as a static library: that would imply bundling the C library as well. As a workaround, I am prepared to consider a completely static library on Windows if you can help me with that. I think Linux users are intelligent enough to install the libgfortran through their package manager ;-P) -- Sam |
|
From: Samuel H. <sam...@gm...> - 2013-08-23 21:39:52
|
Hmm, I think I might have just fixed this by supplying the following gcc arguments: -shared /usr/lib/gcc/x86_64-w64-mingw32/4.6/libgfortran.a whereas this dynamically links the fortran lib (not what I want): -shared -lgfortran -static-libgfortran Does this sound right? -- Sam On 23 Aug 2013, at 19:43, Samuel Halliday <sam...@gm...> wrote: > Hi all, > > I am author of https://github.com/fommil/netlib-java/ and I am trying to build native fortran binaries using Mingw. > > My binaries are building, but they are referencing the libgfortran.dll which means they are failing on the target platform, because it doesn't have that library. > > Because of the way that Java Native libraries are packaged, I need a single self-contained binary that I can load. It is possible to create such a binary on OS X (no cross-compiling) by passing the following command line arguments to a macports gcc (Xcode doesn't have gfortran): > > -dynamiclib -lgfortran -static-libgfortran /opt/local/lib/gcc48/libquadmath.a -static-libgcc > > (note the awkwardness with libquadmath) > > This results in a single dynamic library/application that can be run on any OS X machine without the need for fortran or gcc libraries (i.e. Joe Public). > > > I've failed to repeat this process in Linux as the libgfortran.a is not compiled with -fPIC (allowing it to be included as part of a dynamic library). > > I am also completely lost how this would be achieved with MinGW. > > Any help to get a single library / application file that includes the libgfortran would be greatly appreciated! > > (NOTE: this is not the same as a static library: that would imply bundling the C library as well. As a workaround, I am prepared to consider a completely static library on Windows if you can help me with that. I think Linux users are intelligent enough to install the libgfortran through their package manager ;-P) > > > -- > Sam > |
|
From: Keith M. <kei...@us...> - 2013-08-23 22:15:46
|
On 23/08/13 22:39, Samuel Halliday wrote: > I think I might have just fixed this by supplying the following gcc arguments: > > -shared /usr/lib/gcc/x86_64-w64-mingw32/4.6/libgfortran.a This suggests that you are using a mingw-w64 tool chain, (provided by a different project, and this is not their mailing list); perhaps you should ask them. However... > whereas this dynamically links the fortran lib (not what I want): > > -shared -lgfortran -static-libgfortran > > Does this sound right? No, this does not seem right. You don't show your full command line, so I can't be sure; are you, perhaps, falling into the (sadly all too common) trap of specifying your command line arguments in the wrong order? -lfoo cannot be arbitrarily placed; it *must* come *after* anything else which may refer to it, (in particular object files which require it to resolve references); of what you've shown, should not -static-libgfortran (at least) precede -lgfortran? -- Regards, Keith. |
|
From: Samuel H. <sam...@gm...> - 2013-08-24 00:07:02
|
-static-libgfortran before -lgfortran makes no difference... still gives the dynamically linked libgfortran :-( -- Sam On 23 Aug 2013, at 23:15, Keith Marshall <kei...@us...> wrote: > On 23/08/13 22:39, Samuel Halliday wrote: >> I think I might have just fixed this by supplying the following gcc arguments: >> >> -shared /usr/lib/gcc/x86_64-w64-mingw32/4.6/libgfortran.a > > This suggests that you are using a mingw-w64 tool chain, (provided by a > different project, and this is not their mailing list); perhaps you > should ask them. However... > >> whereas this dynamically links the fortran lib (not what I want): >> >> -shared -lgfortran -static-libgfortran >> >> Does this sound right? > > No, this does not seem right. You don't show your full command line, so > I can't be sure; are you, perhaps, falling into the (sadly all too > common) trap of specifying your command line arguments in the wrong > order? -lfoo cannot be arbitrarily placed; it *must* come *after* > anything else which may refer to it, (in particular object files which > require it to resolve references); of what you've shown, should not > -static-libgfortran (at least) precede -lgfortran? > > -- > Regards, > Keith. > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
|
From: Earnie B. <ea...@us...> - 2013-08-25 14:51:13
|
On Fri, Aug 23, 2013 at 8:06 PM, Samuel Halliday <sam...@gm...> wrote: > -static-libgfortran before -lgfortran > > makes no difference... still gives the dynamically linked libgfortran :-( > You still haven't given your full command line. gfortran -o foo.exe foo.o -static -static-libfortran -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Sam H. <sam...@gm...> - 2013-08-25 17:18:11
|
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 ... Results in a dynamic reference. > g -o foo.exe foo.o -static -static-libfortran Kind regards, Sam Halliday -- Sent from my iPhone On 25 Aug 2013, at 15:51, Earnie Boyd <ea...@us...> wrote: > On Fri, Aug 23, 2013 at 8:06 PM, Samuel Halliday <sam...@gm...> wrote: >> -static-libgfortran before -lgfortran >> >> makes no difference... still gives the dynamically linked libgfortran :-( > > You still haven't given your full command line. > > gfortran -o foo.exe foo.o -static -static-libfortran > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
|
From: Sam H. <sam...@gm...> - 2013-08-25 17:24:10
|
Sorry, DLL not SO Kind regards, Sam Halliday -- Sent from my iPhone On 25 Aug 2013, at 18:17, Sam Halliday <sam...@gm...> 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 ... > > Results in a dynamic reference. > >> g -o foo.exe foo.o -static -static-libfortran > > Kind regards, > Sam Halliday > > -- > Sent from my iPhone > > On 25 Aug 2013, at 15:51, Earnie Boyd <ea...@us...> wrote: > >> On Fri, Aug 23, 2013 at 8:06 PM, Samuel Halliday <sam...@gm...> wrote: >>> -static-libgfortran before -lgfortran >>> >>> makes no difference... still gives the dynamically linked libgfortran :-( >> >> You still haven't given your full command line. >> >> gfortran -o foo.exe foo.o -static -static-libfortran >> >> -- >> Earnie >> -- https://sites.google.com/site/earnieboyd >> >> ------------------------------------------------------------------------------ >> Introducing Performance Central, a new site from SourceForge and >> AppDynamics. Performance Central is your source for news, insights, >> analysis and resources for efficient Application Performance Management. >> Visit us today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> _______________________________________________ >> MinGW-users mailing list >> Min...@li... >> >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> Also: mailto:min...@li...?subject=unsubscribe |
|
From: Samuel H. <sam...@gm...> - 2013-08-25 18:16:46
|
And the .o files are before the library includes (that's what I get for trying to do it from memory!) -- Sam On 25 Aug 2013, at 18:23, Sam Halliday <sam...@gm...> wrote: > Sorry, DLL not SO > > Kind regards, > Sam Halliday > > -- > Sent from my iPhone > > On 25 Aug 2013, at 18:17, Sam Halliday <sam...@gm...> 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 ... >> >> Results in a dynamic reference. >> >>> g -o foo.exe foo.o -static -static-libfortran >> >> Kind regards, >> Sam Halliday >> >> -- >> Sent from my iPhone >> >> On 25 Aug 2013, at 15:51, Earnie Boyd <ea...@us...> wrote: >> >>> On Fri, Aug 23, 2013 at 8:06 PM, Samuel Halliday <sam...@gm...> wrote: >>>> -static-libgfortran before -lgfortran >>>> >>>> makes no difference... still gives the dynamically linked libgfortran :-( >>> >>> You still haven't given your full command line. >>> >>> gfortran -o foo.exe foo.o -static -static-libfortran >>> >>> -- >>> Earnie >>> -- https://sites.google.com/site/earnieboyd >>> >>> ------------------------------------------------------------------------------ >>> Introducing Performance Central, a new site from SourceForge and >>> AppDynamics. Performance Central is your source for news, insights, >>> analysis and resources for efficient Application Performance Management. >>> Visit us today! >>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> MinGW-users mailing list >>> Min...@li... >>> >>> This list observes the Etiquette found at >>> http://www.mingw.org/Mailing_Lists. >>> We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. >>> >>> _______________________________________________ >>> You may change your MinGW Account Options or unsubscribe at: >>> https://lists.sourceforge.net/lists/listinfo/mingw-users >>> Also: mailto:min...@li...?subject=unsubscribe |
|
From: Earnie B. <ea...@us...> - 2013-08-25 22:36:54
|
On Sun, Aug 25, 2013 at 1:17 PM, Sam Halliday wrote: PLEASE STOP TOP POSTING. > 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 > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. Please read this! -- Earnie -- https://sites.google.com/site/earnieboyd |
|
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). |
|
From: Peter R. <p.r...@sh...> - 2013-08-26 10:02:44
|
On 26/08/13 10:00, Samuel Halliday wrote: > 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: >>> ...snip >>> I'm am falling back to my previous workaround using the following parameters to the gcc linker: ...snip >>> 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). >>> >>> _-r...@li...?subject=unsubscribe AFAIU, neither gcc nor gfortran is a 'compiler', nor indeed a 'linker'. They are both front-ends which, dependent on command line parameters, invoke a compiler proper, and then a linker to combine the object files. I think you will find that gcc and gfortran ultimately invoke the same linker, ld. So not strange at all... P. |
|
From: Samuel H. <sam...@gm...> - 2013-08-26 10:21:17
|
On 26 Aug 2013, at 11:02, Peter Rockett <p.r...@sh...> wrote: > On 26/08/13 10:00, Samuel Halliday wrote: >> On 25 Aug 2013, at 23:36, Earnie Boyd wrote: >>> On Sun, Aug 25, 2013 at 1:17 PM, Sam Halliday wrote: > ...snip >>>> 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). >>>> > AFAIU, neither gcc nor gfortran is a 'compiler', nor indeed a 'linker'. > They are both front-ends which, dependent on command line parameters, > invoke a compiler proper, and then a linker to combine the object files. > I think you will find that gcc and gfortran ultimately invoke the same > linker, ld. So not strange at all... That is true, but don't you agree that it is unusual to use gfortran to link objects that are language independent? I much rather use the gcc front-end which is language agnostic. |
|
From: Earnie B. <ea...@us...> - 2013-08-26 11:27:09
|
On Mon, Aug 26, 2013 at 6:21 AM, Samuel Halliday wrote: > > That is true, but don't you agree that it is unusual to use gfortran to link objects that are language independent? I much rather use the gcc front-end which is language agnostic. > That is not true. GCC is much language agnostic and is bent toward providing C. All of the frontends when used for compiling will try to determine the type of source being compiled and will, based on assumptions that may not be correct, pass the source to its compiler. GCC as a linker is C agnostic only. You must use the correct frontend so that the base libraries are passed in the correct order. Add a -v option to the command line to see what the different frontends do for each of the functions, compiler or linker. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Samuel H. <sam...@gm...> - 2013-08-26 11:37:20
|
On 26 Aug 2013, at 12:26, Earnie Boyd wrote: > On Mon, Aug 26, 2013 at 6:21 AM, Samuel Halliday wrote: >> >> That is true, but don't you agree that it is unusual to use gfortran to link objects that are language independent? I much rather use the gcc front-end which is language agnostic. >> > > That is not true. GCC is much language agnostic and is bent toward providing C. Aah, so for the command, the "GCC" stands for "GNU C Compiler" and not "GNU Compiler Collection" ? ;-) |
|
From: Earnie B. <ea...@us...> - 2013-08-26 14:38:48
|
On Mon, Aug 26, 2013 at 7:37 AM, Samuel Halliday wrote: > On 26 Aug 2013, at 12:26, Earnie Boyd wrote: >> On Mon, Aug 26, 2013 at 6:21 AM, Samuel Halliday wrote: >>> >>> That is true, but don't you agree that it is unusual to use gfortran to link objects that are language independent? I much rather use the gcc front-end which is language agnostic. >>> >> >> That is not true. GCC is much language agnostic and is bent toward providing C. > > Aah, so for the command, the "GCC" stands for "GNU C Compiler" and not "GNU Compiler Collection" ? ;-) > That depends on the context in which it is used. GCC is the Gnu C Compiler when used on the command line to compile C. It is the GNU Compiler Collection when talking broadly about all of the compilers. The acronym just happens to fit both. http://gcc.gnu.org/wiki/History -- Earnie -- https://sites.google.com/site/earnieboyd |
