3 ms·

You mean it only produces 32 bit code? This disagrees (http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).aspx http://msdn.microsoft.com/en-US/library/x4

You mean it only produces 32 bit code? This disagrees (http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).aspx http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as...) going back to at least 2005. The following list describes the various versions of cl.exe (the Visual C++ compiler): ... x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit Widows operating system.

jlgreco 13y ago
What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows. This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output. OS Linker Output Mem 1 32 32 32 3GB 2 32 32 64 3GB 3 64 32 32 4GB 4 64 64 32 8TB They use to be doing 1, now they are doing 3. They need to do 4, but apparently cannot. My understanding of this may be wrong, or they may be wrong, I don't know.
- yuhong 13y ago
  You need to add cl.exe to the table.
  - jlgreco 13y ago
    I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use? I am baaarely familiar with Microsoft-world development.
    - yuhong 13y ago
      Yes, they can use a 32-bit cl.exe and 64-bit linker, but most build systems don't make it easy.
      - bzbarsky 13y ago
        You can't use a 32-bit cl.exe and a 64-bit linker to produce 32-bit binaries if you're doing PGO (which is the whole point of this "using lots of memory" issue). In particular, the 64-bit linker can't produce 32-bit binaries when you're using link-time code generation, which PGO does.
yuhong 13y ago
I am talking about the cl.exe executable that output x86-32 code itself, not the code it produces. You can use a 32-bit cl.exe to cross compile 64-bit code, but not the other way round.
- ryanmolden 13y ago
  Ahh gotcha, I hadn't look at that angle. That is unfortunate.

jlgreco 13y ago

What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows. This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output. OS Linker Output Mem 1 32 32 32 3GB 2 32 32 64 3GB 3 64 32 32 4GB 4 64 64 32 8TB They use to be doing 1, now they are doing 3. They need to do 4, but apparently cannot. My understanding of this may be wrong, or they may be wrong, I don't know.

yuhong 13y ago
You need to add cl.exe to the table.
- jlgreco 13y ago
  I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use? I am baaarely familiar with Microsoft-world development.
  - yuhong 13y ago
    Yes, they can use a 32-bit cl.exe and 64-bit linker, but most build systems don't make it easy.
    - bzbarsky 13y ago
      You can't use a 32-bit cl.exe and a 64-bit linker to produce 32-bit binaries if you're doing PGO (which is the whole point of this "using lots of memory" issue). In particular, the 64-bit linker can't produce 32-bit binaries when you're using link-time code generation, which PGO does.

yuhong 13y ago

I am talking about the cl.exe executable that output x86-32 code itself, not the code it produces. You can use a 32-bit cl.exe to cross compile 64-bit code, but not the other way round.

ryanmolden 13y ago
Ahh gotcha, I hadn't look at that angle. That is unfortunate.