cairo configure fails due to odd fontconfig pkgconfig .pc file

[dbsgeo@…]

I'm on snow leopard, 10.6.2.

The fontconfig.pc generated by the latest fontconfig +universal port has these lines:

#ifndef __LP64__
Libs.private:  -lexpat -L/opt/local/lib -lfreetype -lz -liconv
#else /* __LP64__ */
Libs.private:  -lexpat -L/opt/local/lib -lfreetype -lz 
#endif /* __LP64__ */

such that when you ask for the libs you get an error response:

$ pkg-config --libs fontconfig
Libs.private field occurs twice in '/opt/local/lib/pkgconfig/fontconfig.pc'

I think this is what is now breaking the cairo configure step:

checking for png... yes
checking whether cairo's PNG functions feature could be enabled... yes
checking for cairo's FreeType font backend feature... 
checking for FONTCONFIG... no
no
checking whether cairo's FreeType font backend feature could be enabled... no (requires fontconfig)
configure: error:  FreeType font backend feature could not be enabled

Warning: the following items did not execute (for cairo): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

As changing the .pc lines to:

Libs.private:  -lexpat -L/opt/local/lib -lfreetype -lz -liconv

...allows cairo to compile.

[ryandesign@…]

Please see #20727 for this specific problem, #21953 for the more general problem with pkgconfig files, and #20728 for the most general problem for all ports.

[dbsgeo@…]

ah, okay, very sorry I missed those other tickets, and thanks for the reference.

[ryandesign@…]

Do those pointers help you to install these ports properly? I think you just need to do what it says in #20727 and reinstall libiconv with the universal variant ("sudo port upgrade --enforce-variants libiconv +universal"), then rebuild fontconfig (I just updated fontconfig to 2.8.0 today so if you "sudo port selfupdate" you should then be able to "sudo port upgrade fontconfig"). Then if you clean cairo ("sudo port clean cairo") you should be able to install it. Let me know if this works.

[dbsgeo@…]

Yes, I'm sure they will, so feel free to close as invalid.

And, to be honest I'm doing something else which may be compounding the issue.

I'm experimenting with compiling and linking cairo and cairo deps against the system (snow leopard) provided zlib and libiconv. In this case the goal is to package the cairo dylibs into a relocatable Framework for distribution/packagmaker install. Previously I was happily packaging up zlib and libiconv and all the other cairo/cairomm dependencies, but after a review by other more experienced packagers it was recommended to not bundle zlib and libiconv from macports since the system provides universal libs already without XCode, so I've been (up to cairo at least) successfully installing the universal variant of zlib and libiconv and then overwriting all of the libs with a symlink to the system lib. Stuff like libpng and freetype have been building fine and linking to the system libs.

I'm certainly open to suggestions for smarter ways to do this, and I don't want to cause any undu burden by creating tickets due to my odd setup. How do others distribute macports built libs while compiling and linking to system libs where appropriate? In this case install_name_tool won't work because the major lib compatibility version of libiconv is different.

[ryandesign@…]

You could try asking those questions on a MacPorts mailing list. But you're pretty much in uncharted and unsupported territory. You're trying to make MacPorts do things it's not designed to do. Doesn't mean it won't work, but it may be hard to find someone who will know how to help you.

libiconv is 4.4MB installed on my system; zlib is 672K. It may be possible to get your distribution to use the system libiconv and zlib instead, but it may not be worth the effort just to save 5MB. 2.3MB of that is static ".a" libraries, by the way; you could safely delete all the static libraries before packaging to save that space.