I am sure that question must have been ask a 1000 times, and somewhere must be a tutorial....

but Google only brought me to a page on the wiki, that describes how to do diff OS.

So here it goes:
- I have a 32 bit windows, on a 32 bit Intel CPU
- I have a SVN checkout
- I want to build it, so I get a compiler, that will run on my 32 bit system, but compile for a 64 bit system.

Actually, I don't even care if it creates an executable (I can skip linking). All I need to see, is that it compiles, and does not give any type conversion errors, because the size of certain types depends on the cpu.

All I need is a command-line, how to call "make", on the SVN checkout, so I get the desired result....

Martin

Martin wrote

So here it goes: - I have a 32 bit windows, on a 32 bit Intel CPU - I have a SVN checkout - I want to build it, so I get a compiler, that will run on my 32 bit system, but compile for a 64 bit system.

In the top level directory of your checkout, run

make CPU_TARGET=x86_64 all

Afterwards, compiler/ppcrossx64 will be the cross compiler (from i386 -> x86-64) and compiler/ppcx64 will be the native x86-64 compiler.

Jonas

Isn't it necessary to run "fpcmake -Tx86_64-win64 -w -r", before making?

thanks,
dmitry

In our previous episode, dmitry boyarintsev said:

> > Afterwards, compiler/ppcrossx64 will be the cross compiler (from i386 -> x86-64) and compiler/ppcx64 will be the native x86-64 compiler. Isn't it necessary to run "fpcmake -Tx86_64-win64 -w -r", before making?

No, in general SVN sources have been "fpcmake"'d with "fpcmake -Tall -w"

Unfortunately it doesn't work. I get the following error: make.exe all CPU_TARGET=x86_64 FPC=c:\FPC\SVN\ppc386_2_4_0.exe makefile:199: *** The Makefile doesn't support target x86_64-win32, please run fpcmake first. Stop.

neither of the above fpmake help (nor does "fpcmake -Tall -w - r" )

Note that it is looking for ...-win32 not for ...-win64 Attempting: fpcmake -Tx86_64-win32 -w -r
Processing Makefile.fpc
Error: No targets set

And yes, I did a "make clean" before.

any ideas?

Martin

Martin wrote

Unfortunately it doesn't work. I get the following error: make.exe all CPU_TARGET=x86_64 FPC=c:\FPC\SVN\ppc386_2_4_0.exe makefile:199: *** The Makefile doesn't support target x86_64-win32, please run fpcmake first. Stop.

Add OS_TARGET=win64

Jonas

Well, the command line mentioned is not sufficient, do

make all CPU_TARGET=x86_64 OS_TARGET=win64

ok thanks, that worked.

Only remainder is, the ppccrossx64 is not "installed". I have to copy it by hand to my install dir?

I tried both: "make install" and "make install CPU_TARGET=x86_64 OS_TARGET=win64"
I also guess, I need the later, because it installs the ppu (for rtl/packages) for 64 bit?

Martin

Martin wrote

Only remainder is, the ppccrossx64 is not "installed". I have to copy it by hand to my install dir? I tried both: "make install" and "make install CPU_TARGET=x86_64 OS_TARGET=win64" I also guess, I need the later, because it installs the ppu (for rtl/packages) for 64 bit?

Use "crossinstall" instead of "install"

Jonas

make crossinstall ... should work.

Henry

Hi guys,

I took the liberty to add the summary of this thread to the following wiki page.

http://wiki.lazarus.freepascal.org/Cross_compiling#Win32_To_Win64

Regards,
- Graeme -

Does anyone know the reason why 64-bit Windows was added as win64 instead of (x86_64-)win32? With Linux it was done the ${platform}-linux way as well.

Regards,
Sven

MS calls it Win64 api, see e.g.
http://technet.microsoft.com/en-us/library/bb496995.aspx

In our previous episode, Sven Barth said:

Does anyone know the reason why 64-bit Windows was added as win64 instead of (x86_64-)win32? With Linux it was done the ${platform}-linux way as well.

It's afaik microsofts own designation.

If that's the only reason then that sounds a bit lame in my opinion... but what's done is done.

A pity that I wasn't there when support for Win64 was added :P

Thanks for the answer.

Regards,
Sven

Why? It would only cause confuse to name it different than it is officially called.

Because I consider Win32 and Win64 as one type of operating system. One "OS target". Just as Linux is one operating system for all those available platforms.

Maybe it would have been better to name the target "windows" instead of "win32" and "win64" from the beginning so there would be no confusion regarding this...

But that's just my opinion ^^

Regards,
Sven

In the beginning there was win16 which was really different so it was needed to call the 32 bit api win32. And don't forget, the win64 api has slight differences from the 32 bit api e.g. regarding exception handling.

Florian Klaempfl wrote

And don't forget, the win64 api has slight differences from the 32 bit api e.g. regarding exception handling.

The differences are either slight enough to be left to the developer or be considered CPU dependant (and could thus have been moved into $platform-subdirectories like was done with Linux). And from these CPU dependant differences only exception handling is a bigger problem.

Normal SEH is considered purely CPU dependant, so no problem here.

The vector exception handling approach which came up with 64-bit was also included in the 32-bit systems (but you can only rely on the fact that all 64-bit systems have it).

And if you're talking about the new 64-bit only much more complicated exception scheme which uses new sections in the PE file:
1. Also CPU dependant (only on 64-bit systems)
2. FPC isn't even using SEH to its full potential, so why bother... (also it seems to be only really needed to catch exceptions thrown by MS Visual C++ libraries as the older exception scheme (SEH) is still available)

But as I said in my past mails: the decision was done already a long time ago and thus I live with it (but I don't need to agree with it :P ).

Regards,
Sven

In our previous episode, Sven Barth said:

Windows is more binary centric than Linux.

In Linux every app is "linux" and then compiled to linux/x86 etc

On windows, typically binary files are distributed and win64 bins don't work on win32, so win32win64.

That is a bit unfair now. Comparing binary only applications to source only ones regarding portability.

If I write a proprietary application for Linux and distribute it for x86 only it doesn't necessarly run on a x86_64 Linux (at least not on mine, because I don't have the 32 bit libraries installed). Also if I compile my application for x86_64 only than it won't work on x86 Linux. So Linux32 Linux64.

Also if I write an application for Windows and distribute its source I can compile it for Windows 32 bit and Windows 64 bit without problems (even if I'd not use Pascal but plain MS C).

And even x86 and x86_64 Linux differ in some syscalls, so the Windows API doesn't need to be the exact same on both Platforms (but it is mostly except of some platform specific pieces).

But you know what? Let's stop this discussion, before it turns into a usual flamewar thread. I've said my opinion and that I'd have done that different, but I can't change it (without forking FPC) and I'll still continue to use FPC happily ever after no matter whether we have seperate win32/64/128 targets or a single windows one.

Regards,
Sven

In our previous episode, Sven Barth said:

There is nothing about fairness or not here. It is simply a bit different tradition in what is considered compatible, bianry or source.

If I write a proprietary application for Linux and distribute it for x86 only it doesn't necessarly run on a x86_64 Linux (at least not on mine, because I don't have the 32 bit libraries installed)

True, but apps enter distributions mostly as source. Some projects don't even release binaries themselves.

Also if I compile my application for x86_64 only than it won't work on x86 Linux. So Linux32 Linux64.

On the binary level, true. But the point is that it is the tradition on the free unices (and even a bit Unix in general) to focus on the source. The whole system is defined in C language level terms.