This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Problem with putenv() in global constructor
> Here is the test case I infer from the original poster:
> #include <stdlib.h>
> class A { public: A() { putenv ("A=B"); } };
> A a;
> main() {}
> It runs fine for me on Solaris 2.6 with a shared link with ~gcc
> 2.95.3. Crashes in putenv()/find() for stated reason above (unless my
> analysis is buggy and, of course, it might be) with a static link.
Mea Culpa: This original larger test case fails with a shared link
exactly as the poster reported (I blame premature abstraction on my
part before I looked at it ;-). Thus, the specifics of the analysis
of run-time ordering issues don't apply. Sorry to have gotten off in
the weeds a bit. But it did display the general portability issue to
be concerned with here.
I will still stick with this probably being an initialization order
problem that gcc can't fully control since it didn't provide libc or
the startup code. Beyond that, someone that really cares about
Solaris would have to debug the exact problem. I am more interested
in explaining why a user should steer clear of this C++ coding style.
Sorry to have not noticed this detail until just after sending the
longer message.
Regards,
Loren