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

[Jeremy Manson]

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

Jeremy