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

[Jeremy Manson]

You're right - I misread it.

Jeremy


On Wed, Feb 19, 2014 at 9:43 AM, Volker Simonis <volker.simonis at gmail.com>wrote:

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