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

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


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