creating DLL with gfortran on Windows

There is a difference in philosophy between the two operating systems in terms of how symbols are resolved for load time dynamic linking. In linux, the resolution of the name of the library that provides a particular symbol can be deferred till load time, while in Windows the name of the library that will provide a symbol must be resolved at link time.

Consequently, under linux you can link the libdll2.so shared library without providing any information to the linker about the location of the object code for the test1 procedure, while linking dll2 on Windows requires something akin to the -ldll1 command option. When linking the final executable on Windows, you then do not need to repeat the -ldll1 specification.

I cannot reproduce your observations with the modified link process on Windows with the Msys2 mingw-64 x86_64 toolchain.

$ gfortran -shared -fPIC -o dll1.dll dll1.f90$ gfortran -shared -fPIC -o dll2.dll dll2.f90 -L. -ldll1$ gfortran -o main main.f90 -L. -ldll2$ ./main.exe test1 ok$ du -b *330013  dll1.dll125     dll1.f90204     dll1.mod329573  dll2.dll140     dll2.f90237     dll2.mod398054  main.exe87      main.f90

Inspection of the dll and exe executable modules show the expected symbol imports and exports, and runtime debugging shows that execution is being transferred between executable modules.

Note that stripping debugging symbols will spectacularly reduce EXE and DLL file size.