Ticket #1546 (new bug)

Opened 4 years ago

Last modified 4 years ago

Env.pmc fails to link dll in Windows VC build, and probably doesn't work

Reported by: Austin_Hastings Owned by:
Priority: normal Milestone:
Component: none Version: 2.2.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: win32


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.")

Change History

Changed 4 years ago by nwellnhof

  • platform set to win32
Note: See TracTickets for help on using tickets.