Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.

On Mon, 2011-09-05 at 11:28 +0200, Stephan Bergmann wrote:
> On Sep 4, 2011, at 11:47 PM, Norbert Thiebaud wrote:
> > why is there zlib/zlib.h and external/zlib/zlib.h ?
>
> At least on Linux, that would result in only one of the two versions of
> the external library being loaded, and the other dependee failing more
> or less badly.

A practical example was libjpeg, iirc the stock libjpeg is always
configured using platform endianness, while our internal one *was*
configured little endian (or the other way around, stock is always
little endian and we configured platform endian). So on solaris if you
used the image preview of the gnome file picker you got reversed colours
in jpegs seeing as the internal jpeg symbols got used and the gnome
dialog was built against the stock system jpeg.

The various workaround aren't consistent so its a bit of a horror show
at the moment anyway. As one aside, we should probably make the macosx
"system" libs the stock baseline for all the unixes at this stage, i.e.
system libxml2/xslt as well as the current system lz, libjpeg etc.

In the general case though, anyone got any ideas about a less fragile
more universal solution where we could automatically change sonames and
tweak symbol names so that *only* our own libs use/are affected by
symbols in these bundled libs ?

As an aside, for prettyness, it would be nice to have the external
headers and libs always installed in inc/external libs/external and add
-I -L to the compiler/linker to find them. I gave a go at this at one
stage but fell into some trap or other with the odbc headers IIRC

C.