Hi Arjen:
On 2011-11-09 12:59+0100 Arjen Markus wrote:
> Hello,
>
> I have run into a strange problem with the Fortran 95 bindings.
> My platform is Windows XP (using MinGW, not MSYS) with gfortran as the
> Fortran compiler. The Fortran 77 bindings and examples work fine with
> that combination, but gfortran refuses to build the Fortran 95 examples.
> The reason is that there are duplicate symbols, such as
> _gfortran_set_args, that the linker does not like.
>
> Strangely enough, these symbols are referred to in libplplotf95d.dll.a
> and libplplotf95optsd.a as well as libplplotf77optsd.a (I expect them in
> the latter two), but not in the Fortran 77 library libplplotf77d.dll.a.
> Their absence in that last file means that the linker finds only one
> definition and is perfectly happy building the examples.
>
> I have tried to deduce from the object files and compile options and
> the like where the difference is coming from, but without a single
> piece of success.
>
> My solution therefore is to bring in the option
> "-Wl,--allow-multiplpe-define", as with that option linking the
> examples does work.
>
> Has anyone seen similar problems on this or another platform?
Hi Arjen:
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.
What happens for the "MSYS Makefiles" generator? This will test if
the issue is specific to the "MinGW Makefiles" generator or more
general.
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.
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.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
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
