plplot-general — PLplot user discussion group

[Plplot-general] problems with using Dll in VC++.net

[Ruwei L. <rw...@ph...>]

Hi, all

     I'm trying to use plplot library for a project. It works fine with 
the static library , but it fails to
link when I using the dynamic library. I got the following error message:

         ------ Build started: Project: Tplot, Configuration: Debug 
Win32 ------

    Linking...
    LINK : error LNK2020: unresolved token (0A0000B3) plD_dispatch_init_null
    LINK : error LNK2020: unresolved token (0A0000B4) plD_dispatch_init_gif
    LINK : error LNK2020: unresolved token (0A0000B5) plD_dispatch_init_jpeg
    LINK : error LNK2020: unresolved token (0A0000B6) plD_dispatch_init_png
    LINK : error LNK2020: unresolved token (0A0000B7) plD_dispatch_init_ljii
    LINK : error LNK2020: unresolved token (0A0000B8) 
plD_dispatch_init_ljiip
    LINK : error LNK2020: unresolved token (0A0000B9) plD_dispatch_init_xfig
    LINK : error LNK2020: unresolved token (0A0000BA) plD_dispatch_init_psc
    LINK : error LNK2020: unresolved token (0A0000BB) plD_dispatch_init_psm
    LINK : error LNK2020: unresolved token (0A0000BC) plD_dispatch_init_plm
    LINK : error LNK2020: unresolved token (0A0000BD) plD_dispatch_init_win3
    LINK : fatal error LNK1120: 11 unresolved externals

    Tplot - 12 error(s), 0 warning(s)

     I did put the "plplotd.lib", "plplotd.def", "plplotd.exp" and 
"plplotd.dll" to the project directory, link
to "plplotd.lib", and also defined "__PLDLL_H__", is there anything I'm 
still missing?

   Any help or hint will be greatly appreciated.

   Thanks

   Ruwei Liu



   

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

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

On 2006-05-24 11:39-0600 Orion Poplawski wrote:

> Orion Poplawski wrote:
>> Alan W. Irwin wrote:
>>> 
>>> You are the first to report this problem.  The python examples certainly
>>> work on my two systems (Ubuntu Breezy with Python 2.4.2/Numeric-23.8 and
>>> Debian stable with Python 2.3.5/Numeric-23.8). What is your version of
>>> Python _and_ Numeric? 
>> 
>> Indeed, I don't see the problem on Fedora 5.  Devel has python 2.4.3 and 
>> Numeric 23.7.  5 has python 2.4.2 and Numeric 23.7.  I'll poke around some 
>> more.
>> 
>
> Confirmed as an issue with Numeric 23.7 and python 2.4.3.  Updating to 24.2 
> fixes so I've filed a bug with Fedora to try to get it updated.
>
> Any plans to move to numpy?

Not unless and until it gets better supported by distributions.  I just
checked Ubuntu dapper packages (which is also effectively a search of Debian
unstable), and I can find no sign of it there.  Just the older Numeric
(which confusingly was called numpy originally which is quite different from
the modern NumPy) and NumArray.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

[Orion P. <or...@co...>]

Orion Poplawski wrote:
> Alan W. Irwin wrote:
>>
>> You are the first to report this problem.  The python examples certainly
>> work on my two systems (Ubuntu Breezy with Python 2.4.2/Numeric-23.8 and
>> Debian stable with Python 2.3.5/Numeric-23.8). What is your version of
>> Python _and_ Numeric?  
> 
> Indeed, I don't see the problem on Fedora 5.  Devel has python 2.4.3 and 
> Numeric 23.7.  5 has python 2.4.2 and Numeric 23.7.  I'll poke around 
> some more.
> 

Confirmed as an issue with Numeric 23.7 and python 2.4.3.  Updating to 
24.2 fixes so I've filed a bug with Fedora to try to get it updated.

Any plans to move to numpy?

-- 
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301   http://www.co-ra.com

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

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

On 2006-05-22 00:06+0200 steven mestdagh wrote:

> With 5.6.0, I had some problems with the pstex driver.
>
> I get a SIGSEGV (on OpenBSD), which can be prevented by the following
> patch. However, the resulting .eps_t file does not contain any label text.
> So maybe there is a better fix?
>
> steven
>
> --- drivers/pstex.c.orig	Mon Jan 19 20:10:19 2004
> +++ drivers/pstex.c	Mon Apr 17 01:34:40 2006
> @@ -260,6 +261,11 @@ parse_str(const char *str, char *dest)
> 		       "psi", "Psi", "omega", "Omega"};
>
>   plgesc(&esc);
> +
> +  if (str == NULL) {
> +    *tp = '\0';
> +    return;
> +  }
>
>   while (*str) {
>

I confirm segfaults on both Debian Stable and Ubuntu Breezy as well.  So it
appears some bit rot has set in.

There was an overview of the purpose of the pstex device driver in 2001 list
mail which indicated it was designed to short-circuit the process of using
-dev xfig, importing the result to xfig, and exporting the result to latex.
But I am not sure that short-circuit is of much utility any more since the
only purpose of the short-circuit, as far as I know, was to get access to
some Type 1 fonts.  Other than a spattering of 2001 list mail (which is no
longer available to anybody unless they saved it at the time), the pstex
device driver is undocumented.

Those nice-looking fonts did impress me in 2001, but we have long since had
those completely supported in the ps device driver, and now we have
introduced powerful new Complex Text Layout (CTL) and TrueType font
capability with the psttf device driver. Also, it is completely
straightforward to import either ps or psttf results into latex documents.

Thus, I am largely convinced the pstex device is not worth supporting any
more especially since nobody else has responded to this bug report or my
off-list question to other PLplot core developers about this device. So
unless someone surprises me in the next 24 hours and volunteers to support
this device, I have decided to completely disable its build on Unix systems
for 5.6.1 while keeping the pstex.c code still available in CVS and the
distribution tarball.  This change should allow anybody who is still keen on
pstex to fix that code in the future while discouraging anybody from
attempting to build it when we know it segfaults.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Re: [Plplot-devel] PLplot 5.6.1 Release Candidate 1

[Koen v. d. D. <kvd...@ea...>]

On May 21, 2006, at 2:00 PM, hba...@ma... wrote:

>
> This is a *test* release for the final version of PLplot 5.6.1. If  
> you have the time & the inclination, please download it and let us  
> know if does/does not work on your system of choice.


Builds fine on OS X using fink (ppc, 10.4 tree):

host:           powerpc-apple-darwin
have_x:         yes
prefix:         /sw
CC CFLAGS:      gcc -Wno-long-double
CXX CXXFLAGS:   g++ -g -O2
F77 FFLAGS:     gfortran -g -O2
FC FCFLAGS:     gfortran -g -O2
LIB_TAG:        d
devices:         aqt png jpeg gif hp7470 hp7580 lj_hpgl mem null pbm  
plmeta ps pstex tk xfig xwin

Available device drivers:
static:
dynamic:        aqt.la gd.la hpgl.la mem.la null.la pbm.la plmeta.la  
ps.la pstex.la tk.la xfig.la xwin.la

Compilation options:
with_debug:     no

Library options:
enable_shared:  yes             enable_static:  yes
with_rpath:     no              with_double:    yes

Optional libraries:
with_qhull:     yes             with_csa:       yes
with_freetype:  yes             with_pthreads:  no

Language Bindings:
enable_f77:     yes             enable_f95:     yes
enable_cxx:     yes             enable_java:    yes
enable_python:  yes             enable_octave:  yes
enable_tcl:     yes             enable_itcl:    no
enable_pdl:     no

Also no problems with the examples.

- Koen.

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

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

On 2006-05-22 16:57-0500 Geoffrey Furnish wrote:

> Alan W. Irwin writes:
> > Orion Poplawski wrote:
> > > Finally, I guess I should have weighed in earlier on the debate about
> > > where to put the fortran .mod files earlier, but I'm not sure I'm happy
> > > about /usr/lib/fortran/modules/plplot.  Why so many subdirs?  Why not
> > > just /usr/lib/plplot?  The former makes for more work for distribution
> > > makers (who owns /usr/lib/fortran?).
> >
> > At this point, I don't think the Linux community has really come to grips
> > with this fortran 95 install location issue since it is only recently that
> > libre fortran 95 compilers (gfortran and g95) became viable solutions. The
> > fortran part of the above install location was recommended in a generic
> > way by someone on the Linux File Hierarchy Standards list, but that is
> > certainly not an official decision and they may change their minds
> > later. The modules part of it was my invention to be more informative, but
> > if that turns out to be a major problem we can certainly move to
> > /usr/lib/fortran/plplot in the future or anything else that finally
> > becomes officially recommended by the LFHS group.  For now, though, I
> > think we should just stick with what we have.
>
> ???  Maybe I put my foot in the wrong place on that.  I thought I had
> registered support for putting the Fortran modules under the $prefix.

Correction: By default it goes under $prefix/lib/fortran/modules/plplot
(which translates to what Orion and I said above for prefix = /usr).  So
you have full control of the prefix with the --prefix configure option.

However, there are a lot more possibilities then this prefix default which
you can check out by looking at the libdir (and other *dir) documentation
using ./configure --help.  I have checked that --libdir actually works for
PLplot.  As I said when I commented on that good result before, Geoffrey,
your disambiguation problems are probably over if you use some of those *dir
configure options.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

[Geoffrey F. <fu...@li...>]

Alan W. Irwin writes:
 > Orion Poplawski wrote:
 > > Finally, I guess I should have weighed in earlier on the debate about
 > > where to put the fortran .mod files earlier, but I'm not sure I'm happy
 > > about /usr/lib/fortran/modules/plplot.  Why so many subdirs?  Why not
 > > just /usr/lib/plplot?  The former makes for more work for distribution
 > > makers (who owns /usr/lib/fortran?).
 > 
 > At this point, I don't think the Linux community has really come to grips
 > with this fortran 95 install location issue since it is only recently that
 > libre fortran 95 compilers (gfortran and g95) became viable solutions. The
 > fortran part of the above install location was recommended in a generic
 > way by someone on the Linux File Hierarchy Standards list, but that is
 > certainly not an official decision and they may change their minds
 > later. The modules part of it was my invention to be more informative, but
 > if that turns out to be a major problem we can certainly move to
 > /usr/lib/fortran/plplot in the future or anything else that finally
 > becomes officially recommended by the LFHS group.  For now, though, I
 > think we should just stick with what we have.

???  Maybe I put my foot in the wrong place on that.  I thought I had
registered support for putting the Fortran modules under the $prefix.

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

[Orion P. <or...@co...>]

Alan W. Irwin wrote:
> Thanks, Orion, for your report.  Comments in context below....Alan
> 
> Generally, we have found you must specify F77=f95 (or whatever is
> appropriate for your fortran 95 compiler) if there is a fortran 77 compiler
> installed.

Okay, that's the case here.  f77 is not installed.

> 
> You are the first to report this problem.  The python examples certainly
> work on my two systems (Ubuntu Breezy with Python 2.4.2/Numeric-23.8 and
> Debian stable with Python 2.3.5/Numeric-23.8). What is your version of
> Python _and_ Numeric?  

Indeed, I don't see the problem on Fedora 5.  Devel has python 2.4.3 and 
Numeric 23.7.  5 has python 2.4.2 and Numeric 23.7.  I'll poke around 
some more.


-- 
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301   http://www.co-ra.com

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

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

Thanks, Orion, for your report.  Comments in context below....Alan

On 2006-05-22 11:39-0600 Orion Poplawski wrote:

> Alan W. Irwin wrote:
>> 
>> PREFIX is my chosen install prefix (/usr/local/plplot in my case). If you
>> --enable-f95, F77 must be set to whatever is appropriate for your fortran 
>> 95
>> compiler which was f95 in my particular case. 
>
>  Compiling on Fedora Core Development I do not appear to need to specify 
> F77=f95.  What problems did you see when you omitted it?  I don't see the 
> extra "yes" after the "accepts -g" check, and no obvious errors.

Generally, we have found you must specify F77=f95 (or whatever is
appropriate for your fortran 95 compiler) if there is a fortran 77 compiler
installed.  The explanation I got on the libtool list was fortran 77
compilers tended to mess up the fortran 95 settings so setting F77 cuts the
fortran 77 compiler completely out of the loop to get around this. So we
have just gotten in the habit of setting F77. But that proved necessary on
most platforms for a slightly different version of our fortran configuration
that has been changed since so it is possible this problem has been fixed
and setting F77 is no longer required.

Since Orion's platform did not need the F77 setting, I ask anybody else who
tests this to let me know whether setting F77 is absolutely necessary
anymore on any platform.  If this workaround were no longer necessary on any
platform, that would be excellent news.

>
>> 
>> After the build and install I did the usual test of compiling the 
>> installed
>> examples and testing them:
>> 
>> cp -a $prefix/share/plplot5.6.1_RC1/examples/ /tmp/examples
>> cd /tmp/examples
>> make
>> ./plplot-test.sh script
>> 
>> Spot checks of the resulting 162 (!) postscript files looked good, and a
>> comprehensive check showed these postscript results were identical with
>> previous ones.
>
> Most of them look good, except:
>
> Testing front-end python
> Traceback (most recent call last):
>  File "/builddir/build/BUILD/plplot-5.6.1_RC1/test/../examples/python/x03", 
> line 36, in
> ?
>    import xw03
>  File "/builddir/build/BUILD/plplot-5.6.1_RC1/examples/python/xw03.py", line 
> 63, in ?
>    main()
>  File "/builddir/build/BUILD/plplot-5.6.1_RC1/examples/python/xw03.py", line 
> 21, in main
>    i.shape = (-1,1)
> ValueError: can only specify one unknown dimension
>
> Seen in xw03.py, 08, 09, 11, 15, 16, 18, 22

You are the first to report this problem.  The python examples certainly
work on my two systems (Ubuntu Breezy with Python 2.4.2/Numeric-23.8 and
Debian stable with Python 2.3.5/Numeric-23.8). What is your version of
Python _and_ Numeric?  Fedora is notoriously cutting edge so is it possible
you are using one of the Numeric successors such as Numarray or NumPy? The
NumPy project advertises themselves (see
http://numeric.scipy.org/#older_array) as the ultimate successor to Numeric
and Numarray, but I don't know how much they have convinced others of this.
At some point I may move us to NumPy, but I really haven't had time to
investigate whether NumPy has good distribution support.  For now, I know
Numeric does have that support (with the possible exception of Fedora), so
that is why I am sticking with Numeric for now.

>
> Also, I still got:
>
> PASS: plplot-test.sh
> ==================
> All 1 tests passed
> ==================
>
> even with the above errors.

That is not right.  However, I don't maintain the complicated make check
logic myself (the installed examples test I advocate above has much simpler
logic behind it) so somebody else will have to do the fix.

>
>
> Finally, I guess I should have weighed in earlier on the debate about where 
> to put the fortran .mod files earlier, but I'm not sure I'm happy about 
> /usr/lib/fortran/modules/plplot.  Why so many subdirs?  Why not just 
> /usr/lib/plplot?  The former makes for more work for distribution makers (who 
> owns /usr/lib/fortran?).

At this point, I don't think the Linux community has really come to grips
with this fortran 95 install location issue since it is only recently that
libre fortran 95 compilers (gfortran and g95) became viable solutions. The
fortran part of the above install location was recommended in a generic way
by someone on the Linux File Hierarchy Standards list, but that is certainly
not an official decision and they may change their minds later. The modules
part of it was my invention to be more informative, but if that turns out to
be a major problem we can certainly move to /usr/lib/fortran/plplot in the
future or anything else that finally becomes officially recommended by the
LFHS group.  For now, though, I think we should just stick with what we
have.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

[Orion P. <or...@co...>]

Alan W. Irwin wrote:
> 
> PREFIX is my chosen install prefix (/usr/local/plplot in my case). If you
> --enable-f95, F77 must be set to whatever is appropriate for your 
> fortran 95
> compiler which was f95 in my particular case.  

   Compiling on Fedora Core Development I do not appear to need to 
specify F77=f95.  What problems did you see when you omitted it?  I 
don't see the extra "yes" after the "accepts -g" check, and no obvious 
errors.

> 
> After the build and install I did the usual test of compiling the installed
> examples and testing them:
> 
> cp -a $prefix/share/plplot5.6.1_RC1/examples/ /tmp/examples
> cd /tmp/examples
> make
> ./plplot-test.sh script
> 
> Spot checks of the resulting 162 (!) postscript files looked good, and a
> comprehensive check showed these postscript results were identical with
> previous ones.

Most of them look good, except:

Testing front-end python
Traceback (most recent call last):
   File 
"/builddir/build/BUILD/plplot-5.6.1_RC1/test/../examples/python/x03", 
line 36, in
?
     import xw03
   File 
"/builddir/build/BUILD/plplot-5.6.1_RC1/examples/python/xw03.py", line 
63, in ?
     main()
   File 
"/builddir/build/BUILD/plplot-5.6.1_RC1/examples/python/xw03.py", line 
21, in main
     i.shape = (-1,1)
ValueError: can only specify one unknown dimension

Seen in xw03.py, 08, 09, 11, 15, 16, 18, 22

Also, I still got:

PASS: plplot-test.sh
==================
All 1 tests passed
==================

even with the above errors.


Finally, I guess I should have weighed in earlier on the debate about 
where to put the fortran .mod files earlier, but I'm not sure I'm happy 
about /usr/lib/fortran/modules/plplot.  Why so many subdirs?  Why not 
just /usr/lib/plplot?  The former makes for more work for distribution 
makers (who owns /usr/lib/fortran?).

Otherwise, everything looks great.  Good work everyone.

-- 
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301   http://www.co-ra.com

[Plplot-general] Re: [Plplot-devel] PLplot 5.6.1 Release Candidate 1

[Arjen M. <arj...@wl...>]

hba...@ma... wrote:

>
> Hello,
>
> Release candidate #1 for PLplot 5.6.1 is now available for download at:
>
> http://sourceforge.net/project/showfiles.php?group_id=2915
>
> This is a *test* release for the final version of PLplot 5.6.1. If  
> you have the time & the inclination, please download it and let us  
> know if does/does not work on your system of choice.

Yesterday, working in my development tree, I found two problems on 
Cygwin and one on Windows:

Cygwin:
1. There is a problem with gfortran and shared libraries: I have to 
disable shared libraries to get the
    examples to build properly. I have reported the bug (you get 
messages about duplicate gfortran symbols
    during the link phase). But disabling the shared libraries makes the 
error go away. Unfortunate, but
    at least there is a workaround.

2. The auxiliary program plflt does not get built properly. I have 
stared at the generated makefile,
    but the rule to make plflt$(EXEEXT) from $plflt_OBJECTS is _not_ 
followed (all looks okay
    to me, but the program is being built directly).
    The very ugly workaround is:
    % make
    % gcc -o plflt plft.c -I../../include
    % ./plflt
    % make

    Can anyone have a look at this? (I added a line to define 
plflt_CFLAGS in Makefile.am
    but this did not solve the issue - of course it wouldn't: make takes 
a default rule rather
    than the rule it should take)

Windows:
3. The DLL version does not compile at the moment - changes in the API 
(plrgbhls, ...)
    that are not reflected in the stubs for the DLL version. The static 
version works splendidly.

I do not know when I will have time to solve issue 3 - maybe tomorrow. 
Issue 2 is really puzzling
Issue 1 is out of our control.

Regards,

Arjen

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

[steven m. <ste...@es...>]

hba...@ma... [2006-05-21, 14:00:22]:
> 
> Hello,
> 
> Release candidate #1 for PLplot 5.6.1 is now available for download at:
> 
> http://sourceforge.net/project/showfiles.php?group_id=2915
> 
> This is a *test* release for the final version of PLplot 5.6.1. If  
> you have the time & the inclination, please download it and let us  
> know if does/does not work on your system of choice.

With 5.6.0, I had some problems with the pstex driver.

I get a SIGSEGV (on OpenBSD), which can be prevented by the following
patch. However, the resulting .eps_t file does not contain any label text.
So maybe there is a better fix?

steven

--- drivers/pstex.c.orig	Mon Jan 19 20:10:19 2004
+++ drivers/pstex.c	Mon Apr 17 01:34:40 2006
@@ -260,6 +261,11 @@ parse_str(const char *str, char *dest)
 		       "psi", "Psi", "omega", "Omega"};
 
   plgesc(&esc);
+
+  if (str == NULL) {
+    *tp = '\0';
+    return;
+  }
 
   while (*str) {
 

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

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

On 2006-05-21 21:11+0200 steven mestdagh wrote:

> hba...@ma... [2006-05-21, 14:00:22]:
>>
>> Hello,
>>
>> Release candidate #1 for PLplot 5.6.1 is now available for download at:
>>
>> http://sourceforge.net/project/showfiles.php?group_id=2915
>>
>> This is a *test* release for the final version of PLplot 5.6.1. If
>> you have the time & the inclination, please download it and let us
>> know if does/does not work on your system of choice.
>
> even if f95 is disabled, the installation still creates the directory
> $(libdir)/fortran/modules/plplot

Thanks, Steven, for spotting that.  Fixed in cvs (and therefore in the final
release).

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

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

On 2006-05-21 14:00-0400 hba...@ma... wrote:

>
> Hello,
>
> Release candidate #1 for PLplot 5.6.1 is now available for download at:
>
> http://sourceforge.net/project/showfiles.php?group_id=2915
>
> This is a *test* release for the final version of PLplot 5.6.1. If you have 
> the time & the inclination, please download it and let us know if does/does 
> not work on your system of choice.

Thanks, Hazen.

Your new release candidate tarball, plplot-5.6.1_RC1.tar.gz, works for me.

I will describe some details for the benefit of PLplot users that want
to give this a try.

My Ubuntu Breezy system has been loaded up with all the development packages
(e.g., Tcl, free java, octave, gfortran) required to take advantage of
virtually all language interfaces and device drivers of PLplot that are
accessible from Linux.  The build and install was accomplished as follows:

./configure --prefix=$PREFIX --disable-static --enable-f95 F77=f95 \
--with-prebuiltdoc >& configure.out
make >& make.out
make install >& make_install.out

PREFIX is my chosen install prefix (/usr/local/plplot in my case). If you
--enable-f95, F77 must be set to whatever is appropriate for your fortran 95
compiler which was f95 in my particular case.  Although not necessary in my
case, you might also have to set FFLAGS to to whatever is appropriate for
FCFLAGS.  These --enable-f95 workarounds should not be necessary when we can
base our release on libtool-2.0 (scheduled for release later this year). The
--with-prebuiltdoc option allows me to browse the new documentation
(including the initial cut at some fortran 95 documentation) at 
$PREFIX/share/doc/plplot/html/index.html.

After the build and install I did the usual test of compiling the installed
examples and testing them:

cp -a $prefix/share/plplot5.6.1_RC1/examples/ /tmp/examples
cd /tmp/examples
make
./plplot-test.sh script

Spot checks of the resulting 162 (!) postscript files looked good, and a
comprehensive check showed these postscript results were identical with
previous ones.

So 5.6.1 release candidate 1 is looking good on Ubuntu Breezy, and I
strongly encourage RC1 reports from our users (going through all the steps
above) to make sure 5.6.1 gets comprehensively tested on as wide a variety
of platforms as possible before it is released in final form.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot 5.6.1 Release Candidate 1

[steven m. <ste...@es...>]

hba...@ma... [2006-05-21, 14:00:22]:
> 
> Hello,
> 
> Release candidate #1 for PLplot 5.6.1 is now available for download at:
> 
> http://sourceforge.net/project/showfiles.php?group_id=2915
> 
> This is a *test* release for the final version of PLplot 5.6.1. If  
> you have the time & the inclination, please download it and let us  
> know if does/does not work on your system of choice.

even if f95 is disabled, the installation still creates the directory
$(libdir)/fortran/modules/plplot

steven

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Plplot-general] PLplot 5.6.1 Release Candidate 1

[<hba...@ma...>]

Hello,

Release candidate #1 for PLplot 5.6.1 is now available for download at:

http://sourceforge.net/project/showfiles.php?group_id=2915

This is a *test* release for the final version of PLplot 5.6.1. If  
you have the time & the inclination, please download it and let us  
know if does/does not work on your system of choice.

best,
-Hazen

Re: [Plplot-general] f95-support

[Valery P. <pi...@is...>]

> Good.  That makes four (actually probably five) platforms where gfortran is
> working.
I've successfully   compiled plplot with f95 bindings on kubuntu-dapper which 
has  gfortran-4.0.1 currently.
> > The common blocks is obsolete in F90-95. I would recommend to  use
> > "USE" .
>
> Noted, but not implemented yet.  I would like to change this whole area of
> the API to use proper callbacks (where the API of the function or
> subroutine name being passed as an argument of the library routine is fully
> specified). Is this C-like approach available in fortran 95 (perhaps with
> the interface statement)?  
This is  a kind of hard question to  me because I've never  used  interface 
statements  in my practice.   
>
> > This experiment was on altlinux where we have gfortran-4.1.  I shall
> > check my dapper part this afternoon.
> >
> > For intel fortran I've get the linkage error:
> > /bin/sh ../../libtool --mode=link ifort -I. -O3   -o
>
> ....
>
> I don't want to discourage you; your experiments with ifort may eventually
> pay off.
> However, from what I have heard from the libtool experts, we are 
> limited to just gfortran for now because libtool is not yet ready for full
> fortran 9x support.  Once libtool is improved in this respect (hopefully
> within a few months from now), then the plplot fortran 95 interface should
> be able to support commercial fortran compilers such as ifort, pgf90, and
> the absoft fortran compiler.
Yes that's a way,

best regards
Valery

Re: [Plplot-general] f95-support

[Arjen M. <arj...@wl...>]

Alan W. Irwin wrote:

>
> Noted, but not implemented yet.  I would like to change this whole 
> area of
> the API to use proper callbacks (where the API of the function or 
> subroutine
> name being passed as an argument of the library routine is fully 
> specified).
> Is this C-like approach available in fortran 95 (perhaps with the 
> interface
> statement)?  If so, then a number of different routines (e.g., plcon0,
> plcon1, etc) could be replaced by one routine (plcont) in the fortran 95
> interface, and there will be no more need for the common block.

The F95 bindings as I had them were incomplete at two points;
- two-dimensional arrays like for plgriddata(), actually pointers to arrays
- functions that take other functions as arguments

The first can be solved at the C side.
The second can be solved by appropriate explicit interfaces (so that
the compiler can detect mismatches in the interfaces) and, if needed,
a small C wrapper.

That is something I want to realise the coming few days.

Regards,

Arjen

Re: [Plplot-general] f95-support

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

On 2006-05-15 14:20+0900 Valery Pipin wrote:

> After export F77=3Dgfortran export FC=3Dgfortran and
> export F77FLAGS=3D'-O3' export FCFLAGS=3D'-O3'
>
> I've get
> /bin/sh ../../libtool --mode=3Dcompile gfortran -I. -O3 -c -o sfstubsf95.=
lo
> sfstubsf95.f95
> gfortran -I. -O3 -c sfstubsf95.f95  -fPIC -o .libs/sfstubsf95.o
> In file sfstubsf95.f95:69
>
>      module plplot
>                  1
> In file sfstubs.f95:227
>
>     Included at sfstubsf95.f95:66
>
>      common /plplot/ tr
>                    2
> Error: Global name 'plplot' at (1) is already being used as a COMMON at (=
2)
> make[4]: *** [sfstubsf95.lo] =EF=DB=C9=C2=CB=C1 1
>
> Then I replaced the corresponding  name of common block in   sfstubs.f95
> from  common /plplot/ to  common /plplot1/.
> After this compilation and checks  for f95 goes smoothly.

Good.  That makes four (actually probably five) platforms where gfortran is
working.  I have just now put in a similar fix for the nameclash into CVS i=
n
response to somebody else's report on the plplot-devel list.  When it
becomes available for anon cvs (bindings/f95/sfstubs.f and some of the
fortran 95 examples should change), please try it out.

> The common blocks is obsolete in F90-95. I would recommend to  use
> "USE" .

Noted, but not implemented yet.  I would like to change this whole area of
the API to use proper callbacks (where the API of the function or subroutin=
e
name being passed as an argument of the library routine is fully specified)=
=2E
Is this C-like approach available in fortran 95 (perhaps with the interface
statement)?  If so, then a number of different routines (e.g., plcon0,
plcon1, etc) could be replaced by one routine (plcont) in the fortran 95
interface, and there will be no more need for the common block.

> This experiment was on altlinux where we have gfortran-4.1.  I shall chec=
k my
> dapper part this afternoon.
>
> For intel fortran I've get the linkage error:
> /bin/sh ../../libtool --mode=3Dlink ifort -I. -O3   -o
=2E...

I don't want to discourage you; your experiments with ifort may eventually
pay off.  However, from what I have heard from the libtool experts, we are
limited to just gfortran for now because libtool is not yet ready for full
fortran 9x support.  Once libtool is improved in this respect (hopefully
within a few months from now), then the plplot fortran 95 interface should
be able to support commercial fortran compilers such as ifort, pgf90, and
the absoft fortran compiler.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] f95-support

[Valery P. <pi...@is...>]

After export F77=gfortran export FC=gfortran and
 export F77FLAGS='-O3' export FCFLAGS='-O3'

I've get
/bin/sh ../../libtool --mode=compile gfortran -I. -O3 -c -o sfstubsf95.lo 
sfstubsf95.f95
 gfortran -I. -O3 -c sfstubsf95.f95  -fPIC -o .libs/sfstubsf95.o
 In file sfstubsf95.f95:69

      module plplot
                  1
 In file sfstubs.f95:227

     Included at sfstubsf95.f95:66

      common /plplot/ tr
                    2
Error: Global name 'plplot' at (1) is already being used as a COMMON at (2)
make[4]: *** [sfstubsf95.lo] Ошибка 1

Then I replaced the corresponding  name of common block in   sfstubs.f95
from  common /plplot/ to  common /plplot1/.
After this compilation and checks  for f95 goes smoothly.  
The common blocks is obsolete in F90-95. I would recommend to  use
"USE" .

This experiment was on altlinux where we have gfortran-4.1.  I shall check my 
dapper part this afternoon. 

For intel fortran I've get the linkage error:
/bin/sh ../../libtool --mode=link ifort -I. -O3   -o 
libplplotf95d.la -rpath /usr/local/lib -version-info 
0:0:0 -rpath /usr/local/lib -no-undefined libplplotf95cd.la strutil.lo 
configurable.lo sfstubsf95.lo
ifort -shared -nofor_main  .libs/strutil.o .libs/configurable.o .libs/sfstubsf95.o  -Wl,--rpath -Wl,/home/vv/RPM/RPMS/plplot/bindings/f95/.libs -Wl,--rpath -Wl,/usr/local/lib ./.libs/libplplotf95cd.so  -Wl,-soname -Wl,libplplotf95d.so.0 -o .libs/libplplotf95d.so.0.0.0
IPO link: can not find ".libs/strutil.o"
ifort: error: problem during multi-file optimization compilation (code 1)

I don't know  how to switch "ipo" option  off.


best regards
Valery  

Re: [Plplot-general] ANNOUNCEMENT: PLplot Release 5.6.0

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

On 2006-05-14 16:38+0900 Valery Pipin wrote:

> Hello Alan,
>
> I've tried to build plplot with f95 support from cvs distribution.
> I've got error for building f95 libraries:
> ................
> gcc -shared  .libs/sc3d.o .libs/sccont.o .libs/scstubs.o  -Wl,--rpath -Wl,/home2/vv/RPM/BUILD/plplot/src/.libs -Wl,--rpath -Wl,/usr/local/lib ../../src/.libs/libplplotd.so  -mieee-fp -Wl,-soname -Wl,libplplotf95cd.so.0 -o .libs/libplplotf95cd.so.0.0.0
> (cd .libs && rm -f libplplotf95cd.so.0 && ln -s libplplotf95cd.so.0.0.0
> libplplotf95cd.so.0)
> (cd .libs && rm -f libplplotf95cd.so && ln -s libplplotf95cd.so.0.0.0
> libplplotf95cd.so)
> ar cru .libs/libplplotf95cd.a  sc3d.o sccont.o scstubs.o
> ranlib .libs/libplplotf95cd.a
> creating libplplotf95cd.la
> (cd .libs && rm -f libplplotf95cd.la && ln -s ../libplplotf95cd.la
> libplplotf95cd.la)
> /bin/sh ../../libtool --mode=compile f95 -I. -g -O2 -c -o strutil.lo
> strutil.f95
> libtool: compile: unable to infer tagged configuration
> libtool: compile: specify a tag with `--tag'
> make[4]: *** [strutil.lo] Error 1
> make[4]: Leaving directory `/home2/vv/RPM/BUILD/plplot/bindings/f95'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory `/home2/vv/RPM/BUILD/plplot/bindings/f95'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home2/vv/RPM/BUILD/plplot/bindings'
>
> Something is wrong with libtool. I've get this error on altlinux and on
> ubuntu-dapper as well.

So far, I am the only person that has been successful with it.  There are
lots more reports like yours on plplot-devel.  However, because of my
success we hope to find a small tweak that will allow building the f95
interface on more than just my platform.  My platform (Ubuntu Breezy with
gfortran-4.0.1) had no g77 installed.  (g77 tends to confuse issues with
gfortran.) To emulate that, be sure to set the F77 and F95 environment
variables to be the same as FC and FCFLAGS. (Those variables are reported in
config.summary).  Also, be sure that gfortran is installed. (/usr/bin/f95
symlinks to gfortran on my system.) My experience is that the gfortran
compiler is fine for compiling both our f77 and f95 interfaces. Finally, you
might want to try the --tag=F77 option for the above libtool command to see
if that variation works by hand.

I will be most interested to hear of any tweak success/failures to follow
what happens on my platform, i.e., both the f77 and f95 interfaces are built
by gfortran with no problems.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] ANNOUNCEMENT: PLplot Release 5.6.0

[Valery P. <pi...@is...>]

Hello Alan,

I've tried to build plplot with f95 support from cvs distribution.
I've got error for building f95 libraries:
................
gcc -shared  .libs/sc3d.o .libs/sccont.o .libs/scstubs.o  -Wl,--rpath -Wl,/home2/vv/RPM/BUILD/plplot/src/.libs -Wl,--rpath -Wl,/usr/local/lib ../../src/.libs/libplplotd.so  -mieee-fp -Wl,-soname -Wl,libplplotf95cd.so.0 -o .libs/libplplotf95cd.so.0.0.0
(cd .libs && rm -f libplplotf95cd.so.0 && ln -s libplplotf95cd.so.0.0.0 
libplplotf95cd.so.0)
(cd .libs && rm -f libplplotf95cd.so && ln -s libplplotf95cd.so.0.0.0 
libplplotf95cd.so)
ar cru .libs/libplplotf95cd.a  sc3d.o sccont.o scstubs.o
ranlib .libs/libplplotf95cd.a
creating libplplotf95cd.la
(cd .libs && rm -f libplplotf95cd.la && ln -s ../libplplotf95cd.la 
libplplotf95cd.la)
/bin/sh ../../libtool --mode=compile f95 -I. -g -O2 -c -o strutil.lo 
strutil.f95
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make[4]: *** [strutil.lo] Error 1
make[4]: Leaving directory `/home2/vv/RPM/BUILD/plplot/bindings/f95'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home2/vv/RPM/BUILD/plplot/bindings/f95'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home2/vv/RPM/BUILD/plplot/bindings'

Something is wrong with libtool. I've get this error on altlinux and on 
ubuntu-dapper as well. 

I've updated plplot's cvs tree at Sunday afternoon (Irkutsk time)

best regards,
Valery

Re: [Plplot-general] ANNOUNCEMENT: PLplot Release 5.6.0

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

On 2006-05-10 20:00+0900 Valery Pipin wrote:

> Thank you very much for explanations!
> Is there any special flag to add the support for f95  during configure?
> I'd like to see whether it will work for Intel's ifort compiler.

Such a test would be most helpful.

To specifically answer your question, if autoconf cannot find ifort by
itself, then you should be able to set the FC environment variable (and
corresponding FCFLAGS variable) to give you full control over the particular
fortran compiler and set of compiler options that you want to test.  This is
in exact analogy with the present f77 interface system where the F77 and
FFLAGS environment variables can be used to control the particular fortran
77 compiler and flags for that compiler.

Of course, you cannot test our new f95 interface until we supply you with a
test tarball that contains our latest work. Before deploying such a test
tarball, our core developers need to do additional checking of the fortran
95 interface for the variety of platforms accessible to them. All such
testing will be delayed until this weekend because of the current
SourceForge CVS outage.  So my guess is it will probably be a week from now
before we can supply you with a test tarball that you and other fortran 9x
enthusiasts can test.  Watch this space for an announcement.

BTW, after many years of fortran 77 experience, this has been my first
sustained exposure to fortran 9x (in particular gfortran), and I must say I
am most impressed with the language capabilities (especially the powerful
array facilities).  All those fortran 77 issues that have been unconsciously
annoying me all these years are no longer an issue with fortran 9x.  So I
think all our fortran-aware users are going to be most happy with us for
finally supplying a modern fortran 95 interface.  Of course, there are bound
to be "teething" troubles with this new interface, but we will work those
out as the bug reports come in.

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] ANNOUNCEMENT: PLplot Release 5.6.0

[Valery P. <pi...@is...>]

Thank you very much for explanations!
Is there any special flag to add the support for f95  during configure?
I'd like to see whether it will work for Intel's ifort compiler.

V

Re: [Plplot-general] ANNOUNCEMENT: PLplot Release 5.6.0

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

On 2006-05-10 18:44+0900 Valery Pipin wrote:

> BTW,
> the  cvs  version of plplot has number 5.5.3 (not 5.6.0 or older) ;-)

The SourceForge anonymous CVS server has been frozen in time ever since a
major CVS outage 6 weeks ago so that is why it is so far out of date
compared to the "developer" CVS server.  The current estimate from
SourceForge (see http://sourceforge.net/docs/A04/) for when this problem
will be resolved is by the end of this week. However, I assume that estimate
will be extended since the developer CVS server has just developed a major
outage of its own. It went down hard yesterday, and has been down ever
since.  Presumably that problem has higher priority because there are a lot
of developers (including me) waiting to get access to CVS again.

Getting back to your original bug report, I have just completed an extensive
polishing effort on the fortran 95 interface, and I think all our
fortran-aware users are really going to like it.  Our next release (coming
soon) will include it (for real this time).

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________