On Jul 23, 2008, at 11:47 , Uwe Ligges wrote:
Simon Urbanek wrote:
On Jul 23, 2008, at 6:21 , Prof Brian Ripley wrote:
I updated one of by Windows' boxes to GTK 2.12.9, and replaced the
libcairo-2.dll in the Cairo binary distribution by that from GTK
2.12.9.
At that point Cairo and EBImage worked together, in either order.
I think Uwe may need to trigger a rebuild of his Cairo binary to
pick up Simon's updated libcairo-2.dll -- the existing binary is
not compatible with GTK 2.12.9.
I have released a new version of Cario on Monday just to trigger
this, so once CRAN is updated it should happen automatically.
Sorry, I'm currently a bit short of time:
- Should I install GTK 2.12.9 or does it work with older versions?
- So do I understand alright that I do not need to trigger anything
yet?
As far as I am concerned nothing needs to be done - Cairo package
pulls its own copy of libcairo-2 (1.6.4 which comes from GTK+) when
built and I have submitted a new version of Cairo to CRAN few days ago
so hopefully it will appear there sometime.
I don't know what EBImage needs, though...
Cheers,
Simon
Thanks,
Simon
On Tue, 22 Jul 2008, Prof Brian Ripley wrote:
On Mon, 21 Jul 2008, Simon Urbanek wrote:
Brian,
thanks for the analysis.
On Jul 21, 2008, at 6:29 , Prof Brian Ripley wrote:
On Mon, 21 Jul 2008, Sklyar, Oleg (London) wrote:
EBImage is dynamically linked against GTK, which includes cairo
libraries, so those are installed along with GTK. Cairo seems
to be
statically linking to libcairo.dll.a. I would assume that if
it is
That is an import library, so it is actually linked to
libcairo-2.dll, which it ships.
linked statically it should not get confused with a shared
library
present elsewhere in the path, but it looks like it does. I
have no
solution for that because unlike Cairo I cannot not statically
link
EBImage to GTK as it is not one library that I need, but a
bunch of
those.
On Linux you won't get this problem as it uses the same
centrally
installed Cairo library.
In a way it would be better, if Cairo relied on the
gladewin32.sf.net
which normally provides GTK (and thus cairo libraries) for
Windows and
linked dynamically, but probably to simplify user
installations the
developers wanted to avoid this.
It _is_ using dynamic loading, or there would be no conflict.
From the names, it looks very like that it is using a DLL from
gladewin32.
The real issue looks rather like a versioning problem, that the
cairo libraries installed as part of GTK and used by EBImage
are way too old (cairo_pdf_surface_create was added at cairo
1.2, and cairo is at 1.6.4). So updating to the current GTK
distribution may be all that is needed (and Henrik could also
try replacing your GTK's libcairo-2.dll by that distributed
with Cairo).
For compatibility sake I have updated the libcairo binary to
1.6.4 (based on GTK+ build), so if EBImage gets updated all
should be well.
EBImage relies on a user installation of GTK (AFAICS). Last
night I updated my GTK to 2.12.9 and used that's libcairo-2.dll
in Cairo. It all seemed to work.
There is not much I can do now about this, but I will follow
the thread
if anybody comes up with an idea to change the code if possible
The Cairo package (which ships DLLs) could rename them, as R
itself does where it builds its own versions. Or it could link
statically (if that works, which it does not for e.g. package
XML).
I'd rather not maintain my own build of libcairo for Windows
since I don't use it. I may consider renaming the DLL, but given
that I'm not building it from sources I'm not sure whether there
is a trivial way to do that.
If you are not building it yourself, then the only way is to use
an editor on the DLL to change the embedded name. I wouldn't
suggest you do that (I had thought you were building it yourself).
Best,
Simon
I don't really understand why this was posted to R-devel: it is
not an R issue.
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Henrik
Bengtsson
Sent: 19 July 2008 19:26
To: R-devel
Subject: [Rd] Clash between 'Cairo' and 'EBImage' packages on
Windows
Hi,
on Windows XP Pro with R version 2.7.1 Patched (2008-06-27
r46012) the 'Cairo' and the 'EBImage' packages does not play
well together.
Loading EBImage before Cairo cause the following to happen:
# Rterm --vanilla
library(EBImage);
library(Cairo)
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared library
'C:/PROGRA~1/R/R-2.7.1pat/library/Cairo/libs/Cai
ro.dll':
LoadLibrary failure: The specified procedure could not be
found.
Error : .onLoad failed in 'loadNamespace' for 'Cairo'
Error: package/namespace load failed for 'Cairo'
with a dialog titled 'Rterm.exe - Entry Point Not Found'
saying 'The procedure entry point cairo_pdf_surface_create
could not be located in the dynamic link library
libcairo-2.dll'.
Loading the packages in the reverse order works, but the
Rterm seems unstable, e.g. calling q() immediately after will
exit the R session without questions:
# Rterm --vanilla
library(Cairo)
library(EBImage)
q()
[Immediately back to the command line].
I cannot reproduce the problem on R v2.7.1 on Ubuntu Hardy.
sessionInfo()
R version 2.7.1 Patched (2008-06-27 r46012)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MON ETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets
methods base
other attached packages:
[1] EBImage_2.4.0 Cairo_1.4-2
Cheers
Henrik
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
**********************************************************************
The contents of this email are for the named addressee(s...
{{dropped:22}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/
~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel