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

Simon Urbanek simon.urbanek at r-project.org
Wed Jul 23 15:05:13 CEST 2008


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.

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



More information about the R-devel mailing list