Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))))
jeremymanson at google.com
Wed Feb 19 16:10:26 UTC 2014
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
More information about the build-dev