Werner Smekal wrote:
Hi all,
sorry for the lot of cvs commits ;). I made a lot of changes regarding
the dll problematic, since Arjen told me about the problem, that if a
dll is compiled which uses another dll a MAKINGDLL will make trouble
since you use and make a dll at the same time. The
So the problem probably lies in a clash between the version of glib on
my system and what plplot expects, but I am not sure.
Does anyone know what I have to do to get a working gcw driver?
I do not think that is the problem - you have compiled PLplot as a
whole, so glib should be okay.
Alan W. Irwin wrote:
CMake-2.4.4 was released today with some new features and a whole bunch of
fixes.
Arjen, was your module (Windows-f90.cmake) accepted for this new version?
Hi Alan,
I checked the changes list, but could not find a reference to that
particular module.
However, since
hiroyasu yasuda wrote:
Hello Arjen:
- Are you using the latest release (PLplot 5.7.1) or version 5.6.1?
I was using PLplot 5.7.0. yesterday.
- Are you using the ./configure script to build the libraries or
are you
using the CMake build system?
I followed 'INSTALL' document below:
Werner Smekal wrote:
* qhull library - not sure actually, but I think it is used for
interpolation in grids, so they look more nicely (or something similar :)
qhull is a library/program to determine the convex hull of a set of
points in
n dimensions. The CSIRO library that is part of
Hi Werner,
I tested the batch file make_all_vc.bat this morning. Here are my results:
- I ran it in a separate DOS-box
- Preparation includes:
- running vcvars32 - otherwise CMake can not identify the proper compilers
- making sure CMake in the path
- A minor but important fix is needed:
Werner Smekal wrote:
Hi Arjen,
I reverted all the changes to the Fortran 77 bindings, since I found
out, that Arjen already made corresponding changes for Fortran 95
bindings and his changes were much more elegant, so I made the same for
the Fortran 77 bindings. I hope this works now (since I
Maurice LeBrun wrote:
A ghostly figure emerges from the mist..
Has anyone gotten the cmake build to auto-detect itcl itk? I'm trying my
first cmake build (ok feel free to rag on me for being such a laggard :), and
those two were inexplicably not detected in my usual prefix area that
contains
Alan W. Irwin wrote:
On 2007-01-11 08:45+0100 Arjen Markus wrote:
I checked the entire directory structure: there is only one file matching
cygfreetype*.dll
and that is cygfreetype-9.dll.
Hi Arjen:
One way cygfreetype-6.dll could still be interfering is if one of the system
Alan W. Irwin wrote:
Hi Orion:
Thanks for finding this.
Note, the present version should work because the effect of
common /zzplstr6/ string6
common /zzplstr6/ string7
common /zzplstr6/ string8
common /zzplstr6/ string9
is identical to
common /zzplstr6/ string6, string7, string8,
Alan W. Irwin wrote:
I tried CMake-2.4.6 on my Debian stable system, and it appears to work as
well as 2.4.5. I suggest you try 2.4.6 for yourselves to make sure it is
fine on all platforms. We don't want to get caught by surprise by some
introduced platform incompatibility in 2.4.6 since that
As Hazen is experiencing problems with the mailing list,
I thought to send a message and see whether it arrives ...
Regards,
Arjen
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel
Werner Smekal wrote:
and so on. Since I don't have access to any fortran compiler in question
I would ask Arjen to check these patches and apply them if applicable.
I have not had the opportunity yet, but I will look into this ASAP.
Regards,
Arjen
Alan W. Irwin wrote:
Arjen, when you figure this out, please collect all the required
changes in cmake/modules/Platform/Windows-ifort.cmake. Of course, you
should also make
that changed Windows-ifort.cmake file part of a bug report to CMake so
that
once your changes are adopted by the
Maurice LeBrun wrote:
Arjen Markus writes:
Werner Smekal wrote:
Hello Andrew,
Ok, sounds good. Only problem I see is, that the value of these
variables will likely not be defined, since it's not cpp and I have no
constructor where I can set them. And than I can't find
Jim Dishaw wrote:
Attached is a patch that gets plplot building correctly with the Intel
Fortran compiler. It still doesn't link correctly because of the
mismatch in runtime libraries. I'm not enough of a cmake guru to track
that down. Maybe some can read my previous message about win32
Jim Dishaw wrote:
Attached is a patch for fixing Fortran 95 support for Intel Fortran.
This patch applies changes that was previously applied to the f77
bindings.
On a related topic, to make the library more flexible on the Windows
platform, the /Zl option (no default library) should be
Hiroyasu Yasuda wrote:
Hello Arjen:
Thank you for the reply.
I thought that if there is one PLplot on my environment, the compiler
refers new PLplot 5.7.2 in /opt/local... After removing PLplot 5.6.1,
they still refers /usr/bin. How to be refereed new location of PLplot ?
Since I am
Hello,
in view of the action to clean up the release tarball,
I have added the directory sys/win32 to the list of
directories and files that will not be packaged into
the release tarball.
As far as I can tell, there is no reason whatsoever
to keep the sources and build scripts it contains:
the
Alan W. Irwin wrote:
OK. I will take responsibility for putting a prominent sentence or two in
the 5.8.0-RC1 (and 5.8.0) release notes about this important planned change
for 5.9.0 and beyond.
Hi Alan,
much as I agree with this step, I do want to put the problem of Marius
into the
Alan W. Irwin wrote:
I am not familiar with the particular problem you are referring to.
However,
it sounds like this user was attempting to integrate PLplot software
as part
of a larger autotools build, and I agree that would be awkward. Instead,
PLplot should be treated as the
Michael M. Tung wrote:
Dear Alan:
It looks like the missing symbol fonts in the F95 binding is related to the
equivalence commands in the sfstubs.h file:
integer maxlen
parameter (maxlen = 320)
character*(maxlen) string1, string2, string3
character*(maxlen) string4,
Michael M. Tung wrote:
Arjen Markus [EMAIL PROTECTED] wrote:
Hi Michael,
I will look into the matter of the EQUIVALENCE statements
(real life, as they say, may get in the way of a quick and
clean solution ...)
But in the meantime, could you try and work around this by
using, say, g77
Thanks for that test, Andrew.
Does anybody have access to Debian stable (etch)? It would be interesting
to see whether that version of gfortran (4.1.1) supports the intrinsic
transfer function as well so that it can build our f95 interface.
As far as PLplot is concerned, I think all this
Andrew Ross wrote:
On 2007-10-02 12:48+0100 Andrew Ross wrote:
F95 example 28 now compiles and works. Visually I get identical
results to the other languages. ifort produces identical files.
gfortran 4.1 does not quite produce identical files. When plotting the
string The future of our
Jim Dishaw wrote:
I think dynamic devices still do not work in cygwin.
I can confirm that:
On Cygwin you need to specify -DENABLE_DYNDRIVERS:BOOL=OFF
The individual shared objects are created, but at some point libtool
comes up
with the message that it can not find the driver (in my case
On 2007-10-24 11:02+0200 Arjen Markus wrote:
I have no idea why that would be.
Arjen, I have no idea either since you have ommitted most details.
Your symptoms sound like the problem I attempted to fix as of revision
7967
(done just after 5.8.0-RC1). If your test was for a PLplot version
Hi Arjen and Alan,
as far as I remember shared library support was always broken in Cygwin,
also with the autotools build system. Alan, you asked me to examine that
problem using the ABS first, but I never managed to do that. Long story
short, this should be no showstopper for 5.8.0 since I
Hiroyasu Yasuda wrote:
(1) The first test should have the following options:
-DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=OFF
-DCMAKE_VERBOSE_MAKEFILE=ON
-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON
(2) The second test should have the following options
-DBUILD_SHARED_LIBS=ON
Alan W. Irwin wrote:
Hiroyasu, I am hoping that you, Arjen, and Jim all do the requested
test 2
for svn trunk with complete error report since if a problem exists it may
depend on what version of dynamic loading libraries each of you have
installed with Cygwin. However, if instead you
Much thanks for those detailed results. At this point, I have not found
anything wrong elsewhere that might be affecting the get-drv-info.exe
problem.
At least get-drv-info.exe has the correct .exe suffix now. (The recent
change
I put into svn.)
Could you attempt to verify the problem
On 2007-10-27 18:58+0900 Hiroyasu YASUDA wrote:
Arjen, I can succeeded to install Plplot with g77 on Cygwin according to
attached reports. Thank you.
However, when run make command for build example, make shows the error
message of referring Win32 libs, gdi32 and comdlg32. Is this problem
On 2007-10-26 14:10-0700 Alan W. Irwin wrote:
Forget that last request because I have made some svn changes that make
that request irrelevant.
As of revision 7981 when you execute
./get-drv-info.exe ps
that application internally prepends the drivers directory path to the
search term
Hi Alan,
I won't keep in suspense: dynamic drivers work when I rename
the .so file to .dll!
However, there is a small caveat:
For get-drv-info to do its job, the path/ld_library_path
must be extended or the cygplplotd-9.3.0.dll and cygcsirocsa-0.0.1.dll
copied into the drivers directory.
I did
I performed the best by setting the LD_LIBRARY_PATH to include lib/csa
and src, which are the locations of the csa and plplot DLL's. I
configured plplot with the command
cmake -DCMAKE_INSTALL_PREFIX=install -DCMAKE_VERBOSE_MAKEFILE=ON
-DBUILD_TEST=ON -DENABLE_DYNDRIVERS=ON -DENABLE_tk=OFF
Alan W. Irwin wrote:
On 2007-10-30 08:39+0900 Hiroyasu Yasuda wrote:
On 2007/10/30, at 7:49, Alan W. Irwin wrote:
On 2007-10-30 07:09+0900 Hiroyasu Yasuda wrote:
On 2007/10/29, at 19:27, Alan W. Irwin wrote:
Please run the command that determines the compile flags
Alan W. Irwin wrote:
Therefore, Arjen, have you actually tried building the examples in the
install tree (after make install has been run) and running make and
./plplot-test.sh in the installed examples directory (e.g., in
$prefix/share/plplot5.8.0-RC1/examples, where $prefix is the installation
Arjen Markus wrote:
Hello,
it is clear to me now why:
gfortran -o x01f x01f.f `pkg-config --libs plplotd-f77`
gives the error message:
/bin/ld: cannot find -lplplotf77d
The file it should link against is called libplplotf77d-9.1.1.dll
(and the other one is libplplotf77cd-9.1.1.dll)
If I
Arjen Markus wrote:
That said, I will change the CMake code that is responsible for writing the
*.pc files for the FORTRAN 77 and Fortran 90/95 libraries. However,
does this issue come with C++, Java, ... too? Does anyone know?
Hello,
I updated the relevant CMake files to produce correct
Alan W. Irwin wrote:
I have just bought a new PC and installed Debian testing on it. Thus, I was
anxious to know how fast the new PC was for building PLplot, and whether the
svn trunk version of PLplot has any bugs for this 64-bit Linux system that
would be showstoppers for the 5.8.0 release.
Hiroyasu Yasuda wrote:
Because to use -dev and something options of plplot, I would like to
know how to build plplot for cygwin environment. When built plplot
svn version last week, I ran cmake options with :
-DENABLE tk=OFF -DENABLE tcl=OFF -DENABLE DYNDRIVERS=OFF -DPLD
wingcc=OFF ..
Hiroyasu Yasuda wrote:
On 2007/11/12, at 16:48, Arjen Markus wrote:
the message about the negative number of arguments was exactly the
problem we encountered
before. One way, IIRC, around it is to use static libraries. Can you
try with g95?
Hello, Arjen,
I tried to build
Alan W. Irwin wrote:
On 2007-11-22 19:18- Andrew Ross wrote:
For some time I've been pondering ways of plotting up time series over
days / months. Many plotting packages (e.g. gnuplot) provide special
options for time series so you can format the axis labels in a human
dd/mm type
Dear all:
I would like to plot vectors in general curve coordinate as attached
picture. Of course I have already try to be plotting with plvec2.
When I gave the vector data which is u =1.0 and v=0.0, the plotted
vectors look like along co-orthogonal coordinate.
I think that plplot has the
Andrew Ross wrote:
plvec2 is equivalent to calling plvect with the pltr2 function as the
pltr. This only affects the location of the vectors, not the direction /
magnitude.
The only reason for plvec2 etc is that fortran (and several other bindings)
don't allow you to pass a function name as an
Andrew Ross wrote:
On Wed, Dec 12, 2007 at 09:20:46AM +0100, Arjen Markus wrote:
Andrew Ross wrote:
plvec2 is equivalent to calling plvect with the pltr2 function as the
pltr. This only affects the location of the vectors, not the direction /
magnitude.
The only reason for plvec2
Andrew Ross wrote:
Ah yes. I should have looked more closely at this. Was there a reason
you didn't do this for the plvect / plcont functions in the F95
bindings? I'm not sure I would advocate changing this now as we already
have plvect / plcont implemented, although with different arguments to
On 2007-12-18 09:03+0100 Arjen Markus wrote:
Hi all,
I have been experimenting with MingW as the development and build
environment
under Windows, but I have run into a nasty problem.
One possibility is the programme might be waiting for access to some
resource. In such situations, I
Andrew Ross wrote:
Ah yes. I should have looked more closely at this. Was there a reason
you didn't do this for the plvect / plcont functions in the F95
bindings? I'm not sure I would advocate changing this now as we already
have plvect / plcont implemented, although with different arguments
Hazen,
Many thanks for this. It's a useful feature to have and I'm glad someone
has finally got round to starting to code it in. I've added support for
alpha values to the gd driver too so hopefully more people can test it
out.
Note that libgd uses integer alpha values in the range 0-127
On Tue, Jan 08, 2008 at 08:43:46AM +0100, Arjen Markus wrote:
Well, Tcl 8.5 has finally landed in Fedora Development again. You can
see some results from earlier attempts here:
http://www.mail-archive.com/plplot-devel@lists.sourceforge.net/msg00440.html
I've attached my recreated
Maurice LeBrun wrote:
On Tuesday, January 8, 2008 at 16:11:13 (-0800) Alan W. Irwin writes:
Maurice, there is a question at the end for you about the current
status of itcl.
..
N.B. itcl is not compatible with Tcl 8.5, and is probably going to be
a
problem for all future versions
There is some effort by the Fedora maintainer to get it working:
https://bugzilla.redhat.com/show_bug.cgi?id=428083
I have heard that two members of the Tcl Core Team are working
on this issue as well. I will keep you posted about progress.
Orion,
can you get Itcl/Itk from the CVS HEAD
On Tue, Jan 08, 2008 at 08:43:46AM +0100, Arjen Markus wrote:
I tried to build PLplot for Tcl 8.4 under MingW (with the intent to
move on to Tcl 8.5 if all went well), just to see what would happen
(and to have access to the generated source code for inspection).
In previous attempts
On 2008-01-10 21:42+0100 Arjen Markus wrote:
Hi Alan,
wise words indeed (see the - elliptical - subject line)!
The short story:
---
I have success now with Tcl under Cygwin and MinGW with the
wingcc device.
I can add the bare Windows platform to be above list :D
Hi,
the iMac I use has already Mac OS X 10.5.1 installed. But although
cmake finds the f77 and f95 compiler there are problems to compile the
fortran files. For both bindings I got errors like:
Scanning dependencies of target plplotf77d
[ 6%] Building Fortran object
Andrew Ross wrote:
I've been looking at implementing an example which uses plgfci / plsfci.
The most logical seems to be to replace calls to plfont in one or more
of the existing examples with the new functions. Comments in the source
suggest that is what users should do.
Unfortunately the way
Arjen Markus wrote:
Here is the current status for f77 and f95:
[EMAIL PROTECTED] scripts/check_api_completeness.sh f77 |grep '[+-]' |grep -v
'@@' |grep -v '\-\-\-' |grep -v '+++'
-plarrows
-plenv0
-plgcolbga
-plgfci
-plimage
-plimagefr
-plot3dcl
+plsetmapformc
-plsfci
-plsurf3dl
[EMAIL
Andrew Ross wrote:
Arjen,
I guess this is an issue with gcc 3.4.4 being tighter with type
checking. No-one else has yet reported it. I assume the problem is that
the compiler doesn't know whether to interpret 1 as a PLINT or a bool.
To my mind it is definitely an int. (bool should either be true
Andrew Ross wrote:
Arjen,
I guess this is an issue with gcc 3.4.4 being tighter with type
checking. No-one else has yet reported it. I assume the problem is that
the compiler doesn't know whether to interpret 1 as a PLINT or a bool.
To my mind it is definitely an int. (bool should either be true
Hi,
well, continuing my test on bare Windows XP, I get into trouble:
- I expected CVF as the Fortran compiler, but it turns out that
two are in the path, both CVF and g95. I can solve that one.
- This is more serious:
Linking C shared library ..\dll\libplplotd.dll
LINK : warning LNK4044:
Hi,
I am testing CMake 2.6 on bare Windows XP, using the latest version
of PLplot. At the end of the generation of the makefiles I get this
warning:
-- Configuring done
CMake Warning (dev) at src/CMakeLists.txt:129 (add_library):
Policy CMP0003 should be set before this line. Add code such
Hi,
well, continuing my test on bare Windows XP, I get into trouble:
- I expected CVF as the Fortran compiler, but it turns out that
two are in the path, both CVF and g95. I can solve that one.
- This is more serious:
Linking C shared library ..\dll\libplplotd.dll
LINK : warning
I removed g95 from the path and reran the whole configuration and
build: this worked without the above errors - except for a small
glitch in PLSCMAP1LA. I will repair that.
Conclusion: you must be careful when you have several Fortran compilers
in the path!
I repaired the glitch regarding
Now I am going to try the g95/MSVC combination.
That combination fails:
I get the warnings about options like L\lib from the
linker and the error messages about /STACK:1000 and
the like from g95 when linking the Fortran DLL.
There is something wrong here, but I do not know what
- the
On 2008-05-13 22:10+0200 Arjen Markus wrote:
Now I am going to try the g95/MSVC combination.
That combination fails:
I get the warnings about options like L\lib from the
linker and the error messages about /STACK:1000 and
the like from g95 when linking the Fortran DLL
Alan W. Irwin wrote:
You should make a simple test case of this. If it continues to fail for
that case, then you should report this as an important Fortran bug for
2.6.0. I recommend you also say in your bug report whether the same
failure
occurs for 2.4.8. OTOH, if you cannot make a
Hello,
Stefan Menzel reported a bug (plplot-Bugs-1973336) regarding plotting a
single
pixel. This is a special case in plpoin (where the value of the argument
code is -1).
The wingcc driver does not plot anything, whereas the GD driver does (at
least for PNG).
Given the implementation (as a
Jim Dishaw wrote:
There is a similar logic for X11 using XDrawPoint and XDrawLine.
I think this change should be made even if a single point drawing
function is implemented.
The plpoin does not draw a single pixel point per se. The intent of the
function is to draw a point on the graph (which
Hello,
while testing the patch Jim Dishaw provided I ran into
a few oddities that could actually be considered nasty:
1. The file plplotf95.def, the list of subroutines and
functions that must be exported is NOT seen as a
dependency. So only via make clean will a change here
force a
Hello,
my testing of Jim's patch also brought to light the following
issues:
1. In x19f I get a runtime error (with message box) just after
the last page. It does not happen with x19c.
According to the message it may be a mismatch in the calling
convention for one or more
Hello,
while testing the patch Jim Dishaw provided I ran into
a few oddities that could actually be considered nasty:
Sorry, my subject line caused some confusion:
I have used CMake 2.6 in these tests, but I am not sure
this is the first version of CMake that they are connected
with.
I don't have CVF installed on my machine right now, so I was not able to
test it. I guess you got it working with the default, in which case we
might be able to do away with the CVF define.
Okay, that sounds reasonable :). ISTR CVF has an option to change
that behaviour but we will rely on
Could somebody with Windows access try example 29? That example only uses
POSIX compliant time functions like mktime and difftime, but I am not sure
whether the Windows C library provides those or not (or even supplies them
under a different name).
Hi Alan,
I looked into example
I've been working on implementing plgfci and plsfci in the fortran
bindings, starting with f95. Unfortunately fortran does not support
unsigned integers so PLUNICODE has to be cast to an 64 bit integer in
fortran. I've created a plunicode type, similar to plflt, to make this
transparent in
On 2008-08-01 22:24+0100 Andrew Ross wrote:
I also noticed the integer(16) and did not like it since in fortran 77 at
least integer*8 would correspond to 64 bits and integer*16 to 128 bits.
Arjen, do you know about this?
Can you test again with my fix and see what happens?
The f95 example
On 2008-08-05 09:59+0100 Andrew Ross wrote:
Alan,
A first initial look at the postscript shows differences even on the
first page, suggesting perhaps a slightly different random distribution
of numbers to start with. I've made a few of the constants in the
example explicitly of kind plflt,
On 2008-08-01 22:24+0100 Andrew Ross wrote:
I also noticed the integer(16) and did not like it since in fortran 77
at
least integer*8 would correspond to 64 bits and integer*16 to 128 bits.
Arjen, do you know about this?
Can you test again with my fix and see what happens?
The f95
I've just committed a fix to the f77 example 26 so that it gives
identical results to the C version. While trying to do this I needed to
split one of the unicode strings in a data statement across two lines
since the multibyte characters make the line more than 72 characters
long. You can't
Andrew Ross wrote:
(1) Normally, I believe it should be the user's responsibility to set the
flags appropriate for their compiler.
So what happens if you simply use
FC='ifort -assume byterecl'
?
If that works for all examples without messing them up, then perhaps we
should recommend that
On Thu, Aug 07, 2008 at 04:20:40PM +0100, Andrew Ross wrote:
Tcl is lagging well behind. We're lacking any dedicated tcl users to
help with this.
Now that the Fortran examples and bindings are so nicely in shape,
I want to dedicate some time to Tcl.
Having said that, while waiting for a
On Thu, Aug 07, 2008 at 04:20:40PM +0100, Andrew Ross wrote:
MSVC 6.0 does not like the long long type in plplot.h!
This is odd: things worked before - the problem is that this
compiler does not have a stdint.h, so the fallback is used.
Actually MSVC 6.0 on my machine does not like 64
On Thu, Aug 07, 2008 at 04:20:40PM +0100, Andrew Ross wrote:
MSVC 6.0 does not like the long long type in plplot.h!
This is odd: things worked before - the problem is that this
compiler does not have a stdint.h, so the fallback is used.
Actually MSVC 6.0 on my machine does not like 64
Andrew Ross wrote:
Arjen and I have been tidying up the tcl bindings and examples. As a
result the tcl bindings are in a much better state than they have been
for a long time. There were a large number of newer common API functions
missing along with quite a few examples.
Most of the work has
Hi Arjen,
Well, Fortran 95 is an (almost) strict superset of FORTRAN 77, so any
F95
compiler should be able to handle F77 as well (*).
The problem you encounter here most likely has to do with naming and
calling
conventions. I have never tried gfortran under MinGW (got g95 instead),
but
Werner Smekal wrote:
I attached the output of nm for libplplotd.dll and libplplotf77d.dll.
I think that we should try to make plplot work for gfortran, since
it's the standard fortran compiler of MinGW (g95 is not favoured by
the MinGW guys for some reason) and it's very easily installed
Werner Smekal wrote:
Hi Arjen,
No, MinGW (official and unofficial) doesn't provide a bash like shell or
something similar. I assume, that if you install (official) MSYS you
will be asked, where the MinGW directory is, and that you can use MSYS
also with the unofficial MinGW package.
Alan W. Irwin wrote:
Also, please note that I have been working on gcc visibility issues
recently
so I may have inadvertently messed up the MinGW version of GCC case. The
the PLplot trunk version right now, all is well for Linux gcc because
I use
the (default) case (i.e., everything
Hi Arjen,
The official GCC compilers that I get via TDM do _not_ include
gfortran, however! So that seems to be the end of the line:
- the TDM distribution is incomplete
- the official distribution does not have gfortran
The official distribution is MinGW 3.4.5 and gfortran was first
Hi Arjen,
maybe an old library is linked to, which contains differently named
functions? Could you try to compile the simple fortran program from the
Windows CLI? run cmd.exe, set the path with
set PATH=c:\mingw_gcc\bin;%PATH%
and compile the program. MSYS maybe sets some other
Werner Smekal wrote:
Hi Arjen,
it must be some misconfiguration of MSYS and your MinGW version(s),
since I was able to compile and run your program but from within a
Windows CLI without problems.
Hi Werner,
yes, there definitely is some kind of interaction: MSYS (or g95) defines
an
Alan W. Irwin wrote:
There are some questions below for Arjen and Werner in addition to my
response to some of Andrew's comments.
Here is a question for Arjen and Werner. One thing I am confused about at
the present time is whether there has been any visibility work done
yet for
our
Werner Smekal wrote:
I think that you are actually right. We would need MAKINGPLCXXDLL (for
the source) and USINGPLCXXDLL (for the examples) definitions. And
since the cpp library uses c functions from liplplotd USINGPLDLL must
be defined. I wonder, why it worked so far for Windows.
Hi
Alan W. Irwin wrote:
Nevertheless, every time there is a Windows visibility issue, you would
wonder whether ignoring dllimport for the undefined symbols for some
of our
libraries is the culprit. Furthermore, for consistencies sake, since the
import issue is treated properly for libplplotd
Alan W. Irwin wrote:
Here is what I suggest you and Werner do to follow up on this. You have
already indicated earlier in this thread you were not quite sure about
what
circumstances required use of __declspec(dllimport). So I suggest you
look
very carefully at all traditional and
The SourceForge mailing lists seem down at the moment, but this post
should
get distributed eventually so for the record, I have just changed our
website (http://plplot.sourceforge.net/) over to Werner Smekal's new
PHP-based version. (If you still want access to the old site, look at
Hello,
I am picking up the issue of gfortran 4.3.2 under MinGW again.
I have modified the source code (the import/export stuff) so
that the libraries are created appropriately, but while
building the examples, I run into the problem that the file
libplplotf77d.dll.a is not found (there is a file
On 2008-10-02 22:04+0200 Arjen Markus wrote:
Hello,
I am picking up the issue of gfortran 4.3.2 under MinGW again.
I have modified the source code (the import/export stuff) so
that the libraries are created appropriately, but while
building the examples, I run into the problem
Steve Schwartz wrote:
Also, I'm still having difficulty printing a postscript plot on a page;
it looks fine in ghostscript (with the view set to A4 or Letter paper),
but prints to a ps printer blown up by a factor ~4.8. Passing through
eps2eps, epstopdf, or any other filter generates a file that
Alan W. Irwin wrote:
On 2008-10-02 22:04+0200 Arjen Markus wrote:
Hello,
I am picking up the issue of gfortran 4.3.2 under MinGW again.
I have modified the source code (the import/export stuff) so
that the libraries are created appropriately, but while
building the examples, I run
1 - 100 of 912 matches
Mail list logo
