Command line cross-compile X86, X64 and IA64 Visual Studio 2005

[Eric]

Hi,

I want to builds several librairies (lib and dll) by using the command
line (cl.exe, link.exe, ...) with VS2005.

I know the option /MACHINE:{X86, X64, IA64} for the linking but is
there a similar option for the compiler?

All librairies that I build are the same size witch is impossible.

Here are the command line that I use :

cl.exe @" /c /Wp64 /O2 /D _WIN64 /D _CRT_SECURE_NO_DEPRECATE /D
_CRT_NONSTDC_NO_DEPRECATE /D _CRT_NON_CONFORMING_SWPRINTFS /D NDEBUG /D

_WINDOWS /D _MBCS /Z7 /Zc:wchar_t "

and

link.exe " /MACHINE:IA64 /implib:" kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll
/incremental:no
libpath:"PATH" "

So, I think the link go to the right target but the problem is cl.exe.
How to specify to target machine ?

/bin/amd64/cl.exe can execute
/bin/ia64/cl.exe can't execute

Regards
Eric

[Bruno van Dooren [MVP VC++]]

> I want to builds several librairies (lib and dll) by using the command
> line (cl.exe, link.exe, ...) with VS2005.
> I know the option /MACHINE:{X86, X64, IA64} for the linking but is
> there a similar option for the compiler?

which version of VS are you using?
x64 is only possible with professional and higher.
ia64 is only possible with TeamStudio

What I would do if I were you is to create a solution for your projects, and
make an x32, x64 and ia64 configuration.
then build them using msbuild. this will be much simpler than explicitly
invoking cl and link on the command line.

--

Kind regards,
Bruno van Dooren
bruno_nos_pa...@hotmail.com
Remove only "_nos_pam"

[Eric]

> > I want to builds several librairies (lib and dll) by using the command
> > line (cl.exe, link.exe, ...) with VS2005.
> > I know the option /MACHINE:{X86, X64, IA64} for the linking but is
> > there a similar option for the compiler?
>
> which version of VS are you using?
> x64 is only possible with professional and higher.
> ia64 is only possible with TeamStudio

I have VS2005 Team Suite and PlatformSDK 3.0

>
> What I would do if I were you is to create a solution for your projects, and
> make an x32, x64 and ia64 configuration.
> then build them using msbuild. this will be much simpler than explicitly
> invoking cl and link on the command line.
>

The problem is that I have the code source but not the solution. I
need to generate librairies from an application that use a script for
build the .lib and .dll. I have to explicite the options for cl.exe
and link.exe in the script.

Regards,
Eric

[Jochen Kalmbach [MVP]]

Hi Eric!!

> The problem is that I have the code source but not the solution. I
> need to generate librairies from an application that use a script for
> build the .lib and .dll. I have to explicite the options for cl.exe
> and link.exe in the script.

The problem is: for every target, you need a different compiler!

But you can just swicth the target compiler by changing the environment
variables. See
%ProgramFiles%\Microsoft Visual Studio 8\VC\vcvarsall.bat

You can change the target by executing:

x86:
vcvarsall x86

x64 (build on an x86 OS):
vcvarsall x86_amd64

IA64 (build on an x86 OS):
vcvarsall.bat x86_ia64

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Eric]

>
> The problem is: for every target, you need a different compiler!
>
> But you can just swicth the target compiler by changing the environment
> variables. See
> %ProgramFiles%\Microsoft Visual Studio 8\VC\vcvarsall.bat
>
> You can change the target by executing:
>
> x86:
> vcvarsall x86
>
> x64 (build on an x86 OS):
> vcvarsall x86_amd64
>
> IA64 (build on an x86 OS):
> vcvarsall.bat x86_ia64
>

Yeah, I just found this tool but it doesn't work. The problem, I have
Windows XP x64. Thus, I can just execute
%ProgramFiles%\Microsoft Visual Studio 8\VC\bin\amd64\cl.exe

I can't execute

%ProgramFiles%\Microsoft Visual Studio 8\VC\bin\cl.exe (for X86)
%ProgramFiles%\Microsoft Visual Studio 8\VC\bin\x86_amd64\cl.exe
%ProgramFiles%\Microsoft Visual Studio 8\VC\bin\x86_ia64\cl.exe

because : mspdb80.dll can't be found

I try to copy this dll from %ProgramFiles%\Microsoft Visual Studio
8\VC\bin\amd64\ without success.

Thank you,
Eric

[Ben Voigt]

"Eric" <clemen...@gmail.com> wrote in message
news:1161289536....@i3g2000cwc.googlegroups.com...

> >
>> The problem is: for every target, you need a different compiler!
>>
>> But you can just swicth the target compiler by changing the environment
>> variables. See
>> %ProgramFiles%\Microsoft Visual Studio 8\VC\vcvarsall.bat
>>
>> You can change the target by executing:
>>
>> x86:
>> vcvarsall x86

Guessing here:
vcvarsall amd64_x86

>>
>> x64 (build on an x86 OS):
>> vcvarsall x86_amd64

vcvarsall amd64

>>
>> IA64 (build on an x86 OS):
>> vcvarsall.bat x86_ia64

vcvarsall amd64_ia64

[Jochen Kalmbach [MVP]]

Hi Eric!

>>The problem is: for every target, you need a different compiler!
>>
>>But you can just swicth the target compiler by changing the environment
>>variables. See
>>%ProgramFiles%\Microsoft Visual Studio 8\VC\vcvarsall.bat
>>
>>You can change the target by executing:
>>
>>x86:
>>vcvarsall x86
>>
>>x64 (build on an x86 OS):
>>vcvarsall x86_amd64
>>
>>IA64 (build on an x86 OS):
>>vcvarsall.bat x86_ia64
>>
>
>
> Yeah, I just found this tool but it doesn't work. The problem, I have
> Windows XP x64. Thus, I can just execute
> %ProgramFiles%\Microsoft Visual Studio 8\VC\bin\amd64\cl.exe

First: if you have an x64 OS, VS is NOT installed in %ProgramFiles%
instead it is installed in %ProgramFiles(x86)% !

> I can't execute
>
> %ProgramFiles%\Microsoft Visual Studio 8\VC\bin\cl.exe (for X86)
> %ProgramFiles%\Microsoft Visual Studio 8\VC\bin\x86_amd64\cl.exe
> %ProgramFiles%\Microsoft Visual Studio 8\VC\bin\x86_ia64\cl.exe
>
> because : mspdb80.dll can't be found

Please take a look into vcvarsall.cmd!!!
And you must use a 32-bit command prompt!
%SystemRoot%\syswow64\cmd.exe

(or was it:
%SystemRoot%\wow6432\cmd.exe !?)

[Jochen Kalmbach [MVP]]

Hi Ben!

>>>x86:
>>>vcvarsall x86
>
> Guessing here:
> vcvarsall amd64_x86

No... there is no cross compiler for x64-x86, because x64 IS x86 ;)

And therefor there is also no need for an x64-ia64 cross-compiler
because you can use the x86-ia64 cross-compiler.

Of course, you have a problem if you only have an IA64 system: because
there is no cross compiler for x86/x64 for IA64 OSs...

[Eric]

Thank you a lot. Now I understand :-) I don't have to chose manually
the good binary cl.exe. The script vcvarsall.bat set the environment
for the cross-compiling.

It doesn't matter which cmd.exe I use (32 or 64 bits), all work.

But I still have an existential question. Why cl.exe doesn't have a
simple option like /MACHINE:IA64 for the cross-compile?

Thanks again !
Eric

[Jochen Kalmbach [MVP]]

Hi Eric!

> But I still have an existential question. Why cl.exe doesn't have a
> simple option like /MACHINE:IA64 for the cross-compile?

Maybe this is "by-design"?

Greetings
Jochen

[Tim Roberts]

"Eric" <clemen...@gmail.com> wrote:
>
>But I still have an existential question. Why cl.exe doesn't have a
>simple option like /MACHINE:IA64 for the cross-compile?

There's a very good reason for that. Each processor architecture takes an
entirely different compiler. There are different instruction sets,
different register sets, very different optimization schemes, very
different instruction re-ordering guidelines, etc. Although they have
similar philosophies, an x86 compiler and an x64 compiler are rather
different beasts, embodied in different compiler binaries.

The linker is not like that. The linker does not care one whit what the
bits in an object file actually mean. It is merely following directives in
the linker tables, and they are all processor-independent. The linker
tables tell it exactly which bytes need to be relocated, or linked to
external symbols, or exposed in export tables, etc. The linker does not
know that the bytes are inside a "call" instruction, or that the "call"
instruction has different encodings on different processors.

Indeed, although it may not be literally true, the /MACHINE directive for
the linker might do nothing more than set the machine type field in the
resulting PE header.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[jmic...@yahoo.com]

Hi eric, what you are looking at in those dirs is
host_target (with x86_x86 implied if none specified or left blank)
for both the

unfortunately, VS compiler uses blank for x86_x86.
you can deduce the host and target based on list of right hand side targets and left-hand-side hosts.
do a dir/s/b/ad of the bin directory.
left-hand-side:
- blank or x86: x86 (the original compiler for VC was 32-bit)
- amd64
right-hand-side:
- blank or x86: x86
- amd64
- arm

given that no compiler is usually by default available for the arm platform (like a phone or tablet), you can assume that the side that has ARM is the target, and that the other side of the _ is the host. I hope to see atom, itanuium, and arm64 in VS2013Pro at some point (it's why I bought it).

set tools_32h32t=%base32%\VC\bin
set tools_32h64t=%base32%\VC\bin\x86_amd64
set tools_32harmt=%base32%\VC\bin\amd64_arm
set tools_32harm64t=
set tools_32hitaniumt=
set tools_32hatomt=
set tools_64h32t=%base64%\VC\bin\amd64_x86
set tools_64h64t=%base64%\VC\bin\amd64
set tools_64harmt=%base64%\VC\bin\amd64_arm
set tools_64harm64t=
set tools_64hitaniumt=
set tools_64hatomt=
set vcefaults=/Qpar /MP
rem if only!
set vcopt_32t=/link /arch:x86
set vcopt_64t=/link /LARGEADDRESSAWARE /arch:AVX
set vcopt_arm=/link /arch:ARM
if /i @%PROCESSOR_ARCHITECTURE%@ equ @AMD64@ (
set host=64h
) else (
set host=32h
)
setlocal enabledelayedexpansion
for %%x in (32 64 arm) do (
if exist "!tools_%host%_%%xt!\cl.exe" "!tools_%host%_%%xt!\cl.exe" /Fe%%x\somefile.exe %vcdefaults% !vcopt_%%xt! somefile.cpp
)
endlocal

since I want to generate a set of executables, one for each type of target, it's not as simple as adding the compiler to my path, since they all have the same filename, one of them is going to win out over the other, and continually adding to the path ends you up with a path that exceeds 8190 chars, the limit of the commandline.



as a workaround for the blank thing and the inconsistency of platform naming conventions across tools, I ended up having to set more variables than I wanted to.