i Alan,
On 2011-11-09 19:19, Alan W. Irwin wrote:
>
> Is this the first time you have tested the MinGW version of gfortran
> on Windows for our f95 examples using the "MinGw Makefiles" generator?
> As I recall, I could not get those examples to work on MinGW/Wine for
> the "MSYS Makefiles" generator, but I believe it was a separate issue
> (complaints about the form of the module file). I wrote that off as a
> Wine platform problem and probably didn't get deep enough into the
> testing to run into the problem you describe.
>
No, the MinGW+gfortran combination (not MSYS) is the one I use most.
It is only very recent that I noticed these issues.
The issue is very strange, because I can see no reason in the source
code or the object code for including these routines that are part
of gfortran run-time. Also note that these routines are not doubly
present in the FORTRAN 77 case.
It may be the combination of static and dynamic libraries that is
causing trouble, but the command-line arguments passed to the program
are not accessible from a DLL/shared object. So if we turn to dynamic
libraries only, we lose the functionality.
> What happens for the "MSYS Makefiles" generator? This will test if
> the issue is specific to the "MinGW Makefiles" generator or more
> general.
Hm, I have not tried that yet.
>
> All of the relevant build system logic is controlled
> with the STATIC_OPTS cmake variable which is set in
> cmake/modules/TestF77CmdLine.cmake as follows:
>
> SET(STATIC OFF)
> IF(WIN32)
> IF(MINGW OR CYGWIN)
> IF(BUILD_SHARED_LIBS)
> SET(STATIC ON)
> ENDIF(BUILD_SHARED_LIBS)
> ENDIF(MINGW OR CYGWIN)
> ENDIF(WIN32)
> IF(STATIC)
> SET(STATIC_OPTS ON CACHE BOOL "Command-line parsing in static library")
> ELSE(STATIC)
> SET(STATIC_OPTS OFF CACHE BOOL "Command-line parsing in static library")
> ENDIF(STATIC)
>
> It appears this build system logic is attempting to work around some
> problem with the MINGW gfortran compiler (for either generator since
> the MINGW cmake variable is set for the MinGW compiler regardless of
> generator) for the Windows and Cygwin platforms. A fundamental
> question is whether that problem has now been fixed for the latest
> MinGW compiler. To answer that question replace
>
> SET(STATIC ON) ==> SET(STATIC OFF)
>
> (which implies that STATIC_OPTS will always be OFF) in the above
> logic; install that latest versions of MinGW/MSYS; and rename sh.exe
> so the "MinGW Makefiles" generator will work. (That rename allows you
> to keep bash.exe on your PATH so that all the test suite works for the
> "MinGW Makefiles" generator just like it does for the "MSYS Makefiles"
> generator.) Or don't rename she.exe and use the "MSYS Makefiles"
> generator instead.
Well worth experimenting with.
>
> N.B. you have to download and install the latest automatic installer
> for MinGW/MSYS to access the latest MinGW/MSYS. Using the update
> command for an older version of that automatic installer does not get
> you the latest versions.
>
> Even if STATIC_OPTS ON turns out to still be necessary with the latest
> MinGW and MinGW/MSYS versions of gfortran, I have some questions about the
> implementation. For the f95 case and STATIC_OPTS ON we have the
> following cmake logic:
>
> add_library(plplotf95${LIB_TAG} ${plplotf95${LIB_TAG}_LIB_SRCS})
>
> if(STATIC_OPTS)
> add_library(plplotf95opts${LIB_TAG} STATIC
> ${plplotf95opts${LIB_TAG}_LIB_SRCS})
> target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG})
> target_link_libraries(plplotf95opts${LIB_TAG} plplotf95${LIB_TAG}
> plplotf95c${LIB_TAG})
> else(STATIC_OPTS)
> target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG})
> endif(STATIC_OPTS)
>
> So it appears for the STATIC_OPTS ON case you are trying to link the
> static plplotf95opts${LIB_TAG} library using the shared
> plplotf95${LIB_TAG} library as a dependency.
>
> Such mixtures of shared and static libraries are always tricky to link
> correctly. As far as I can tell plplotf95opts${LIB_TAG} only has the
> plparseopts7_ symbol undefined which is resolved by
> plplotf95c${LIB_TAG}. In other words, I don't believe
> plplotf95${LIB_TAG} supplies any symbol required by
> plplotf95opts${LIB_TAG}. I would think putting plplotf95c${LIB_TAG}
> in the dependent library list for
> target_link_libraries(plplotf95opts${LIB_TAG} ....) would be
> relatively harmless, but there be some nasty linking side effect that
> is causing so I would suggest simplifying the linking logic as follows
> for the STATIC_OPTS ON case:
>
> add_library(plplotf95opts${LIB_TAG} STATIC
> ${plplotf95opts${LIB_TAG}_LIB_SRCS})
> target_link_libraries(plplotf95${LIB_TAG} plplotf95c${LIB_TAG})
> target_link_libraries(plplotf95opts${LIB_TAG} plplotf95c${LIB_TAG})
>
> This simplified linking means that the examples will need to be linked
> to both plplotf95opts${LIB_TAG} and plplotf95${LIB_TAG} for the
> STATIC_OPTS ON case, but that is a small price to pay if the result
> works.
>
> There are a number of other possibilities to try such as linking
> plplotf95opts${LIB_TAG} separately but as SHARED, or linking it STATIC
> but with the -FPIC compile option so that it can be linked
> as a dependency of plplotf95${LIB_TAG. But I think your best bets
> for solving this are (1) install the latest gfortran version available
> for MinGW and try both the "MinGW Makefiles" and "MSYS Makefiles"
> generators, or (2) simplify the linking by dropping plplotf95${LIB_TAG}
> (as above) as a target_link_libraries dependency of
> plplotf95opts${LIB_TAG}.
>
> If none of those options work, I would be willing to try to test the
> combination of the latest wine and latest MinGW/MSYS under Wine to see
> if the module issue in that case is now solved so that I can explore
> the issue under Wine. But that is a pretty big time committment when
> I am tied up with other things so I really hope one of my suggested
> options does work for you.
I will go and experiment with these.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
