cairo install fails (was: Building cairomm (inkscape dependency) fails)

[Ryan Schmidt]

On Apr 20, 2008, at 7:25 PM, Mike McAngus wrote:

> On Apr 20, 2008, at 4:42 PM, Ryan Schmidt wrote:
>
>> On Apr 20, 2008, at 5:34 AM, sourceforge.rocks at xemaps.com wrote:
>>
>>> On Apr 18, 2008, at 10:59 AM, "Jason Merrill" wrote:
>>>
>>>> I've been trying to get the latest version of inkscape going,  
>>>> and I've
>>>> run into some trouble installing cairomm:
>>>>
>>>> jmerrill:Frameworks jm843$ sudo port clean cairomm
>>>> --->  Cleaning cairomm
>>>> jmerrill:Frameworks jm843$ sudo port install -d cairomm
>>>> --->  Fetching cairomm
>>>> --->  Verifying checksum(s) for cairomm
>>>> --->  Extracting cairomm
>>>> --->  Applying patches to cairomm
>>>> --->  Configuring cairomm
>>>> --->  Building cairomm with target all
>>>> Error: Target org.macports.build returned: shell command " cd
>>>> "/opt/local/var/macports/build/ 
>>>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_gr 
>>>> aphics_cairomm/work/cairomm-1.6.0"
>>>> && make all " returned error 2
>>>
>>> 8<-----snip----
>>>
>>> I get a similar error when trying to install cairo 1.6.4 in the  
>>> following environment:
>>>
>>>     Mac OS X 10.4.11
>>>     PowerPC G4
>>>     Xcode 2.5
>>
>> [snip]
>>
>>> /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include - 
>>> I. -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/ 
>>> local/include -I/opt/local/include/libpng12 -DXTHREADS -I/opt/ 
>>> local/include -I/usr/X11R6/include -I/usr/X11R6/include -I/opt/ 
>>> local/include/pixman-1 -Wall -Wextra -Wsign-compare -Werror- 
>>> implicit-function-declaration -Wpointer-arith -Wwrite-strings - 
>>> Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations - 
>>> Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute  
>>> -Wstrict-aliasing=3D2 -Winit-self -Wdeclaration-after-statement - 
>>> Wold-style-definition -Wno-missing-field-initializers -Wno-unused- 
>>> parameter -Wno-long-long -Winline -fno-strict-aliasing -O2 -MT  
>>> libcairo_la-cairo-quartz-surface.lo -MD -MP -MF .deps/libcairo_la- 
>>> cairo-quartz-surface.Tpo -c cairo-quartz-surface.c -fno-common - 
>>> DPIC -o .libs/libcairo_la-cairo-quartz-surface.o
>>> cairo-quartz-surface.c: In function 'quartz_ensure_symbols':
>>> cairo-quartz-surface.c:144: error: 'RTLD_DEFAULT' undeclared  
>>> (first use in this function)
>>> cairo-quartz-surface.c:144: error: (Each undeclared identifier is  
>>> reported only once
>>> cairo-quartz-surface.c:144: error: for each function it appears in.)
>>> make[2]: *** [libcairo_la-cairo-quartz-surface.lo] Error 1
>>> make[1]: *** [all-recursive] Error 1
>>> make: *** [all] Error 2
>>> Error: Status 1 encountered during processing.
>>
>> Your error does not seem similar to the one Jason encountered.
>
> I'm sorry, to this naive user they looked like they were starting  
> out very similarly.
>
>> Jason's error was "/System/Library/Frameworks/ 
>> CoreServices.framework/Frameworks/CarbonCore.framework/Headers/ 
>> MachineExceptions.h:255: error: declaration does not declare  
>> anything", was a result of running on Leopard, and was fixed by  
>> modifying the cairomm Portfile to work around the Leopard behavior.
>>
>> Your error is "cairo-quartz-surface.c:144: error: 'RTLD_DEFAULT'  
>> undeclared (first use in this function)"
>>
>> Googling for that, I found this thread:
>>
>> http://www.zeroc.com/forums/patches/408-patch-build-ice-1-2-0- 
>> macos-x-10-3-a.html
>
> OK, so I should have known the significance of the lines at the end  
> of the error messages, and not have focused on the similarities at  
> the beginning of the error messages.

Right, all build errors encountered by any port will begin with a  
line like:

Error: Target org.macports.build returned: shell command "cd "/opt/ 
local/var/macports/build/ 
_opt_local_var_macports_sources_rsync.macports.org_release_ports_whateve 
r_whatever/work/whatever" && make whatever" returned error whatever

That line is generated by MacPorts. Then what follows is the output  
from that command (in this case the make all command) which tells us  
specifically what error occurred in that specific port.


>> It suggests that you may have something installed in /usr/local,  
>> specifically /usr/local/include/dlfcn.h, which is interfering with  
>> the (in this case cairo) build process.
>>
>> When using MacPorts, it is recommended not to have anything in / 
>> usr/local. What do you have there any why? Can you install it with  
>> MacPorts instead?
>
> Where is this recommendation documented?  I don't find it in the  
> MacPorts Guide which is what comes up when you click on the  
> Documentation link on the MacPorts home page.

You're right. I don't see it documented in the Guide either. I filed  
a ticket to get this documented:

http://trac.macosforge.org/projects/macports/ticket/15077

> I did not consciously install anything in /usr/local.  Looking in  
> there, I see
> *  ClamXav directory.  I could probably replace ClamXav with clamav  
> from MacPorts if I was willing to give up the UI.
> *  A "SourceGuard" directory which I don't recognize.  All of its  
> files have Created, Modified and Accessed dates of 9/3/03.

These are not a problem. It's only things installed "directly" in / 
usr/local (that is, that were compiled with --prefix=/usr/local or  
which install into prefix /usr/local by default) which can cause  
problems.

> *  A bin, include, lib, man and share directory.  There are many  
> files in those directories.

These are the potentially problematic files, especially the bin,  
include and lib directories.

> The include directory contains ONLY the dlfcn.h file.  Its Created,  
> Modified and Accessed dates are all 5/8/02, which I find  
> interesting since the introduction date of the Power Mac G4 with  
> dual 1.25MHz processors is  8/13/02 and I bought mine in Feb 2003.   
> So, I guess there is no way to know for sure when a file was  
> actually installed onto the disk.

Yeah, not sure what put that there. All you can be sure of is that  
Apple does not provide anything in /usr/local, so it's definitely  
third-party. MacPorts and Fink don't put anything there either.

> All this is information that relates to the fact that I originally  
> installed cairo 3 or 4 months back when I installed Wireshark.  I  
> only encountered this issue when I found that cairo was outdated  
> and I tried to upgrade it.  I went so far as to force an uninstall  
> of cairo in a vain attempt to reinstall it.
>
> I've only been using MacPorts for a few months, but I find the  
> promise of regular and timely upgrades to installed software to be  
> balanced out by the frustrations that I encounter while trying to  
> install or upgrade applications.  Most of the time, I muddle through.
>
>> Move /usr/local aside (by renaming it to /usr/local-off for  
>> example), clean cairo, and try installing again, and it should work.
>
> Now, to the good news.  I renamed usr/local/include to usr/local/ 
> include.hold and the cairo install succeeded.  So, I have Wireshark  
> back.

I'm glad to hear that!

> I'm still curious how my initial install of wireshark succeeded if,  
> and I realize that this may be a big if, the /usr/local/include/ 
> dlfcn.h file has existed for more than a few months.

Maybe the older version of cairo didn't make use of the definitions  
in that file, and now it does. I don't know. The problem is the  
compiler will look to /usr/local for include file and libraries even  
if you don't tell it to. Therefore we recommend not having anything  
in there, so that we know that everything your ports link with were  
installed by other ports.