Bug in the Makefile creation for DLL

Same thing as above to build the executable when linking with DLLs.
I must remove the '-static' flag in order to get a successful link.

Consider a simple example of two DLLs : libone and libtwo. Files are stored in separated folders and each one
has a project file.

The first DLL is of course successfully created:
"C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe" -c -o "build\libone.o" -m32 -Jmodules "libone.f90"
"C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe" -o "libone.dll" -shared -static -m32 "build\libone.o" -LC:/PROG~5P2/SIMP~CHN/MING~DAW/lib/

The second files libtwo.f90 depends on libone.f90 (via modules and subroutine calls), so in the project properties :
     "..\libone\modules" has been added to the "Include/Module Directories"
and
     "..\libone" has been added to the "Librairies Directories"

Then, hereafter is the creation of libtwo.dll:
"C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe" -c -o "build\libtwo.o" -m32 -IZ:/home/ecanot/tmp/workspace/SimplyFortran/essais/dynamic/libtwo/../libone/modules  -Jmodules "libtwo.f90"
"C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe" -o "libtwo.dll" -shared -static -m32 "build\libtwo.o" -LC:/PROG~5P2/SIMP~CHN/MING~DAW/lib/ -LZ:/home/ecanot/tmp/workspace/SimplyFortran/essais/dynamic/libtwo/../libone -lone
c:/program files (x86)/simply fortran 2/mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lone
collect2.exe: error: ld returned 1 exit status
Error(E42): Last command making (libtwo.dll) returned a bad status
Error(E02): Make execution terminated

Besides, if I remove the '-static' flag from the libtwo Makefile:
"C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe" -o "libtwo.dll" -shared -m32 "build\libtwo.o" -LC:/PROG~5P2/SIMP~CHN/MING~DAW/lib/ -LZ:/home/ecanot/tmp/workspace/SimplyFortran/essais/dynamic/libtwo/../libone -lone

* Complete *

Okay, I see why you're having the issue.  Your library flag in the libtwo project is:

-lone

The compiler, with the -static flag set, is looking for a file named libone.a.  Apparently, if you remove the -static flag, it will instead use libone.dll if anything, which is actually a bit of a surprise to me.

Anyway, the ideal solution is to generate an import library while building the DLL.  Simply Fortran probably should do this by default, but it currently doesn't.  We ideally want to create a file libone.dll.a that will merely contain the declaration of exported symbols in libone.dll.  To do so, load your libone project and open the Project Options dialog.  In the Linker text field under Project Flags, add the following:

-Wl,--out-implib=libone.dll.a

That first part is "capital double-U el," and it instructs gfortran to pass along the flag after the comma to the linker directly.  Now clean and rebuild your libone project.  If you navigate to that directory, you should now see a libone.dll and libone.dll.a.

Next, open your libtwo project.  Open the Project Options dialog and change your library flag from:

-lone

to:

-lone.dll

Clean and rebuild your project, and everything should work fine.

The above method is actually how most GNU-compiled DLLs are linked to under Windows.  The GTK+ project is a good example.  In their lib directory are an assortment of "libgtk-2.0.dll.a" and similar files.

The above should fix your issue, although it is not necessarily ideal.  I think Simply Fortran should allow for two things:

1. Import libraries should be created by default when building DLLs

2. Users should be able to optionally disable static linking

Let me know if this solution works out.    It's good to hear someone is using Simply Fortran under WINE.  A reasonable amount of Simply Fortran's development takes place under WINE using Simply Fortran itself as the IDE.  The only real issue I've come across is the Start screen not loading properly.  If you do see any other problems under WINE, please don't hesitate to post them.

True, I hadn't considered the default behavior on GNU/Linux, and I suppose on Windows, it will simply replace the .so extension with .dll.  That said, the general "preferred" route under Windows is to use import libraries when dealing with linking to DLLs.  As I pointed out, the GTK+ libraries do so, and I know from experience that Python uses the same technique under Windows.

I've had complaints about the size of executables and libraries created by Simply Fortran before, and, of course, it is due to statically linking the GNU Fortran runtime library to the targets.  However, the size is not anything close to problematic on today's modern hard disks, and it eliminates two possible issues.  First, it gets rid of the need to further contaminate the system path with the compiler's internal library directory.  Second, it allows programs built with Simply Fortran to be shared with others without having to hunt down the GNU Fortran and GCC runtime DLLs.

The tradeoff is a few hundred kilobytes of disk space for a little more ease of use and fewer headaches.

Sorry, when typing my comment at 17:05, I didn't see yours at 15:04 ...

Jeff, for your information, I just tried this evening SF-2.3 with wine-1.7.1:

• as before, SF cannot be launch by clicking on the desktop icon; but clicking on any project file launches it.

• once built, the program can be executed inside the IDE (contrary to wine-1.4.1) by typing F5. Input values may be entered in the bottom bar, after clicking to the send button.

• the debugger seems to work properly, at least for a small test program of 20 lines. Stepping between lines works. Input/Output are done in a separated window.

Regards,
Édouard

Édouard,

Version 2.4 is now available, and it allows enabling/disabling static linking in Project Options.  It will continue to provide static linking by default, but it can be easily disabled now.