On 26 September 2015 at 00:59, Sedat Dilek <sedat.di...@gmail.com> wrote: > Hi, > > unfortunately, we still have no cool upstream fix for > -fvisibility=hidden compiler flag handling. > There is still no visibility-attribute "hidden" available or defined. > These two are separate things, as Alan pointed out. The -fvisibility param should not be taken that the __attribute__(visibility(("hidden"))) is available and vice-versa.
> I see people again fell over this issue [2]. > > I have one concern... > > GCC uses "default" visibility-attribute (defined as PUBLIC) when > compiler-flag "-fvisibility=hidden" is used. > But CLANG needs in some cases "hidden" visibility-attribute. > Is that irrespective of the mapi issue at hand ? If so this is a definite clang bug. > [ src/util/macros.h ] > > /** > * PUBLIC/USED macros > * > * If we build the library with gcc's -fvisibility=hidden flag, we'll > * use the PUBLIC macro to mark functions that are to be exported. > * > * We also need to define a USED attribute, so the optimizer doesn't > * inline a static function that we later use in an alias. - ajax > */ > #ifndef PUBLIC > # if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590)) > # define PUBLIC __attribute__((visibility("default"))) > # define USED __attribute__((used)) > # elif defined(_MSC_VER) > # define PUBLIC __declspec(dllexport) > # define USED > # else > # define PUBLIC > # define USED > # endif > #endif > > #ifdef HAVE_FUNC_ATTRIBUTE_VISIBILITY > #define HIDDEN __attribute__((visibility("hidden"))) > #else > #define HIDDEN > #endif > > [ src/util/macros.h ] > > Alan pointed to a solution like in [4] ("Use clang's __has_attribute > to check for attribute support") > > So, what can people do to help to nail this down? > > I have attached a refreshed version of Marc's and added the TDS > snippet from [2] to 0002 patch. > ( Patches have no changelog and are against mesa v10.6.8. ) > The major 'issue' is wrt the second patch really. It changes the visibility of the symbols, which imho is due to a misfeature in clang (i.e. gcc adopts behaviour of new standards if it's more laxed, whereas clang have done the following here). I would suggest re-spinning the patches on top of master (ideally retaining authorship/revision history etc.) and sending them inline. Thanks for bringing this topic again. Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev