[Rd] Clash between 'Cairo' and 'EBImage' packages on Windows

Mon Jul 21 19:40:02 CEST 2008

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.

>> 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.

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
>> osklyar at maninvestments.com
>>
>>> -----Original Message-----
>>> From: r-devel-bounces at r-project.org
>>> [mailto:r-devel-bounces at r-project.org] 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 at 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>