[Libreoffice] [REVIEW] linking against a .a and *not* exporting those symbols.

On Wed, 2011-07-27 at 13:01 +0100, Michael Meeks wrote: 
> On Wed, 2011-07-27 at 09:18 +0100, Caolán McNamara wrote:
> > >   Or perhaps I mis-understood ;-) is it easy to inject those flags ?
> >
> > Not particularly easy, but ended up doing that anyway.
>
>       Great - and I hope it works :-)

Apparently, crash-be-gone anyway, nm -D gives me what I expect now on
the final .so. I'd like to propose that fix
1022b20da6e234349b9c8d094670297a8e523c86 in libs-extern for 3-4.

>       Sure - but we can't apply a map file to a .a - it is just an archive of
> object files; we'd need to apply it to all those that link against it.

Yeah, it's not the .a file that gets munged if that approach was taken,
but the .so into which it gets linked, i.e. the above pseudo-example
would get passed to the linker when making liboox. So in the generic
case the above would need to get run over all -lfoo.a's getting linked
into a final (otherwise visibility controlled).so target to get a single
linker-map for use with that final .so target.

> and of course map-files are nastily non-portable and ...
>
> > Anyway, for this specific case we currently build both shared and static
> > libs in openssl, but indeed only deliver and use the static ones under
> > unix platforms.
>
>       Ah ok; glad we don't deliver the shared one.

Yeah, on the other hand this means that we link the static openssl libs
to about three or so other libs which isn't awesome either. Someone with
sufficient cunning would likely be able to use libnss instead for some
of those openssl usages instead.

> > d) We then have to *just* build with make build_libs to avoid building
> > the openssl demos and tools which would attempt to link against the new
> > useless shared libs that export no symbols
>
>       Ah - right :-) I forgot that; then again - though it's a pain - might
> help accelerate & shrink our make ?

Yup, silver lining is that it's a titchy bit faster to build now.

> ... - or comment in the makefile.mk with the above contained
> for the next unlucky victim

part of patch, yes.

C.