petdance/scratch — Issue #271: Env.pmc fails to link dll in Windows VC build, and probably doesn't work
Author: petdance
Created: 2011-11-01 04:25:31+00:00
State: open

Compiling and linking on windows, using the instructions for the MS VS 2k8 compiler found on the http://trac.parrot.org/parrot/wiki/Platforms/Windows page, I had a problem with the AR_CR= make variable. Setting this to "lib.exe" corrects the problem, but the step of making the shared library (.dll in Windows parlance) fails because of an external reference to `__environ` in Env.pmc.

Inspecting env.pmc leads to the conclusion that there is probably a set of -Defines that will work for MSVS to get the code to link correctly, but also to the conclusion that any Windows dll, and probably any *nix shared lib, that is built in this way is going to fail.

Shared libraries generally have a "separate life" in process-space, so that two applications that both link to the shared library will only cause one instance of the library to appear in memory. In this regard, shared libraries act very much like a program running as a daemon.

But such a program, if it tries to interact with the "system" on behalf of a client, has to take special precautions. For example, if it writes to stdout, which stdout should it write to? The stdout of the shared library, or of the client program?

Similarly, references to environment variables are subject to the same question. And for the specific case of environment variables, the answer is probably always "use the client program's environment."

References to `environ` don't do this. Instead, they reference the environment that was available when the shared library was loaded. The potential bug should be obvious.

For Windows, my research has led me to an API call named 'GetEnvironmentStrings'. I'm not at all clear on the corresponding call for Unix, if there even is such a thing.

Also, it is unclear to me what the protocol for highly-OS-specific code is, w.r.t. PMCs. Parrot is chock full of PMCs that are nothing but wrappers for the various src/foo.c modules, for whatever reason(s).

At any rate, someone smarter than me about Windows, and about Parrot's cross-platform coding approach, will need to take a look at this. (Which is likely to be "anyone with a pulse and a keyboard.")