[tlbuild] yet another progress report from Utah: OpenBSD (mostly a success)

[Jonathan Kew]

On 5/5/12 12:17, Peter Breitenlohner wrote:
> On Fri, 4 May 2012, Nelson H. F. Beebe wrote:
>
>> It isn't an OpenBSD thing: it happens on ALL of the platforms that
>> I've built on. I personally suspect that it is a bug in the
>> source/Work/texk/kpathsea/Makefile, which has
>>
>> libkpathsea.la: $(libkpathsea_la_OBJECTS)
>> $(libkpathsea_la_DEPENDENCIES) $(EXTRA_libkpathsea_la_DEPENDENCIES)
>> $(libkpathsea_la_LINK) -rpath $(libdir) $(libkpathsea_la_OBJECTS)
>> $(libkpathsea_la_LIBADD) $(LIBS)
>>
>> Notice that $(LIBS) appears at the end of that command.
>
> That is the way Automake+Libtool work. LIBS is intended for things detected
> by configure such as '-lm'.
>
>> LIBS='/usr/local/lib/libfontconfig.a /usr/lib/libexpat.a
>> /usr/local/lib/libfreetype.a /usr/local/lib/libbz2.a
>> /usr/local/lib/libz.a -lm'
>
> You are forcing these libraries onto every binary - Libtool treats
> executables and (static and/or shared) libtool-libraries on similar
> footing.
>
> Since your setting of LIBS works, I assume there are no shared
> libfontconfig
> etc in your library search path.

AIUI, static-linking with fontconfig is generally a bad idea.

Such binaries may work OK on the system where they were created, if all 
programs there are using exactly the same version of fontconfig, but are 
unlikely to interoperate well anywhere else. E.g. if they're run on a 
system where the installed (shared) fontconfig is a different version, 
the font caches are likely to be incompatible; the local font 
configuration that the user expects may not even be found, if the 
installed fontconfig was set up to use a different location for its 
config files.

The point of fontconfig is to provide a font configuration that's shared 
across the user's entire desktop environment, rather than having to be 
configured separately for each program. That will only work reliably if 
all applications are linked with the same shared fontconfig library.

JK