mono-addins and pango

[Bart Masschelein]

On 31 Oct 2008, at 22:55, Ryan Schmidt wrote:

> On Oct 31, 2008, at 16:32, Bart Masschelein wrote:
>
>> --->  Configuring pango
>> Error: Target org.macports.configure returned: configure failure:  
>> shell command " cd "/opt/local/var/macports/build/ 
>> _opt_local_var_macports_sources_rsync 
>> .macports.org_release_ports_x11_pango/work/pango-1.22.2" && ./ 
>> configure --prefix=/opt/local --x-includes=/usr/X11R6/include --x- 
>> libraries=/usr/X11R6/lib --enable-static --enable-cairo " returned  
>> error 1
>> Command output: appending configuration tag "CXX" to libtool
>> checking for ld used by /usr/bin/g++-4.0... /usr/libexec/gcc/i686- 
>> apple-darwin9/4.0.1/ld
>> checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ 
>> ld) is GNU ld... no
>> checking whether the /usr/bin/g++-4.0 linker (/usr/libexec/gcc/i686- 
>> apple-darwin9/4.0.1/ld) supports shared libraries... yes
>> checking for /usr/bin/g++-4.0 option to produce PIC... -fno-common
>> checking if /usr/bin/g++-4.0 PIC flag -fno-common works... yes
>> checking if /usr/bin/g++-4.0 static flag -static works... no
>> checking if /usr/bin/g++-4.0 supports -c -o file.o... yes
>> checking whether the /usr/bin/g++-4.0 linker (/usr/libexec/gcc/i686- 
>> apple-darwin9/4.0.1/ld) supports shared libraries... yes
>> checking dynamic linker characteristics... darwin9.5.0 dyld
>> (cached) (cached) checking how to hardcode library paths into  
>> programs... immediate
>> appending configuration tag "F77" to libtool
>> checking for some Win32 platform... no
>> checking for perl5... no
>> checking for perl... perl
>> checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/ 
>> include
>> checking whether -R must be followed by a space... no
>> checking for gethostbyname... yes
>> checking for connect... yes
>> checking for remove... yes
>> checking for shmat... yes
>> checking for IceConnectionNumber in -lICE... yes
>> checking for FONTCONFIG... no
>> checking Carbon/Carbon.h usability... yes
>> checking Carbon/Carbon.h presence... yes
>> checking for Carbon/Carbon.h... yes
>> checking for CAIRO... no
>> checking for GLIB... configure: error:
>> *** Glib 2.17.3 or better is required. The latest version of
>> *** Glib is always available from ftp://ftp.gtk.org/.
>
> Note it's not finding fontconfig or cairo either, which are also  
> required by pango.
>

Both of which I have installed...

> The output in your pango.txt is different from what you pasted  
> above. In pango.txt, it is finding fontconfig, cairo, glib2 and  
> everything else, and building correctly.
>
> Not sure why it's different now than before, though it could easily  
> have been the Leopard Tcl environment variable bug, since it has so  
> many and varied symptoms:
>
> http://trac.macports.org/wiki/LeopardProblems#environmentvariablesbecomeblankbetweenconfigureandbuildphases

I called both commands right after each other, so in the end the only  
difference is that first I did 'upgrade mono-addins', and second I  
used 'install pango', as you suggested. But that does not tell me  
much. It does not seem to be related to the bug you mention, but I'm  
no expert.

>> When I try upgrading now, using sudo port upgrade mono-addins, I  
>> get the following:
>>
>> --->  Activating giflib 4.1.6_0
>> Error: Activating giflib 4.1.6_0 failed: Image error: /opt/local/ 
>> bin/gif2epsn is being used by the active libungif port.  Please  
>> deactivate this port first, or use the -f flag to force the  
>> activation.
>> --->  Activating pango 1.22.2_0
>> Error: Activating pango 1.22.2_0 failed: Image error: Another  
>> version of this port (pango @1.22.0_0) is already active.
>> --->  Activating pango 1.22.2_0
>> Error: Activating pango 1.22.2_0 failed: Image error: Another  
>> version of this port (pango @1.22.0_0) is already active.
>>
>> About the first error, is it in general ok to force the activation?  
>> To me it sounds not recommendable.
>
> No. Instead, you should deactivate libungif and then activate  
> giflib. There is unfortunately some confusion between giflib and  
> libungif. libungif was created while the GIF algorithm was still  
> covered by a patent. The patent has since expired, so now the full  
> giflib is preferred. But many ports still depend on libungif. Those  
> that can should be upgraded to use giflib. Those that can't should  
> have bugs filed with their developers.

Thanks for the explanation. Will help me remember this issue.

>> The second error is more weird. After using your commands (sudo  
>> port clean pango; sudo port -d install pango 2>&1 | tee ~/Desktop/ 
>> pango.txt; bzip2 ~/Desktop/pango.txt ), it went through, but it was  
>> not able to activate. It should automatically desactivate the old  
>> and install the new one, no?
>
> No, since you used "install". If you had used "upgrade" instead, it  
> would have done so. So now you should:

Is this actually true, or is it a typo, a slip of mind? The answer  
might be interesting. Because it is actually the opposite: I used  
upgrade, and you told me to use install. What is in fact the  
difference between install of an existing port, or upgrading it? Maybe  
install uses the existing ports on which it depends, while upgrade  
tries to upgrade the dependencies as well?

Bart