Hi Alan,
Thanks for this information - I will look up these pages (and forward this
information to Sebastian 😉).
Regards,
Arjen
-Original Message-
From: Alan W. Irwin
Sent: 23 February 2022 21:50
To: Arjen Markus
Cc: PLplot development list
Subject: Re: [Plplot-devel] Cross
On 2022-02-23 07:23- Arjen Markus wrote:
Hi,
Sebastian Ehlert asked me about cross-compilation of PLplot for different
platforms as part of cond-forge/plplot-feedstock. He found out that this needs
to be done in two steps, one to build the auxiliary programs for use on the
native platfor
On 2009-03-10 20:07-0700 Alan W. Irwin wrote:
> To finish up this effort, I plan to rename get-drv-info as test-drv-info and
> make a series of tests comparing its output with the *.rc files that are
> configured by CMake.
DONE (revision 9725). The TEST_DYNDRIVERS option is ON by default and is
On 2009-03-06 08:11-0800 Alan W. Irwin wrote:
> On 2009-03-06 07:17- Andrew Ross wrote:
>
>> On Wed, Mar 04, 2009 at 07:37:53PM +, Andrew Ross wrote:
>>> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
Instead of this approach, I think we should simply store those .rc
On 2009-03-06 07:17- Andrew Ross wrote:
> On Wed, Mar 04, 2009 at 07:37:53PM +, Andrew Ross wrote:
>> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
>>> Instead of this approach, I think we should simply store those .rc
>>> files in the drivers subdirectory of the source tree
On Wed, Mar 04, 2009 at 07:37:53PM +, Andrew Ross wrote:
> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
> > On 2009-03-04 10:58- Andrew Ross wrote:
> >
> >> Thinking about it, get-drv-info is only extracting symbols for the
> >> installed
> >> drivers which are in the source
OK after many, many steps, I built x01c.c for x86_64 windows from an
ubuntu x86_64 box. pngcairo works fine. Mono and color ps crashes
though. Also I never was able to disable pkg-config, which may or may
not be why during the build process I had to obtain the import libs for
things like freety
Thomas Stover wrote:
> Andrew Ross wrote:
>> Agh! I think the problem might be that the .rc files are blank.
>> Just as a test could you try addding the following to cairo.rc
>> (include only the lines referring to the drivers you have)
>>
>> xcairo:Cairo X Windows Driver:1:cairo:59:xcairo
>> pdfca
Andrew Ross wrote:
> Agh! I think the problem might be that the .rc files are blank.
> Just as a test could you try addding the following to cairo.rc
> (include only the lines referring to the drivers you have)
>
> xcairo:Cairo X Windows Driver:1:cairo:59:xcairo
> pdfcairo:Cairo PDF Driver:0:cairo:
On 2009-03-04 19:37- Andrew Ross wrote:
> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
>> On 2009-03-04 10:58- Andrew Ross wrote:
>>
>>> Thinking about it, get-drv-info is only extracting symbols for the installed
>>> drivers which are in the source code anyway. There is no
On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
> On 2009-03-04 10:58- Andrew Ross wrote:
>
>> Thinking about it, get-drv-info is only extracting symbols for the installed
>> drivers which are in the source code anyway. There is no reason we couldn't
>> have some alternative way of
On Wed, Mar 04, 2009 at 01:12:03PM -0600, Thomas Stover wrote:
>
> >>
> >> -Anyway, example1 runs on my windows machine with this errorish
> >> condition:
> >> *** PLPLOT ERROR, ABORTING OPERATION ***
> >> plInitDispatchTable: Could not open drivers directory, aborting
> >> operation
> >> PLplot
>>
>> -Anyway, example1 runs on my windows machine with this errorish
>> condition:
>> *** PLPLOT ERROR, ABORTING OPERATION ***
>> plInitDispatchTable: Could not open drivers directory, aborting
>> operation
>> PLplot library version: 5.9.2
>> got here -- 0
>
> You are using the dynamic drivers
On 2009-03-04 10:58- Andrew Ross wrote:
> Thinking about it, get-drv-info is only extracting symbols for the installed
> drivers which are in the source code anyway. There is no reason we couldn't
> have some alternative way of doing this using cmake or some scripting which
> would not rely on
On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote:
> On 2009-03-03 12:49- Andrew Ross wrote:
>
> > On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
> >> [...]In sum, my advice [to Thomas was] to stick with CMake (since we
> >> should be able to give
> >> you some help in t
On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote:
> On 2009-03-03 12:49- Andrew Ross wrote:
>
>> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
>>> [...]In sum, my advice [to Thomas was] to stick with CMake (since we should
>>> be able to give
>>> you some help in that c
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 Thomas,
>
> -I'm guessing that I need to try this with the SVN tree. I'm on rev
> 9667.
>
> -I think sometimes CMake does some config caching or something that
> gets in the way big time, and I can't figure out how to clear or
> disable it. What are you suppose to do? I've been just start
On 2009-03-03 17:59-0600 Thomas Stover wrote:
>
>>>
>>> The current stumbling block for the cairo drivers is that they use
>>> pkg-config to get the correct paths and libraries to link in. This won't
>>> work on a cross-compiled environment unless you provide suitable
>>> pkg-config
>>> files fr
Thomas Stover wrote:
>
> -Also extcairo wont work by itself. At least one other cairo based
> driver needs to be turned on for a successful build. Not just with cross
> compiles, but in general.
>
That was a problem with the cairo.cmake file, extcairo should build by
itself now (as of v9671).
>>
>> The current stumbling block for the cairo drivers is that they use
>> pkg-config to get the correct paths and libraries to link in. This won't
>> work on a cross-compiled environment unless you provide suitable
>> pkg-config
>> files from a cross-compiled version of cairo. This should be po
On 2009-03-03 12:49- Andrew Ross wrote:
> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
>> [...]In sum, my advice [to Thomas was] to stick with CMake (since we should
>> be able to give
>> you some help in that case, and CMake skill with a normal build environment
>> and also a
Andrew Ross wrote:
> Thomas,
>
> I've now done the necessary changes to plplot to allow a cmake
> cross-compilation of at least the basic library. See the plplot wiki
> http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page
> for instructions. I have cross-compiled for mingw32 under linu
On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
> On 2009-03-02 11:38-0600 Thomas Stover wrote:
>
> > Thanks for the input on cross compiling with cmake. Using the latest
> > version
> > of cmake, and the documentation I made a number of attempts to use mingw to
> > build a win32 pl
Hi,
On 02.03.2009, at 22:57, Alan W. Irwin wrote:
> On 2009-03-02 14:57-0600 Thomas Stover wrote:
>
>> Is there an "official" precompiled release for win32 and/or win64?
>
> That has been discussed since it is fairly straightforward to do that
> with CMake, but it hasn't actually happened yet.
I
On 2009-03-02 14:05-0600 Thomas Stover wrote:
> Alan W. Irwin wrote:
>> Specifically, build just the plplot C library (with libqhull and freetype
>> dropped to eliminate those dependencies and with no dynamic drivers to
>> eliminate the dependence on dynamic loading libraries)
>
> What features g
Is there an "official" precompiled release for win32 and/or win64? If
that were the case I would just use that, and bring it into my cross
environment. On the other hand, if the standard installation is for one
is to build their own for maximum tool chain & platform compatibility,
then cross c
On 2009-03-02 14:57-0600 Thomas Stover wrote:
> Is there an "official" precompiled release for win32 and/or win64?
That has been discussed since it is fairly straightforward to do that
with CMake, but it hasn't actually happened yet.
Alan
__
Alan W. Irwin
Astronomical re
Hi Alan and Thomas,
>
> Once you get that first simple cross-build working properly, then I think
> the next step is to figure out what to do with dynamic devices. That
> does
> work on MinGW so it should be straightforward to get it to work for a
> Linux
> cross-build for MinGW, but I am not fa
I have no idea why this works, but it seems to! All I changed is the
data dir. This is astonishing. Surely there must be some problems that
show up later. I think I'm missing support for some major stuff - were
does this nearest neighbors library come into the picture? Never the
less, here is a
On 2009-03-02 11:38-0600 Thomas Stover wrote:
> Thanks for the input on cross compiling with cmake. Using the latest version
> of cmake, and the documentation I made a number of attempts to use mingw to
> build a win32 plplot from a linux host. By the end of the day Friday I
> reached the concl
Correction, it works. I just had to properly set the hard coded data
directory. Actual cross compile test comming soon...
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the b
Hi Thomas,
just for the records, since you already figured it out yourself:
> *** PLPLOT ERROR, IMMEDIATE EXIT ***
> Unable to either (1) open/find or (2) allocate memory for the font file
> Program aborted
Here, PLplot can't find the Hershey fonts, which are in the PLplot data
directory. Actuall
Alan W. Irwin wrote:
> I think doing your own specific Makefile based build system for PLplot
> would
> work, but I also think it would take a rather large effort on your
> part with
> no beneficial networking effects at all (nobody else would use your
> approach
> so you could gain little help
34 matches
Mail list logo
