On Sunday 22 May 2005 00:43, Julien Cayzac wrote: > On 5/21/05, Jason Stubbs <[EMAIL PROTECTED]> wrote: > > You miss the point. Adding that flag to CFLAGS (or CXXFLAGS) is faulty in > > and of itself. It is not a general optimization flag. It is something > > that each package's codebase needs to be updated to support. When > > upstream updates their packages, they will also update whatever build > > system to specify that flag accordingly. > > From the GCC manpage: > A good explanation of the benefits offered by ensuring ELF symbols > have the correct visibility is given by ``How To Write Shared > Libraries'' by Ulrich Drepper (which can be found at > <http://people.redhat.com/~drepper/>) - however a superior solution > made possible by this option to marking things hidden when the default > is public is to make the default hidden and mark things public. This > is the norm with DLL's on Windows and with -fvisibility=hidden and > "__attribute__ ((visibility("default")))" instead of > "__declspec(dllexport)" you get almost identical semantics with > identical syntax. This is a great boon to those working with > cross-platform projects. > > As I understand this, any shared object that relies on the fact that > its symbols will get "magically" exported while not explicitly > exporting them is broken. That said, Portage provides a way to mask > broken c(xx)flags for those ebuilds.
Yes, but there was not only no requirement up until recently, there was no way to specify visibility. This means that almost everything is "broken" at the moment. Or alternatively, you can consider telling the compiler that a piece of code does specify it's visibility when it actually doesn't to be a broken action. It's with the latter viewpoint that any bugs filed asking for -fvisibility=hidden to be filtered will be marked INVALID. Regards, Jason Stubbs
pgpjJw3dMRM5R.pgp
Description: PGP signature
