I'd love build my own copy of Perl--if I could get hold of a copy of AS' source tree.

I'd build my packages using MS VC++ 7 so as to be compatible with the AS 64-bit builds, but I don't believe it is available for download any more.

I'd build my packages using MS VC++ 7 so as to be compatible with the AS 64-bit builds

MSVC++ 7 is 32-bit only. It's the "Microsoft Platform SDK for Windows Server 2003 R2" that you want for 64-bit compatibility with ActivePerl, and I recall you had difficulty tracking it down when you went looking for it last time. Afaik it *is* still available - if you think it might be worth the effort try this link.

Cheers,
Rob

Hm. When I look at the mscvrt.dll that gets imported by perl510.dll from my AS 64-bit build, is loaded from c:\windows\system32\msvcrt,.dll it is versioned as Windows NT CRT DLL 7.0.6001.18000.

Now, if VC++v7 was 32-bit only. And I have VC++v9, which is also "wrong", presumably--assuming some kind of logic--the compiler that comes with SDK2003--which is the "correct version"--must be VC++v8.

Now, on my system I have 53 different copies of various msvcr*.dll, amongst them at least 8 different msvcr80.dlls:

Read more... (3 kB)

As there is a v8-specific version of the CRT, the question is why does the AS built binary load the "generic" msvcrt.dll, in preference to the specific version? Presumably, the existance of the specific version means it must get used under some circumstances.

Or, more interestingly, is there some way to request (or default) extensions built using the v9 compiler to import their CRT requirements from the generic msvcrt.dll supplied with the platform (per the AS binary), rather than the tookit specific msvcr90.dll as currently?

The linker has options: /DEFAULTLIB:library /NODEFAULTLIB[:library] along with the compilers /MT & /MD options.

The generated makefile use (amongst others):-nodefaultlib Set LIBC=msvcrt.lib and add the latter to the list of filesnames supplied ot the linker. But all of that does no good (for this problem at least) as the all the .dll references within the msvcrt.lib that comes with the v9 compiler are to msvcr90.dll.

Probably, none of this means anything. Maybe, it was just a policy change on MS behalf between the v8 and v9 compilers that causes the AS binaries to import from msvcrt.dll (despite the existance of msvcr80.dll), and extensions built with v9 to import from msvcr90.dll? But somehow that doesn't ring true. At least not completely.

I'm going to pull the AS sources ikegami linked to and try building it with the v9 compiler and see which CRT ends up getting used. If it links against the generic, the problem might be solvable by modifying the makefile generation to match the AS build configuration. Worth a shot at least.

---

I don't know how you located the v8/2003sdk downloads? Every search I tried refused point blank to locate it. The one page I found that discussed the 2003 SDK, redirected me to the 2008 SDK when I tried the download link :(

The other problem is that AFAIK, it is impossible to run the two concurrently, and I have a couple of things that I think require the 2008 SDK.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"I'd rather go naked than blow up my ass"

http://downloads.activestate.com/ActivePerl/src/5.10/

http://downloads.activestate.com/ActivePerl/src/5.10/

I'm not sure that constitutes what BrowserUk called "a copy of AS' source tree" - depending, of course, on precisely what he means :-)

Certainly, those sources will contain the core patches that ActiveState used for their builds - but I think that the non-core modules that ship as standard with ActiveState builds are missing.

So if you build perl using those sources, you'll then have to install additional modules before you have the same as provided by the ActiveState binaries. (At least that's the way it used to be.)

Cheers,
Rob