Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))))

[Volker Simonis]

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:
>>>>
>>>> Dan,
>>>>
>>>> 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
>>>> attributes.
>>>
>>> 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).

>
> Jeremy