Re: [Libreoffice] linking against a .a and *not* exporting those symbols ?

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 :-)

>  I was sort of hoping for a fire-once solution which could be wrapped
> around all .a files we link against without having to go around custom
> hacking various externals. Those makefile.mks are already in
> impossible-to-read land :-(

        Yes - horrible :-)

> something like...
>
> echo "FOO {"
> echo "    local:"
> nm --defined-only -g *.a | grep -v "^$" | grep -v : | cut -d' ' -f 3 |
> sed 's/.*/&;/'
> echo "    global:"
> echo "        *;"
> echo "};"
>
> would probably work to generate a suitable map file, but then have to
> collect up which libs are .a's on a given link execution, generate a
> single map file from them, pass it to the compiler, etc. etc. 

        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;
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.

> a) We can't disable shared libs, because then the static libs build
> without -fPIC, and aren't suitable for inclusion into a final .so
> b) We can't just use CFLAGS because the openssl build system doesn't use
> honour it
> c) We can munge the flag in through $CC however
> 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 ?

        Thanks so much for unwinding it all ! prolly worth adding a README in
that directory - or comment in the makefile.mk with the above contained
for the next unlucky victim that has to gnumake-ify it ;-)

        Regards,

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot