Hi,

I am having trouble getting fpc to cross-compiler for win64 target.

I'm using fedora 26 which supplies 3.0.2

I used instructions here to create the cross compiler using trunk fpc since the fedora fpc-src does not seem to have the full Makefile structure:

http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux#Free_Pascal

I have a simple test file:

{$MACRO ON}
program Hello;
begin
   Writeln('Hello world, from FPC ', FPC_FULLVERSION, '!');
end.

This builds fine using the stock fpc 3.0.2 with linux target. However, the supposed cross-compiler seems to be trying to build for linux.

$/usr/lib/fpc/3.1.1/ppcrossx64 /back/coredata/hello.pas Free Pascal Compiler version 3.1.1 [2017/10/06] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling /back/coredata/hello.pas
Fatal: Can't find unit system used by Hello
Fatal: Compilation aborted

$/usr/lib/fpc/3.1.1/ppcrossx64 -iTO
linux

So where is my cross compiler ??

Thanks for any help and suggestions.

since the fedora fpc-src does not seem to have the full Makefile structure:

http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux#Free_Pascal

the supposed cross-compiler seems to be trying to build for linux.

A single compiler binary can always compile for all supported targets of that processor. So as long as all the units are available you simply need to pass "-Twin64" as additional parameter to compile for x86_64-win64.

Regards,
Sven

Hi,

This builds fine using the stock fpc 3.0.2 with linux target. However, the supposed cross-compiler seems to be trying to build for linux.

The cross compiler binary itself is only CPU specific, not OS specific. And because for the cross CPU target the same OS exist which is the host platform,it tries to use that, which is Linux in your case.

You need to specify the target platform with -Twin, at least. Depending on if you have the right config in fpc.cfg, you might also need to point the compiler to the right unit directories using some -Fu parameters.

Charlie

Hi,

Sigh. :) Any reason why Windows is different? No other OS has different target arguments for different CPUs, because the CPU type already specifies if its for 32 or 64bit... (fix me?)

Charlie

Thanks Sven,

I have resolved this issue. It was due to having a distro based fpc which installs in /usr/lib64 and svn trunk which installs in /usr/lib .

Once I reunited both under /usr/lib64 I was able to compile native and cross versions. of my test prog.

I'm a little unclear when you say any compiler can always compile for all supported targets. All I have read indicates a specific make sequence to get a cross compiler.

make all OS_TARGET=win32 CPU_TARGET=i386
make crossinstall OS_TARGET=win32 CPU_TARGET=i386

Could you clarify ?

Thanks.

PS. with my current set up, if I specify -Twin64 fpc uses the cross compiler I built from trunk 3.1.1 , if I build native ( without -T ) it uses the distro 3.0.2

What is happening there if all versions handle all platforms. ;?

thx

Am 07.10.2017 11:11 schrieb "Karoly Balogh (Charlie/SGR)" <

I had asked the same some time ago and the historic reason was that especially the system unit was considered too different to have both of them be the same target... I don't agree either, but that's how it is... :/

Regards,
Sven

OK so the earlier statement was not strictly true, and I do need an fpc build which has been build with the cross compiler. This seems to be missing from the distro pkg which is why I got myself several days work trying to set this up from trunk.

This is all made more complicated by having to keep the distro fpc to build trunk.

Now I have two different version , with trunk being able to cross compile a win64 exe of my hello.pas.

This seems fine from command line but when I try to use Lazarus to with project options specifying a Win64 target , it fails to find system.ppu and friends. The project builds and runs native.

HINT: using config file /etc/fpc.cfg
ERROR: compiled FPC unit not found: system.ppu
ERROR: compiled FPC unit not found: objpas.ppu
ERROR: compiled FPC unit not found: sysutils.ppu

Laz does seem to be sending the right args to fpc ( presumably to fpc )

Info: (lazarus) Execute Title="Test: Compiling an empty file" Info: (lazarus) Working Directory="/tmp/"
Info: (lazarus) Executable="/usr/bin/fpc"
Info: (lazarus) Param[0]="-Twin64"
Info: (lazarus) Param[1]="-Px86_64"
Info: (lazarus) Param[2]="-MObjFPC"
Info: (lazarus) Param[3]="-Scghi"
Info: (lazarus) Param[4]="-O1"

I had to move the trunk libs to /usr/lib64 to be in the same place as the distro files and thus agree with fpc.cfg settings.

I am wondering whether this non-std position of the libs is highlighting a a bug in Lazarus assuming /usr/lib . It seems odd that command line fpc works but laz fails to find the libs.

Can you make any sense of this?

thx

Because MS called the apis win32/win64.

I had asked the same some time ago and the historic reason was that especially the system unit was considered too different to have both of them be the same target... I don't agree either, but that's how it is... :/

Well, this is another story, win32/win64 can easily share as much as possible

Hi Florian,

firstly may I take the opportunity to congratulate you on what have managed to do in creating fpc and lazarus. Despite what seems like a few outstanding quirks it is an amazing achievement.

Can you offer any insights into what is going on with Lazarus not locating the system unit and friends. As you acknowledge they are treated somewhat differently due to problems with the underlying platforms.

I am wondering whether this enforced inconsistency with the generally well organised structure could be leading to the problem.

It seems odd that fpc is finding them OK and Lazarus not.

It seems that fedora are doing something a little different in terms of installation dirs, presumably a result of their way of providing multilib 32/64 functionality where they install 64b libs in /usr/lib64 rather than /usr/lib.

I am wondering whether this has highlighted some assumption implicit in the code about different version of libs being in the same place.

Do you have any ideas why the fpc can find the system.ppu etc and not Lazarus?

Thanks for any insights.

firstly may I take the opportunity to congratulate you on what have

managed to do in creating fpc and lazarus. Despite what seems like a few outstanding quirks it is an amazing achievement.

Note: Florian only developed FPC. Lazarus is done by a different though sometimes intersecting team.

Regards,
Sven

OK, thanks for the correction. Apologies to those on the Lazarus team, it's a substantial body of work and quite an achievement.

;)

On Sat, October 7, 2017 22:13, wrote:

Hi,

.
.

Have you looked at FPC FAQ (in particular,
https://www.freepascal.org/faq.var#systemnotfound), or FPC documentation (https://www.freepascal.org/docs-html/user/usersu7.html#x21-280003.1.2)?

FPC Wiki is an additional resource, there is some information related to Lazarus as well - see
http://wiki.freepascal.org/Unit_not_found_-_How_to_find_units.

All of this might help you in finding differences; note that installation packages created for specific Linux distributions may decide to modify the default unit locations.

Hope this helps

Tomas

OK, I have got somewhere is finding out what is going wrong.

The trunk cross-compiler is installed and correctly linked. distro fpc will use it when the appropriate flags are supplied, however, Lazarus is not looking is the right place for the system libs and is NOT building them when they are are required. Which it claims to be able to do.

I was able to get cross compilation from Lazarus by installing and symlinkg trunk ppcx64 but of course this breaks the ability of build anything else from the svn pull because of versions block.

$make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64 INSTALL_PREFIX=/usr
Makefile:2914: *** The only supported starting compiler version is 3.0.0. You are trying to build with 3.1.1.. Stop.

BTW is that msg is correct? I just built with 3.0.2 , it seems that the version block is not specific enough or the message missed a version bump.

There are two conflicting conditions: fpc requires the system fpc to be older in order to build trunk but Lazarus is not smart enough to find ( or build ) the libs if ppc and ppcross are from different versions.

I don't know the mechanics of that but it would seem that there is an implicit assumption somewhere that ppc and ppcross are of the same version and this leads to it not finding the libs ( which are present ) but not even trying to build them when they are "missing".

Were it not for the version restrictions in building fpc one could arguably say this was a reasonable assumption. As it is, it leads to a very confused and confusing state which has taken several days to understand and untangle.

Maybe that could be addressed.

Thanks for the help along the way.

I do make a lot of use of the cross-compiler and the cross-platform libraries capability of FPC and I am wondering if you might be looking at the problem in the wrong way, especially when you seem to be talking about using the cross-compiler for the Lazarus IDE. Here's how I use them and hopefully this will inform your own understanding.

1. When I develop a program using the Lazarus IDE, I am only working with the native (debug) libraries for the development platform. In my case, this is 64-bit Linux. Occasionally, I will run 64-bit Windows in a virtual machine and Lazarus (in native Windows mode) to test for Windows specific issues. During the development and test cycle I do not use cross-compilers or libraries and you would probably only need to do this when compiling for a target on which it is just not practical to run the Lazarus IDE.

2. The cross-compiler and libraries come into their own when I generate production executables and installation packages as they enable the whole process to be performed on the same platform (Linux 64-bit) for my required target platforms: Linux (32-bit and 64-bit) and Windows (32-bit and 64-bit), and automated using a single script - which then goes on to build the Debian packages and Windows installer packages.

3. I always compile FPC from source. For the development platform, a 64-bit compiler is needed and the FPC RTL and FCL libraries include debug symbols. The Lazarus IDE compiles its libraries (LCL and components) using this compiler and the FPC libraries, and works very nicely without the user needing to understand too much about what is going on - or even having to do much in the way of IDE configuration.

4. For the production platform, a 32-bit cross complier is also needed as are optimised RTL and FCL libraries and optimised Lazarus libraries. These libraries have to be built explicitly for each of the production platforms. I have a separate location in the filesystem for the production libraries (separate from development libraries) with sub-directories for x86_64-linux, x86_64-win64, i386-linux, i386-win32. Within the Lazarus parts of the libraries, the Linux libs have the gtk2 interface libraries, while the Windows ones have the win32 interfaces libraries (both win32 and win64).

5. I then use FPC Makefiles to build for each target platform in turn which reference the production and not the development libraries. This includes Lazarus programs and the Lazarus IDE does not have anything to do with this part of the process. Indeed, it would complicate matters no end to try and use the IDE to build for each production target.

If you have taken only a few days to dis-entangle all there is to know about cross compilation and cross platform libraries then I think you are doing very well. It has taken me far longer than that to work out the toolchain that I need and I am still learning the best way to do things. Indeed, there may be no "best way" to do things. The above works for me, but may not work for you. However, the advice that I would give is that as soon as you start to talk about cross-compilers, then you need to start thinking about the differences between development and production environments. Unless you are working with embedded systems, then my advice is don't try to work with cross-compilers for development. On the other hand, when you generate production executables then cross-compilers and cross platform libraries are very useful for automating the process and ensuring consistent quality across all target platforms. However, you do need to think through carefully how the toolchain works and explicitly generate optimised libraries for each target platform including the Lazarus interface appropriate for the target. Use the IDE for development but have a separate scripted environment for generating production executables.

$make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64

INSTALL_PREFIX=/usr

Makefile:2914: *** The only supported starting compiler version is 3.0.0.

You are trying to build with 3.1.1.. Stop.

BTW is that msg is correct? I just built with 3.0.2 , it seems that the

version block is not specific enough or the message missed a version bump.

Yes, the message is correct as you're trying to build trunk with a trunk compiler (the Makefile even says you're trying to use 3.1.1). Only a release compiler (currently 3.0.0 or 3.0.2) is supported.

Regards,
Sven

Yes, that message is always very irritating - but probably right. The FPC compiler I currently use is built from the fixes_3_0 branch and this demands the 3.0.0 compiler to initially compile the compiler. The first time I build from source there is no problem. I install the 3.0.0 compiler from a binary and build the source and install it. The second time, the error message occurs because you now have a more recent version as the installed compiler.

The way I avoid the problem is to have a script I always use to build from source and to force the use of the 3.0.0 compiler for the initial build. This is still on the system and will stay there (unless explicitly deleted) even after the later version is installed. My script saves the initial compiler version in a file "build-version" which is added to my working copy of the source code tree. The script is given below as an example and is intended to be run in the root directory of the source tree. Note the use of the PP make variable for passing the path to the initial build compiler.

  PREFIX=/usr
  FPCPROG=ppcx64

    if [ ! -f build-version ]; then
      fpc -iV >build-version
    fi

  BUILDVERSION=`cat build-version`

  if [ ! -x $PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG ]; then     echo "FPC Build Version ($BUILDVERSION) not found"     exit 1
  fi

  echo "make default target compiler and libraries"

  export FPCDIR=$PREFIX/lib/fpc/$BUILDVERSION

  make all PP=$PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG OPTIMIZE=1   if [ $? -ne 0 ]; then
    exit $?
  fi

  if [ ! -x compiler/$FPCPROG ]; then
    echo "Failed to build compiler"
    exit 1
  fi

Thanks for a very clear and detailed description of you workflow. That is definitely very helpful coming form someone with hands-on experience of going the whole way.

I'm not new to cross-platform work, so I'm not starting from zero, but this is the first time I've attempted a cross-platform project on fpc/laz.

It's not a project I intend to distribute, it's just a bit of fun for a friend that I am using to evaluate the cross-compilation capabilities that Lazarus claims.

It looks like it's 98% of the way there with a couple wrinkles that need smoothing out.

In view of the issues I've found, VM may be the best way to get a final result. But I like the idea of full cross-platform development and if no one tests it and feeds the problems back the gap will never get bridged.

Thanks very much for the info and advice.

Thanks very much .

You were mis-reading what I meant. I know it is supposed to complain when I use 3.1.1 , my point was the messages said I should ONLY use 3.0.0 when in fact I can and have used 3.0.2 without the version trap being triggered.

So what is the REAL condition which needs to be satisfied and which is tested for ?

Is it any 3.0.x , or any 3.0.x where x is even?

Or is the trap incorrectly letting 3.0.2 through.

I suspect the message text is wrong. I was trying to bring that to the attention of someone why may fix it if needed and seek clarification on what is supported.

;)

Tony Whyman wrote

Within the Lazarus parts of the libraries, the Linux libs have the gtk2 interface libraries, while the Windows ones have the win32 interfaces libraries (both win32 and win64).

Thanks, that was the missing element.

I dropped using gtk2 and it works perfectly on win64 now.

Many thanks. That saved me a lot of time experimenting.

;)

In our previous episode, said:
y> > release compiler (currently 3.0.0 or 3.0.2) is supported.

The only supported version is the last release, but due to good stability in recent times the version before is also supported.

However the cehck and error message comes from the makefile in the checkout, so if it is old, it can show an outdated version.

I checked, and fixes currently tells you to use 3.0.2, but trunk has a wrong message (shows older version in msg, but accepts 3.0.0 and 3.0.2).

I'll see if I can fix that asap.