Hi Alan,
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Sunday, February 14, 2016 10:01 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] CMake-3.5.x works flawlessly on Linux so far
>
> On 2016-02-11 12:40-0800 Alan W. Irwin wrote:
>
> >
> > 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.
Hm, I hadn't seen this message. See below for the current result.
>
> Hi Arjen:
>
> Your recent (commit b94370e) fix for the above issue cannot be correct since
> it
> blocks all symbols from being exported from libplplottcltk which makes that
> library
> useless. So, for example, the result on Linux with
>
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>
...
>
> i.e., no symbols relevant to PLplot are available from that library as the
> direct result
> of your change. This problem in turn generates build errors such as
>
This is not what I see on "bare" Windows. There the pltcl shell runs fine with
the changes I made. Very annoying!
> [...]
> [100%] Linking C executable pltcl
> CMakeFiles/pltcl.dir/pltcl.c.o: In function `AppInit':
> pltcl.c:(.text+0x14a): undefined reference to `Pltcl_Init'
> collect2: error: ld returned 1 exit status
> bindings/tcl/CMakeFiles/pltcl.dir/build.make:99: recipe for target
> 'bindings/tcl/pltcl'
> failed
> make[3]: *** [bindings/tcl/pltcl] Error 1
> CMakeFiles/Makefile2:2069: recipe for target
> 'bindings/tcl/CMakeFiles/pltcl.dir/all'
> failed
> make[2]: *** [bindings/tcl/CMakeFiles/pltcl.dir/all] Error 2
> CMakeFiles/Makefile2:2081: recipe for target
> 'bindings/tcl/CMakeFiles/pltcl.dir/rule'
> failed
> make[1]: *** [bindings/tcl/CMakeFiles/pltcl.dir/rule] Error 2
> Makefile:845: recipe for target 'pltcl' failed
> make: *** [pltcl] Error 2
>
> I am virtually positive you will be able to confirm build issues with pltcl
> for MSVC as
> well for the same reason (no symbols exported from libplplottcltk).
>
> Such build issues interfere with those trying to follow the master branch so
> I have
> reverted your change as a temporary emergency measure (commit ca170c0).
>
> However, I think the only problem with your commit may be that you used too
> large
> a hammer (i.e., disabled all symbol visibility) to disable the visibility of
> the
> plplotLibDir symbol within libplplottcltk.
>
> Therefore, in a follow up commit (bbff8af) I tried disabling just the
> visibility of the
> plplotLibDir symbol within libplplottcltk. That change causes no build
> issues on
> Linux. Does that also fix the build issue on MSVC?
>
> Note my tests of bbff8af discovered a recently introduced matrix size issue
> with
> plpat for example 15 under Tcl, and when I locally disabled plpat to get by
> that error
> then there was an additional such issue (I have forgotten for which command)
> for
> example 18. (By the way, unlike what you intended these were actual errors
> concerning matrix size incompatibility rather than just warnings.) My Tcl
> abilities are
> not sufficient for solving these matrix size issues so I rely on you to do
> that. Note to
> find all such issues you must systematically exercise every Tcl example on
> MSVC
> by hand or else build the test_pltcl_standard_examples target on Cygwin,
> MinGW/MSYS, MinGW-w64/MSYS2, or Linux.
>
I will deal with the examples later - I discovered a flaw in example x01.tcl -
a mismatch between the declared size (101) and the actually used size (100)
that popped when I removed the (almost) superfluous size argument.
With the current source code as per your visibility change for plplotLibDir I
get this again:
[ 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.
I will have to carefully unravel this mystery, but I am not sure that I will
have time to complete that task before the end of the week (that is: before my
holiday).
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.
------------------------------------------------------------------------------
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
