Darin Adler wrote:
> I don’t remember if anyone answered you.
You're the first, but thanks for the response.
> A simple way to transform the library into one with private extern would be
> to use ld and -r, -exported_symbol or -exported_symbols_list, and
> -keep_private_externs to make all the symbols private. This would eliminate
> any need to get a new version of the library from someone at Apple, and
> should be quite simple to do. The only thing I don’t know is how to say “no
> exported symbols”, but it could be as simple as -exported_symbols_list
> /dev/null -- you should give it a try.
This would work, but the steps to prepare it get a little bit heinous.
I'd need to "lipo -thin" it first to break it up by architecture, and
then "ar -x" it to break it up into .o files. Then it's ld as you
describe, "ar -rc" to get it back into a .a, and "lipo -create".
Sure, it's doable, but with the way our build is structured now, we
don't really do anything with libWebCoreSystemInterfaceLeopard.a
outside of WebCore.gyp, which is now in your repository, so all of
these machinations would really belong there...
For that matter, I considered just writing something to rewrite the
archive and set N_PEXT on everything in the symbol tables. Same
effect, more work, fewer temporary files.
> I believe the problem occurs because the Chromium build uses a different
> method for controlling what’s exported than what we use in the standard Mac
> OS X WebKit build, which uses -exported_symbols_list.
Yup, that's right. The first thing I tried, which involved minimal
boat-rocking, was to "strip -R" our output to trim the symbols we
didn't need. That would have been fine, except in order to do it
properly, I'd have to enumerate libWebCoreSystemInterfaceLeopard.a's
symbols first. With archive member selection and dead code stripping,
the set of symbols that we'd see in the linked product isn't fully
deterministic, though, and Apple's "strip -R" gives an error when it's
can't find a symbol that it's told to remove. Oh well.
Would these libraries with private extern symbols be unsuitable for
Apple's WebKit build? The easiest approach, if it would work for you,
would just be to build those libraries with -fvisibility=hidden
(GCC_SYMBOLS_PRIVATE_EXTERN=YES), check them in, and call it a day.
I'd be surprised if you ever needed these symbols exported now or in
the future, and "grep WK $(find . -name \*exp)" doesn't show anything.
Mark
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
