You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by wr...@apache.org on 2007/09/07 22:12:50 UTC

svn commit: r573688 - /apr/apr/trunk/build/fixwin32mak.pl

Author: wrowe
Date: Fri Sep  7 13:12:49 2007
New Revision: 573688

URL: http://svn.apache.org/viewvc?rev=573688&view=rev
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.

Modified:
    apr/apr/trunk/build/fixwin32mak.pl

Modified: apr/apr/trunk/build/fixwin32mak.pl
URL: http://svn.apache.org/viewvc/apr/apr/trunk/build/fixwin32mak.pl?rev=573688&r1=573687&r2=573688&view=diff
==============================================================================
--- 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;



Re: svn commit: r573688 - /apr/apr/trunk/build/fixwin32mak.pl

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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;