Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far

[Alan W. I. <ir...@be...>]

On 2016-02-11 13:51-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Thursday, February 11, 2016 10:39 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>>
>> A bad efficiency regression in CMake-3.5.0-rc1 and a whole host of other 3.5 issues
>> got fixed for CMake-3.5.0-rc2 so I decided to test that CMake version by doing a
>> complete comprehensive PLplot test (except the interactive part was dropped so I
>> wouldn't have to babysit the test).
>>
>> That noninteractive comprehensive PLplot test of CMake-3.5.0-rc2 worked
>> flawlessly on Linux just like CMake versions 3.3.2 and 3.4.3 did before this test. So
>> I urge you all to try 3.4.3 now (especially on non-Linux platforms since as noted
>> yesterday a bump to that minimum version for those platforms is imminent [i.e.,
>> soon after both Cygwin and MinGW-w64/MSYS2 provide that version of cmake])
>> and also try 3.5.0 as soon as that finalized version is released.  And please share
>> those good or bad results for your various platforms with this list to give us all a
>> better idea of the reliability of the various CMake versions on various platforms.
>>
>
>
> I have now Cmake 3.4.3 for Windows (should be useable under MingW as well as bare Windows), but after correcting the plplotf95_ifort.def file I ran into a problem with Tcl:
>
> tclAPI.c
>
> D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(792) : warning C4996: '_getcwd': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _getcwd. See online help for details.
>
>        C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\direct.h(59) : see declaration of '_getcwd'
>
> D:\plplot-svn\plplot-git\bindings\tcl\tclAPI.c(3783) : warning C4101: 'argc' : unreferenced local variable
>
> [ 13%] Linking C shared library ..\..\dll\plplottcltk.dll
>
>   Creating library ..\..\dll\plplottcltk.lib and object ..\..\dll\plplottcltk.exp
>
> tclAPI.c.obj : error LNK2001: unresolved external symbol plplotLibDir
>
> ..\..\dll\plplottcltk.dll : fatal error LNK1120: 1 unresolved externals
>
> LINK Pass 1 failed. with 1120
>
> NMAKE : fatal error U1077: 'D:\cmake3.4.3\bin\cmake.exe' : return code '0xffffffff'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>
> Stop.
>
> The problem is not the message about _getcwd(), but the linkage of plplotLibDir. I haven't analysed the problem in sufficient detail to really understand what is going and why it worked before, but my current guess - and that is a guess, no more - is that the macros that are defined cause the relevant macro PLDLLIMPEXP_TCLTK_DATA( type ) to be defined as "export" instead of "import".
>
> More to follow.

Hi Arjen:

Could you check if this is really a CMake-3.4.3 issue?  That is if you
run the exact same test with CMake-3.3.2 does that solve it? Or does
that linker error persist for both cases presumably due to a long-term
MSVC visibility issue for the combination of libplplottcltk and libplplot?

The reason I suspect the latter case is the only way I can see that
the CMake version affects our visibility implementation is if there is
an an unlikely CMake regression in the way that include/pldll.h(.in)
is configured or an unlikely regression in the way that CMake emits
the plplot_EXPORTS macro when compiling libplplot and the
plplottcltk_EXPORTS when compiling libplplottcltk.  Furthermore, the
linker only gave an error message for one symbol, plplotLibDir.  That
is, visibility seems OK for everything but plplotLibDir.  Also

software@raven> find . -type f |grep -v .git |xargs grep -l plplotLibDir

tells me that symbol only occurs in

./bindings/tcl/tclAPI.c
./src/plctrl.c

in our source code.  If I understand the purpose of plplotLibDir
correctly, it allows libtcltk to get plLibOpenPdfstrm within libplplot
to open a particular file.

Anyhow, the visibility of plplotLibDir is implemented in an extremely
unique way in _both_ the above files, and it appears to me the use of
different _forms_ of visibility macros (i.e., PLDLLIMPEXP_TCLTK_DATA
in the former case and PLDLLIMPEXP in the latter case) is problematic
as well.

Linux tests of visibility that are normally made as part of my routine
testing on that platform are less demanding than the equivalent MSVC
tests. So if it turns out this is a long-term MSVC visibility issue
between libplottcltk and libplplot, I would carefully review the
plplotLibDir visibility implementation in the above two files to see
what might be problematic with it for the MSVC case.

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
__________________________