On 11/09/15 00:35, Erik Faye-Lund wrote:
On Mon, Sep 7, 2015 at 3:54 PM, Jose Fonseca <jfons...@vmware.com> wrote:
On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
On 04.09.2015 01:37, Matt Turner wrote:
You need to test for this support in configure.ac. It's as simple as
adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
list and then a little bit of preprocessor in src/util/macros.h.
Should the code fallbacks on atexit(3) if the attribute is not
supported?
At least on Windows, with MSVC, atexit should be the right thing to do,
since we statically link MSVC RunTime,
Can I use the HAVE_FUNC_ATTRIBUTE_DESTRUCTOR macro in
ralloc.c for this purpose?
For the record, another alternative (way more portable), is you have a
simple .cpp file with a static destructior:
class AtExit
{
public:
~AtExit() {
// do what must be done
}
};
AtExit atExit();
After all, it seems wrong to use non-standard C to replicate what standard
C++ can do.
That sounds nice and all, until you stumble over problems like
STB_GNU_UNIQUE, which makes renders C++ static destructors completely
unusable on Linux if you have even a single static variable in a
method in your C++ code.
Read up on it on Read
http://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html if you feel like
being depressed.
I read up to https://gcc.gnu.org/ml/gcc-help/2011-05/msg00450.html but
it sounded like a problem in dlclose.
> Unfortunately, C++ and it's many questionable implementations make up
> an unpredictable beast that keeps on throwing curve-balls that makes
> it no fun at all for library development.
The irony is that, __attribute__((destructor)) is one of those sources
of unpredictability (the order destructors gets called is almost
unpredictable), which is probably why it was never added to standard C.
I can't look at using C with non-standard extensions on a good light,
and using extended C (ie, C++) under a bad light. Using and abusing
non-standard extensions will surely throw curve-balls too. At least
those curve-balls threw by C++ are shared by a lot of other people, more
likely to get sorted out without our intervention.
Finally, dlclose'ing shared objects is inherently like walking on a mine
field, no matter what language one uses. IMHO, if we can't support
dlclose safely/robustly, might as well slap -Wl,-z,nodelete on our
shared objects, ie. just pretend everything was statically linked.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
