Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))))
volker.simonis at gmail.com
Wed Feb 19 17:43:16 UTC 2014
On Wed, Feb 19, 2014 at 5:10 PM, Jeremy Manson <jeremymanson at google.com> wrote:
> On Wed, Feb 19, 2014 at 1:22 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> (Adding in build-dev since we're moving into the jdk build as well now.)
>> On 2014-02-17 17:39, Volker Simonis wrote:
>>> On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff
>>> <dmitry.samersoff at oracle.com> wrote:
>>>> It was my bad - missed two related threads.
>>>> We have two problems related to map files:
>>>> 1. We have hand-written mapfiles and have to manage it manually.
>>>> It's better to generate map file automatically or use visibility
>>> I would strongly vote against automatically generating the map files
>>> from sources by parsing for special patterns as proposed by Magnus
>>> because I think this will just introduce another level of complexity
>>> and another point of failure.
>> My priorities is to prefer no map files if we can avoid it, but to prefer
>> automatically generated over static, checked in, mapfiles if they cannot be
>> avoided. So I'll try to join you in the fight to get rid of them altogether,
>> but if that fails, I still want to generate them. :-) Having static map
>> files are a source of complexity and point of failure in itself as well.
>>> >From this discussion so far I learned the following:
>>> - as long as Oracle insists on static linking libstdc++ and libgcc
>>> there's no way of getting rid of the map files.
>>> - using -fvisibility=hidden/__attribute__((visibility("default"))) is
>>> still desirable because it has positive performance impacts on some
>>> platforms and because it is the easiest and cleanest solution for the
>>> future when we can finally get rid of the map files. Moreover it is
>>> already used anyway.
>> __attribute__((visibility("default"))) sounds very much like a gcc
>> extension. Is there a similar construct for solaris studio? Otherwise we
>> would still need mapfiles on solaris. Also, does
>> __attribute__((visibility("default"))) work with clang?
> I don't know the story for Solaris, but Clang supports this (they have
> almost complete gcc compatibility). Other compilers tend to have other
> kinds of support - I think MSVC has _declspec(dllexport).
> Note also that __attribute__ is now standard in c++11, although visibility
> is still gcc (and friends) specific.
> Since you seem to be meandering down this path, someone might want to check
> on what is needed for linker gc. I think you guys still compile hotspot
> with -export-dynamic (boo!). (Or, it might be more interesting to clean up
> dead code.)
As far as I can see, '-export-dynamic' is currently only used for
linking "adlc" (which is a build-time only tool).
More information about the build-dev