You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/09/07 22:18:42 UTC
Re: svn commit: r573688 - /apr/apr/trunk/build/fixwin32mak.pl
Windows httpd on Studio 2005 users, you might be interested in this
small hack to fixwin32mak.pl - after applying it I'm able to build
against x86 or x64 cl+link with no trouble at all (other than some
noisy emits that still need to be cleaned up.
Bill
> Log:
> Strip out the /machine from link.exe, in this day and age each CPU
> gets it's own link.exe in it's own path, e.g. you need to set up the
> path for amd64 and you will get that cl compiler, and that linker.
> Although I had already stripped /machine from the .pdb's, the silly
> export put one back. Axe it for good when touching up our .mak files.
> --- apr/apr/trunk/build/fixwin32mak.pl (original)
> +++ apr/apr/trunk/build/fixwin32mak.pl Fri Sep 7 13:12:49 2007
> @@ -86,6 +86,15 @@
> $verchg = -1;
> undef $orig;
> }
> + # With modern LINK.EXE linkers, there is a different LINK for
> + # each platform, and it's determined by the file path. Best
> + # that here, after we compiled the code to the default CPU,
> + # that we also link here to the default CPU. Omitting the
> + # /machine spec from the .dsp was not enough, MSVC put it back.
> + #
> + if ($src =~ s#^(LINK32_FLAGS=.*) /machine:(x|IX|I3)86 #$1 #) {
> + $verchg = -1;
> + }
> print $dstfl $src;
> }
> undef $srcfl;