Hi,
the new set-up to get the driver .rc files seems to be
failing under Cygwin. I have no idea why: I am not overly
familiar with libtool and its inner workings, but what
happens is this:
The test-drv-info runs to completion but writes an
empty string to the screen - and hence the .rc file
is em
Hi Werner,
I have run into a problem with dlltool: is that still required in your
case? I run into it, because my rather basic installation of MinGW
does not have it (the tdragon one): make/cmake complains about an
unknown tool.
Regards,
Arjen
On 2009-03-24 09:51, Werner Smekal wrote:
> Hi Arje
On 2009-03-26 19:26, Hazen Babcock wrote:
> I'll take this opportunity to formalize my vote of ambivalence on the
> move to git. If we decide to move that is ok with me, if we don't that
> is also okay. I'm not enough of an expert on version control to have
> much of an opinion, beyond that w
Hi Werner,
most of it works: it is testing the Tcl part, where there is a lot
of redirecting, that does not work.
Regards,
Arjen
On 2009-03-25 09:56, Werner Smekal wrote:
> Hi Arjen,
>
>> things I want to achieve for the 5.9.3 release:
>> - Get ctest to work under bare Windows (using the winba
Hi Alan,
things I want to achieve for the 5.9.3 release:
- Get ctest to work under bare Windows (using the winbash utility)
- Solve the build issues that pop up now and again (the issues
with .def files for instance)
Should be doable in the coming weeks. So, no objection from me.
Regards,
Ar
Hi Werner,
glad you found that out, but I am slightly puzzled:
- I do not recall ever needing that line
- the actual line will depend on the option to use double-precision
or not, so that complicates matters
Furthermore, while trying to reproduce your problem I ran into
one or two disturbing i
Hi Werner,
very odd! I will delve into this myself :(
Regards,
Arjen
On 2009-03-24 09:51, Werner Smekal wrote:
> Hi Arjen,
>>
>> On 2009-03-24 09:38, Werner Smekal wrote:
>>> Hi,
>>>
>>> I'm using the dynamic drivers and it exits with a message like
>>> (translated from German):
>>>
>>> "The ap
Hi Werner,
the def-file is a file with instructions for the linker, so as far as
CMake is concerned, it has the same function as a source file. I am
not sure why it works for me and not for you (right now, it is not
part of the dependencies - we need to take a look at that).
This requires furthe
On 2009-03-24 09:38, Werner Smekal wrote:
> Hi,
>
> I'm using the dynamic drivers and it exits with a message like
> (translated from German):
>
> "The application could not be started, since (null).dll wasn't found. A
> new installation of the application might solve the problem."
>
> Some
Hi Werner,
what is the reason they do not run? If you do not get any output,
the program simply stops, that could be due to a missing DLL (sometimes
you get a message, sometimes you don't under Windows).
Regards,
Arjen
On 2009-03-24 09:27, Werner Smekal wrote:
> Hi Alan,
>
>> "trim" is recogni
Hello Alan,
For MinGW we also have g95 and gfortran available. But it can't
hurt to test with a FORTRAN 77 compiler perse.
Regards,
Arjen
On 2009-03-20 02:31, Alan W. Irwin wrote:
>
> "trim" is recognized by the gfortran compiler (at least the version of it
> that I have), but not g77 (which
Hi Werner,
right, my Fortran compiler is usually gfortran or g95 - g77 is a very
old compiler that is no longer actively maintained. I can imagine
that the compiler does not produce import libraries - shared libraries
under Windows simply have too many pecularities, so they are probably
beyond g77
Hi Werner,
is there any reference to an (example) linear transformation?
If not, I'd say: remove it.
It seems an attempt to call a similar C function, but I know of
no such functionality ... I am inclined to repeat my suggestion
also in the case there is a reference.
Regards,
Arjen
On 2009-03-
Hello Alan,
I have run the sample programs manually on Windows XP and the resulting
files are exactly the same as the reference files (I must have
overlooked the TEST_NISTCD option ...) Anyway, this is looking very
good.
Regards,
Arjen
On 2009-03-10 23:12, Alan W. Irwin wrote:
> lib/nistcd cont
Hi Werner,
I have been able to build the CGM driver without a problem (the
nistcd.dll was being buit before - I simply overlooked it).
I can use the driver in an example and that produces a CGM file.
I will use the new test facilities later to see if all is well
(right now I can do little with CG
Hi Werner,
good to know that :) then I won't spend time on that fix.
Regards,
Arjen
On 2009-03-10 09:52, Werner Smekal wrote:
> Hi Arjen,
>
> I already fixed that, but didn't commit that so far. Will do in the
> next hours.
>
> Regards,
> Werner
>
>
Hi Werner,
On 2009-03-10 10:34, Werner Smekal wrote:
> Hi Arjen,
>>
>
>> I tried building PLplot with this device (and the new third-party
>> library) turned on on bare Windows, but it fails:
>> - The linker complains about cdImageColorClear() - it does not
>> seem to exist.
>
> Only this func
Hi Alan,
I tried building PLplot with this device (and the new third-party
library) turned on on bare Windows, but it fails:
- The linker complains about cdImageColorClear() - it does not
seem to exist.
- The dll directory that is created under Windows does not contain
a corresponding dll fo
On 2009-03-03 23:23, Thomas Stover wrote:
>
> -I'm curious what NaNAware is, but I haven't found a good link
> explaining it.
Hello Thomas,
NaNAware refers to one of the special "numbers" in IEEE arithmetics:
NaN is the acronym of Not-a-Number, it is used to represent the
result of 0.0/0.0, sq
Hi Terrence,
here is some background information -
http://wiki.apache.org/stdcxx/FloatingPoint
(the cover of the Hitchhiker's Guide to the Galaxy comes to mind)
Regards,
Arjen
On 2009-02-21 18:22, trc wrote:
> Hi,
>
> I am using MSVC 9 with (Activestate) Tcl 8.5
>
> Example 21 fails as
Hello Terrence,
some interaction with a fellow Tcler made me realise that this
may be the "best" way to deal with NaNs of unclear denomination:
if { ![string is double $x] || $x != $x } {
... it is not a valid number or it is NaN
}
(sprintf() as used in the bindings will either produce a va
Hi Terrence,
just tried this with Tcl 8.5:
> set a NaN
NaN
> expr {$a==$a}
0
> string is double $a
1
So:
The string NaN is recognised as a "Not-a-Number", hence the failure of
the test "$a==$a" (one of the distinguishing properties of NaNs) but:
NaN is recognised as a double precision number
nv isn't provided for
> MinGW as well, but putenv is. Look here:
>
> http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/2754.html
>
> So MinGW, must also be included in this patch, but then it's putenv and
> not _putenv, so we need to do more work here.
&
Hi Terrence,
that sounds like a good idea, but we need to check that this does
not have other conseqences (the formatting of a NaN seems to be
a perpetual minefield ...).
Regards,
Arjen
On 2009-02-21 18:22, trc wrote:
> Hi,
>
> I am using MSVC 9 with (Activestate) Tcl 8.5
>
> Example 21 fails
Hi Werner,
one thing I can think of as the underlying cause, is that Windows uses
"bands" to print a plot. Or that may the abstraction I know from one
particular GUI toolkit. The trick used there is that you need to
repeat drawing until all bands have been done. But I do not know
if that is the ca
pilers and might lead
to incorrect results on 64-bits Windows ...)
Regards,
Arjen
On 2009-02-20 02:17, Alan W. Irwin wrote:
> On 2009-02-19 19:48+0100 Arjen Markus wrote:
>
>> Hi Alan,
>>
>> my old MSVC compiler is complaining about a few things
>> with Terrence&
Hi Alan,
my old MSVC compiler is complaining about a few things
with Terrence's patch - nothing I can not resolve, but
the worst is that the testlib program stops immediately:
sizeof(time_t) = 4
tests abandoned because time_t too small on this platform
to run this programme
What is the way forw
ately.
First priority: get it working again.
Regards,
Arjen
On 2009-02-18 20:25, Alan W. Irwin wrote:
> On 2009-02-18 14:11- trc wrote:
>
>> Hi,
>>
>>
>> Arjen Markus wrote:
>>
>>> I have found the same problem with setenv() and unsetenv() on my
>
Hi Terrence,
with this patch in hand, I can concentrate on adding a test to the CMake
files.
Thanks,
Arjen
On 2009-02-18 15:11, trc wrote:
> Hi,
>
>
> Arjen Markus wrote:
>
>> I have found the same problem with setenv() and unsetenv() on my
>> venerable platform
Hello Terrence,
I do not think it is possible to set an environment variable to an empty
string on Windows. This amounts to undefining it.
I have found the same problem with setenv() and unsetenv() on my
venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create
a workaround using put
Hi Werner,
I have a text describing the exact procedure for box-and-whisker plots.
I will send it to you off-list.
(Mind you: there are several variations but this tutorial was sent
to me by a renowned psychometrist, Steve Blinkhorn.)
Regards,
Arjen
On 2009-02-08 21:19, Werner Smekal wrote:
>
On Thu, 5 Feb 2009 12:54:51 + (GMT)
trc wrote:
>>
> The changes required are all in qsastime-
> 1. qsastime/CMakeLists.txt
> 1.1 Remove qsastime.h and qsastimedll.h from
>qsastime_LIB_SRCS
> If these are included the qsastime library is not
>built by MSVC
>
> Looking at ot
Check if e-mail arrives
Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and
parts of Rijkswaterstaat have joined forces in a new independent institute for
delta technology, Deltares. Deltares combines knowledge and experience in the
field of water, soil and the subsurfac
> Hi Arjen:
>
> The current set of shell scripts for testing have had constant maintenance
> and improvement as long as I can remember. So I think taking a windows
> batch file approach to do the same thing would create a substantial
> maintenance issue that we should avoid if at all possible.
>
>
> On 2009-01-16 23:10-0800 Alan W. Irwin wrote:
>
..
> I am concerned the script update is so close to our release deadline it
> makes it difficult for anybody to test it before the release, but please
> try to do so before the release by running
>
> "make test_interactive"
>
> or
>
> ./make ; ./p
>
> All that is going to take time, and we are only two days away from our
> release on Sunday. Arjen, if you can quickly figure out the best
> implementation and get a commit done in the next few hours (or by early
> Saturday (your time zone) at the latest), then that would give the rest of
> us
> On Fri, Jan 16, 2009 at 10:40:24AM +, Andrew Ross wrote:
>
> To follow up my own post - switching to tcl8.5 gives perfect results, so
> this is not a 32-bit issue. Perhaps we should add a note that tcl 8.5
> is recommended, although previous versions will work?
>
You should get the same perf
> The status of testing for this forthcoming release is as follows:
>
> * I have recently confirmed the segfaults are still there for all our
> Tk-related examples, but not for -dev tk. I have updated README.release
> accordingly. That notice should be removed if somebody can figure this
> out.
> I have committed (revision 9319) a general fix for this issue which
> involves
> "call flush(6)". I have checked in the appropriate documentation that the
> flush routine is available in fortran support libraries for the g77,
> gfortran, absoft, intel, and Portland group compilers so I think thi
>
> Arjen,
>
> Sounds wise to me. I'd say go ahead a make the change. You might want to
> wait until after the release this weekend now just to avoid breaking
> anything inadvertently.
>
> Andrew
>
Hi Andrew,
I will do that - wait over the weekend and then make the change.
Currently I am focusin
Hello,
I have been wondering about a better way to determine if
Itcl is available (in the right version) or not.
Currently this is done by looking for the library and
header files. But this does not check if the version
of Itcl does indeed match the version of Tcl. (Itcl
uses - at least in its cl
> tcl
>Missing examples: 17 19
>Differing postscript output :
>Missing stdout :
>Differing stdout:
>
> The API exercised by example 19 is not straightforward to implement, but
> it's been done for Fortran (both f77 and f95) so hopefully somebody
> On Tue, Jan 06, 2009 at 11:28:20PM -0800, Alan Irwin wrote:
>> On 2009-01-07 06:23+0100 Arjen Markus wrote:
>> > So, I reckon the Tcl examples now all give a perfect match
>> > (at least with Tcl 8.5), only example 19 is still missing.
>>
>> Hi Arjen:
>> On 2009-01-05 10:33+0100 Arjen Markus wrote:
>
> Now, there are still the strange deviations in example 11. I am not
> sure how to proceed here - probably the same stubbornness as for
> example 20 is required :).
>
It turned out to be easier than that: the cause was the sa
> On 2009-01-05 10:33+0100 Arjen Markus wrote:
>
>>
>> Example 20 is causing me a slight headache :(. I have checked just
>> about everything I could think of:
>> - All expressions are braced
>> - The file is read correctly - all values are identical to t
> Hi Arjen:
>
> Here is what I now (revision 9253) get with Tcl-8.5 on Debian testing.
>
> tcl
>Missing examples: 19
>Differing postscript output : 11 20
>Missing stdout :
>Differing stdout:
>
> That's a substantial improvement from what I got
> On Wed, Dec 31, 2008 at 08:35:06AM +0100, Arjen Markus wrote:
>> >
>> > I would change the Tcl version to match the C logic (and the logic for
>> the
>> > other languages as well) which (as you noted) does use integers for
>> the
>> > theta-rel
>
> I would change the Tcl version to match the C logic (and the logic for the
> other languages as well) which (as you noted) does use integers for the
> theta-related variables for exactly the rounding reasons you mentioned.
>
Which is what I have done in my private copy. I have not had a chance
Hi,
I am working on the Tcl examples and found possible causes
for the rounding errors vis-a-vis the C examples, namely
not using braces around all expressions. (The lack of braces
means that the numbers are filled as strings before the
expression is evaluated, whereas with braces the [expr]
comma
> On 2008-12-24 11:57-0500 Hazen Babcock wrote:
>
>>
>> Hello,
>>
>> Due a number of significant changes it has been requested that the 5.9.2
>> release of PLplot should happen in a few weeks time. Tentatively I'm
>> going suggest the weekend of January 17-18th. Is this acceptable?
>
> That would b
>
> Thanks, Arjen, for that suggestion. I was debating whether to propose
> enabling Tcl by default regardless (since it certainly has no segfault
> problems as revealed by ctest), and now you have confirmed that idea. So
> I
> will follow your above suggestion in detail (unless some other Tcl/Tk
> Hi everybody:
>
>
> If anybody here strongly objects to disabling Tcl and Tk by default in our
> build system (i.e., you would have to specifically set -DENABLE_tcl=ON and
> -DENABLE_tk=ON to get access to Tcl/Tk from now on), please let me know
> soon
> since I am going to have to make the decis
Alan W. Irwin wrote:
>Thanks everyone for the recent series of commits that fixed a lot of bugs
>and also arrived at a reasonable stopping point for the wxwidgets device
>driver changes. The only additional change planned for this release that I
>am aware of is Hez's docbook documentation for his
Werner Smekal wrote:
> Hi Arjen,
>
>>>
>>
>> I am not sure CMake recognises that it is working under MSYS - I saw
>> that
>> the MSYS flag is off in the output I posted. So, it may be using the
>> MinGW
>> logic.
>
>
> I'm quite sure, that it cmake recognizes MSYS. It tests for sh.exe (or
>
Werner Smekal wrote:
yes, this is a problem, I wrote that the dll directory needs to be in
path. Don't copy the dlls, since if you change something and you forget
to copy again, you won't see the effect :). So add the dll directories
to the path, but if you want to test examples you need to do
Alan W. Irwin wrote:
>
> I believe the above messages indicate target ps was already built
> (i.e., a
> stale build tree). It is possible it was built correctly the first time
> you ran this. Therefore, could you try again with an initially empty
> build
> tree and disabling all devices other t
> Hello,
>
> I am experiencing a few problems with the new dynamic drivers
> under MinGW (MSYS+MinGW to be more precise).
>
> The first is that during the build get-drv-info is run, but it
> can not because the libplplotd.dll is not in the path. Manually
> copying the DLL into the directory drivers
Hello,
I am experiencing a few problems with the new dynamic drivers
under MinGW (MSYS+MinGW to be more precise).
The first is that during the build get-drv-info is run, but it
can not because the libplplotd.dll is not in the path. Manually
copying the DLL into the directory drivers solves this,
Werner Smekal wrote:
>Hi all,
>
>
>it's now possible to load shared driver modules during run time on win32
>platforms.
>
>
...
>Together with some other minor changes this made the shared drivers work
>for MinGW. Visual C++ misses the dirent.h implementation so I downloaded
>a free one
Alan W. Irwin wrote:
> On 2008-10-10 11:49-0700 Alan W. Irwin wrote:
>
>> Later today I hope to report visibility fixes for Tcl, psttc, and the
>> cairo
>> device driver...
>
>
> Just finished the tclmatrixd and plplottcltk namespace changes (revision
> 8878). I also dropped the PLDLLIMPEXP* mac
Alan W. Irwin wrote:
>
>
>Note that the fortran examples passed ctest. This was a bit surprising to
>me since we do something special in the headers to make symbols in the C
>source code libraries libplplotf77cd and libplplotf95cd visible, but we have
>no mechanism to do the same thing for the Fo
Werner Smekal wrote:
>Hi,
>
>I just admitted lot of changes to get this import/export issue right.
>What I basically did I explain in pldll.h:
>
>
>
My, that is quick. I take it the changes work on Linux too?
(I am going to ask on the gfortran list how to arrange the exporting of
Fortran
rout
Alan W. Irwin wrote:
>
> I suggest you simplify the above logic by separating the driver namespace
> from the core library one just as we currently do for the csa and nn
> libraries. What I had in mind was using MAKINGDRDLL, USINGDRDLL,
> DRDLLEXPORT, DRDLLIMPORT, and DRDLLIMPEXP for the driver-re
> On Thu, Oct 09, 2008 at 03:17:40PM -0700, Alan Irwin wrote:
> It is. Setting xxxUSINGDLL for the drivers ensures that all the
> symbols from the core library defined in plplot.h etc are imported into
> the driver. This is ok. However, there are some symbols in the driver
> files which are exporte
Alan W. Irwin wrote:
> On 2008-10-08 11:31+0200 Robert Pollak wrote:
>
>> Hi Alan, Arjen,
>>
>> Alan wrote:
>>
>>> Robert, what happens if you add
>>>
>>> #define PLDLLEXPORT
>>> #define PLDLLIMPORT
>>>
>>> to the #else stanza above? I predict that will fix your problem with
>>> the -DBUI
Robert Pollak wrote:
Arjen Markus wrote:
Does this mean you can now properly build static libraries?
Yes, I can build them with the mentioned svg.c change and with Alan's:
Index: include/pldll.h
===
--- include/pl
Robert Pollak wrote:
Hi,
I wrote:
Unfortunately, it makes another compile error in svg.c visible:
D:\project\PLPlot\drivers\svg.c(341) : error C2143: syntax error :
missing ';' before 'type'
This is fixed by simply removing the unused "int i;" line.
Can someone please commit this ch
Alan W. Irwin wrote:
>Try it now (after revision 8862). What I did was make a local copy of
>CMakeFortranInformation.cmake modified (I hope) to allow what you want
>(check for Fortran platform files in ${CMAKE_MODULE_PATH}/Platform). I
>have checked (with temporary message commands) that
>cmake/
Alan W. Irwin wrote:
>
> Hi Arjen:
>
> Assuming I understand the naming conventions properly, I think you
> just need
> another Platform file called Windows-GNU-Fortran.cmake with the
> appropriate
> gfortran flags corresponding to the equivalent C flags in
> Windows-gcc.cmake.
> The location f
Alan W. Irwin wrote:
> Hi Robert:
>
> Thanks for your report for revision 8861, the latest svn trunk version
> of PLplot.
>
> Arjen, I have a question for you below.
>
> On 2008-10-07 17:40+0200 Robert Pollak wrote:
>
>
> [...]
>
>> cmake -G "NMake Makefiles" ^
>> -DCMAKE_BUILD_TYPE=%BUILD_T
Steve Schwartz wrote:
>Dear All,
>
>For your amusement, I attach a zipped archive with ps and svg files that
>were created by the plplot Qt driver we are working on. Qt has in-built
>routines to draw to a range of file formats (including I think png,
>tiff, jpeg plus ps and svg).
>
>The ps files l
Steve Schwartz wrote:
On Mon, 2008-10-06 at 13:48 +0200, Arjen Markus wrote:
I do not know if this will be a disappointment for you, but when I
printed via the humble lp command on an OCE printer we have here, it
comes out just fine. I am not sure about the margins (some of my
colleagues
Steve Schwartz wrote:
Hi Arjen,
On Mon, 2008-10-06 at 12:51 +0200, Arjen Markus wrote:
I have expressed myself somewhat inaccurately: the command by which I
send
the PostScript files to the printer is simply "lp". The printer
driver
that then gets
invoked will do all manner of
Steve Schwartz wrote:
>Hi Arjen,
>
>My observation is that one ought to be able to send the postscript file
>directly to a postscript printer (I've tried both HP and Xerox
>printers). Passing it through a filter (eps2eps, or whatever - most/all
>of which amount to passing it through ghostscript) r
Alan W. Irwin wrote:
> On 2008-10-06 09:29+0200 Arjen Markus wrote:
>
>> Alan W. Irwin wrote:
>>
>>> On 2008-10-02 22:04+0200 Arjen Markus wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> I am picking up the issue of gfortran
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 into
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
> 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
>
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
> 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
> h
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
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 libpl
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.
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
>
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
> 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 en
> 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
> On 2008-09-08 20:10+0200 Arjen Markus wrote:
>
>> Hello,
>>
>> it turns out that my TDM/MinGW gfortran installation is
>> incapable of linking even the simplest Fortran 90 programs:
>
> Hi Arjen:
>
> If Werner cannot find a way to help you get th
Hello,
it turns out that my TDM/MinGW gfortran installation is
incapable of linking even the simplest Fortran 90 programs:
I tried to compile this program:
! fmain.f90 --
! Simple Fortran program using a DLL
!
program fmain
integer :: x
x = 0
!call fvarset( x )
write(*,*) x
Alan W. Irwin wrote:
>
>Question for the Tcl experts here. Are those differing examples due to the
>string ==> float rounding issues with Tcl or are there deeper concerns?
>
>
Hello Alan,
that would be my first guess, though to make sure I should dive into it.
On the
Tcl side the conversion is
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., everyt
> Hi,
>
> the email below was somehow never sent, since it stayed in my Drafts
> folder, so I send it again.
>
> Werner
>
> Ok,
>
> one step forward. The import library libplplotf77cd.dll.a (to which is
> linked to) doesn't contain any symbols. If I change in plstubs.h
> STUB_LAU to
>
> #define FNA
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. Othe
Alan W. Irwin wrote:
> On 2008-09-04 08:10-0700 Rafael wrote the attached message concerning
> reducing the number of symbols that are exported from our libraries.
>
> I brought up this issue myself a month ago, and I think that wiki
> reference is worth repeating:
>
> "The wiki (http://gcc.gnu.or
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 instal
Andrew Ross wrote:
On Wed, Sep 03, 2008 at 08:48:13PM +0100, Andrew Ross wrote:
Just to confirm - I get this same error having installed tcl 8.5 on my
Ubuntu system. This is tcl 8.5.0 and tk 8.5.0. The itcl / itk version is
3.2.1.
Some quick debugging messages suggest the problem is due t
> 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
Werner Smekal wrote:
>Hi,
>
>after disabling ada (cmake -G "MinGW Makefiles" -DENABLE_ada=OFF
>..\..\plplot) cmake passes the configuration stage. Running make gives
>troubles with fortran 77 though:
>
>Scanning dependencies of target plplotf77d
>[ 52%] Building Fortran object
>bindings/f77/CMa
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 wor
>>> 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
901 - 1000 of 1166 matches
Mail list logo
