In message <[EMAIL PROTECTED]>, Gregory Shimansky writes:
>
> Mark Hindess said the following on 16.06.2008 11:10:
> > I think we should stop linking static lib{png,jpeg,lcms} on linux
> > 32-bit (and any ports that also use this by default). We link these
> > dynamically on linux/x86_64 and if it is good enough for that platform I
> > don't see why it wouldn't be good enough for any other platforms. The
> > APIs for all three libraries are very stable and making the dependencies
> > consistent would help simplify the depends.xml.
> >
> > Furthermore, I'd be tempted to by-pass the symlinking process altogether
> > and just checking that the headers/libraries are available at
> > depends.xml time and then link against them directly with -lpng etc.
> >
> > Comments?
>
> It was Geir who insisted on static linking. He said that for
> certification it is necessary to have a binary with all of its
> dependencies inside of it. I don't know if it is true, but Sun seems to
> be using static libraries...
Thanks for refreshing my memory.
This reasoning is/was flawed (and I'm sure I would have said so at
the time). We don't statically link libc, libX11, etc. or indeed
several libraries (font-related ones for example) with much less stable
APIs/implementations and which could have much broader impact on the
ability to pass the jck. I think we should define some criteria so that
we are clear what the benefits are and so that we make this decision
consistently/consciously.
> On x86 Linux it is usually possible to create a shared library and link
> it against a static library that was not built with -fPIC. But on x86_64
> static library that wasn't built with -fPIC cannot be linked to a shared
> library. Also not all of the distros provide static versions of
> libraries at all and none of them provide static libraries that are
> built with -fPIC option. That is why we use dynamic ones for classlib
> dependencies.
Yes. I vaguely remembered this part.
Regards,
Mark.
