Because plmetafile.c is experimental, we can swap out lround(...) with 
(short)ceil(...) for now. It appears that ceil is in VS 2012. I can code up 
something better after release. 



> On Mar 16, 2015, at 7:47 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
>> On 2015-03-16 15:10-0700 Alan W. Irwin wrote:
>> 
>>> On 2015-03-16 21:23+0100 laurent Berger wrote:
>>> 
>>> Hi,
>>> 
>>> I'm very happy to help you for testing.
>>> So I have clone :
>>> $ git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot
>>> Cloning into 'plplot-plplot'...
>>> remote: Counting objects: 85651, done.
>>> remote: Compressing objects: 100% (25299/25299), done.
>>> remote: Total 85651 (delta 63155), reused 81235 (delta 59337)
>>> Receiving objects: 100% (85651/85651), 118.99 MiB | 1.67 MiB/s, done.
>>> Resolving deltas: 100% (63155/63155), done.
>>> Checking connectivity... done.
>>> 
>>> After I have used cmake 3.1.2 with VS 2012 and windows 7 64 bits
>>> and I have got some errors. I think this one it's important :
>>> 9>     Création de la bibliothèque
>>> F:/Lib/test/plplot-plplot/build/dll/Debug/plplot.lib et de l'objet
>>> F:/Lib/test/plplot-plplot/build/dll/Debug/plplot.exp
>>> 29>plmetafile.obj : error LNK2019: symbole externe non résolu lround
>>> référencé dans la fonction read_line
>>> 29>F:\Lib\test\plplot-plplot\build\dll\Debug\plplot.dll : fatal error
>>> LNK1120: 1 externes non résolus
>> 
>> 
>>> All messages are (sorry it's a frenc VS 2012):
>> [....]
>> 
>> To Laurant, Arjen, and Phil:
>> 
>> @Laurent:
>> 
>> Thanks for your test report.
>> 
>> I am not familiar with VS 2012 or french (sorry about that!) so I
>> am having trouble interpreting those messages. So I will follow your 
>> suggestion that only
>> the above message (concerning what appears to be an unresolved read_line 
>> symbol) is important.
>> 
>> Here is everything relevant to read_line in our source code:
>> 
>> software@raven> find . -type f |grep -v .git |xargs grep read_line
>> ./src/plmetafile.c:// read_line()
>> ./src/plmetafile.c:enum _plm_status read_line( PDFstrm *plm, PLmDev *dev, 
>> PLStream *pls )
>> ./src/plmetafile.c:// read_lineto()
>> ./src/plmetafile.c:enum _plm_status read_lineto( PDFstrm *plm, PLmDev *dev, 
>> PLStream *pls )
>> ./src/plmetafile.c:            rc = read_line( plm, dev, pls );
>> ./src/plmetafile.c:            rc = read_lineto( plm, dev, pls );
>> ./src/plctrl.c:read_line( char *buffer, int length, FILE *fp );
>> ./src/plctrl.c:// read_line()
>> ./src/plctrl.c:read_line( char *buffer, int length, FILE *fp )
>> ./src/plctrl.c:            if ( read_line( color_info, COLLEN, fp ) == NULL )
>> ./src/plctrl.c:    if ( read_line( color_info, PALLEN, fp ) == NULL )
>> ./src/plctrl.c:        if ( read_line( color_info, PALLEN, fp ) == NULL )
>> ./src/plctrl.c:            if ( read_line( color_info, PALLEN, fp ) == NULL )
>> ./src/plctrl.c:            if ( read_line( color_info, PALLEN, fp ) == NULL )
>> 
>> Looking further at plmetafile.c and plctrl.c it appears there are two
>> completely different static read_line functions, and I am wondering if
>> the Windows compiler is confusing them because of that name clash.  A
>> definite issue is the plmetafile.c version is not declared anywhere,
>> and that might be confusing the Windows compiler/linker.
>> 
>> Anyhow, in plmetafile.c could you try inserting a declaration for
>> read_line and/or change the name (throughout that file) to
>> something else, e.g., plmeta_read_line to remove the name clash with
>> the read_line used in plctrl.c?
>> 
>> @Arjen and Phil:
>> 
>> As far as I am concerned, a build issue like this one is release
>> critical.  Therefore, can you confirm this issue on the Windows
>> platforms you have access to and/or the possible fixes I am
>> suggesting?
> 
> From my further reading, my two suggested "fixes" above should not
> be required because static function names are completely local
> to the source file where they occur, and function declarations
> do not have to be done with a function prototype in C, and
> instead, the declaration can be done with the
> function definition so long as that definition occurs before
> any use of the static function (as for read_line in
> plmetafile.c above).
> 
> So I am completely at a loss to explain this build error, but I
> now have noticed Laurant's subsequent post where he said
> 
> "with vs2013 there is no problem".
> 
> So this appears not to be a release-critical issue for us and
> instead appears to be an issue with vs2012.
> 
> @ Arjen and Phil:
> 
> If you guys can confirm the bad build results on vs2012
> and good build results on vs2013, we should probably say
> something in the release notes to warn users against vs2012
> unless it is already well-known that vs2012 is an unreliable
> build platform in general.
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to