On 2016-02-11 13:51-0000 Arjen Markus wrote: > Hi Alan, > > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] >> 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
