On Wed, Feb 19, 2014 at 5:10 PM, Jeremy Manson <jeremyman...@google.com> wrote: > > > > On Wed, Feb 19, 2014 at 1:22 AM, Magnus Ihse Bursie > <magnus.ihse.bur...@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.samers...@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