Another question about cross-compiling

[carl_caulkett]

* Mac Mini M1
* macOS 14.6.1
* Lazarus 3.99
* FPC 3.3.1

I have set up two profiles in the Project Options, enabling me to switch easily between compiling for macOS and for Windows.

However, I also need to change the "Environment" -> "Files" -> "Compiler Executable" parameter between "/Applications/Lazarus_trunk/fpc/bin/x86_64-darwin/fpc.sh" for macOS and "/usr/local/bin/ppcrossx64" for Windows.

It would be far easier, and less of an opportunity for errors to occur, if the "Compiler Executable" parameter could also be selected in the Project Options by profile. Is this possible?

[Warfley]

Thats what the compiler stub is for. The actual compiler are the ppcXXX compilers, the fpc binary is just stub which will dispatch the calls to the correct ppc compiler. So when you in your project options select the correct target architecture the compiler stub should select the correct cross compiler.

You should not need to change the compiler path to the ppcXXX compilers from the fpc (or the fpc.sh in case of fpcup). A few years ago I've built a docker pipeline with Win32 and Win64 cross compilers using fpcup and lazbuild using build configurations, and it worked quite well. I've wrote it down here

If your compiler stub has trouble finding the correct compiler executables, it's probably because they are neither in the search path nor in the same directory. The easiest solution on *nix is usually to just create a symlink into the fpc directory

[TRon]

As mentioned by warfley, this is not Lazarus related but rather a matter of setting up and configuring the FPC commandline compiler.

the fpc command itself is a front-end for the actual (back-end) compiler (ppcxxx). Providing FPC with options allows to select which specific back-end to use, e.g. fpc -Pi386 -Twin32 (where -T selects the target OS and -P the target processor).

If fpc.cfg file is configured correctly then there should not be a problem compiling anything for any target when using the FPC command-line compiler (front-end).

Now having said that, Lazarus works a bit differently in that it only relies on its own settings (though your global settings might be taken into account and/or interfere) and it only expects the FPC command-line compiler to be setup correctly.

Because I personally disagree with how things are setup by default (on *nix platforms) I use my own custom setup:

Code: [Select]

.../[fpc]
- [2.6.4]
- [3.0.4]
- [3.2.0]
- [3.2.2]
  - bin
    - [x64_64-linux]
      - fpc
      - ppc386
      - ppc68k
      - ppca64
      - ppcppc
      - ppcross386
      - ppcrossarm
      - etc, etc.
  - [source]
    - [packages]
      - etc, etc.
    - [rtl]
      - etc, etc.
  - [units]
    - [aarch64-linux]
    - [arm-linux]
    - [i386-linux]
    - [i386-win32]
    - [m68k-amiga]
    - [powerpc-morphos]
    - [x86_64-linux]   
      - [a52]
      - [aspell]
      - etc, etc.
    - [x86_64-win64]
    - etc, etc.
  - etc, etc.
- [3.3.1]
- fpc.cfg
- etc, etc.

and besides that use an overall global link to my own custom fpc.sh shell script that invokes the correct fpc executable. I then feed that script to Lazarus.

And on that (side) note: Though lazarus devs seems to keep inventing measures to prevent that from happening, and whomever he/she/they is/are and in case happen to be reading this: leave it the hell alone because I will beat any measures that you smartypants will be able to come up with and doing so without touching any of the source-code (it is literally a battle you can't win and the measures taken benefits no one but your own piece of mind 

[carl_caulkett]

Thanks Warfley and TRon,

I changes my Lazarus Settings to `/usr/local/bin/fpc` for the Compiler Executable, and it does, indeed as you say, dispatch the command to the correct backend. I thought I had already tried that, but obviously not 😉

[JuhaManninen]

I don't do cross-compilation myself but there was a request to integrate features from fpcupdeluxe to Lazarus for downloading and configuring the libs etc. and the FPC binaries needed for cross-compilation.
It sounds like a good idea. It would be accepted for sure if somebody wants to implement it.
See: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40989

I did not fully understand TRon's rant.
Measures are invented to prevent what from happening? AFAIK the cross-compilation support in Lazarus has not changed for a long time.

[dbannon]

For the record, I routinely cross-compile Linux(64bit and 32bit), Windows (32bit and 64bit) and Arm (32bit) from the one Linux VM. It just works, does not, IMHO, need any changes.
I recently updated my release VM to use Lazarus 3.6, just install Lazarus and use the new one on the command line. So, I have not seen any changes that get in the way of cross-compiling.

Cross-compiling is a FPC thing, not Lazarus anyway. So I am unsure of whats TRon is excited about.

Davo

[TRon]

I did not fully understand TRon's rant.
Measures are invented to prevent what from happening? AFAIK the cross-compilation support in Lazarus has not changed for a long time.

Lazarus which at first setup of the compiler complains that "This is not an (fpc) executable, make sure you select the correct file".

I understand that that is meant to prevent people from using their own (custom) compiler and/or to prevent newbies to make mistakes but it is highly annoying.

Because such messages about what should reside where exactly on my system keeps on popping up more and more (e.g. being persistent) I can only imagine that the person(s) implementing this has/have an agenda to completely deny any setups that are out of the ordinary and/or are in disarray with their view(s).

Cross-compiling is a FPC thing, not Lazarus anyway. So I am unsure of whats TRon is excited about.

It is not about the cross-compilation, it is about Lazarus complaining about my setup. Indeed Lazarus has no business meddling with either FPC or any other things on my system, yet it does complain and nag.

edit: another one for the smartypants. Whenever you change the compiler executable setting in lazarus, even though it is the exact same compiler, same config, same units, same everything, compiling a project triggers a complete rebuild of the widgetset. There is probably a very logical reason for that but, unfortunately I fail to grasp it.

[Thaddy]

It is not about the cross-compilation, it is about Lazarus complaining about my setup. Indeed Lazarus has no business meddling with either FPC or any other things on my system, yet it does complain and nag.

Yes, Lazarus seems to always claim everything for itself and is not very flexible about allowing code to be editted somewhere else. You have my permission to rant.
That said, if the Lazarus IDE is your only editor it is actually excellent.

[dbannon]

Lazarus which at first setup of the compiler complains that "This is not an (fpc) executable, make sure you select the correct file".

I have never seen such a message. I keep my FPC installs in $HOME/bin/FPC, thats not, I expect, a normal place.  Depending on the machine I am using, I'll either be setting an explicit path to fpc in Lazarus (either initially) or under the Tools menu. Or, I just fiddle the PATH in my Lazarus startup script.

Do you see this message only when the initial setup dialog appears or when you change the compiler under Tools->... ?

I understand that that is meant to prevent people from using their own (custom) compiler

I doubt that. Does sound a bit like the way Apple thinks ....

I just tried a few, more unconventional FPC settings under Tools->..., nothing triggers such warnings. Honestly, I'd hate it if it did !

Davo

[Thaddy]

I understand that that is meant to prevent people from using their own (custom) compiler

I doubt that. Does sound a bit like the way Apple thinks ....

I just tried a few, more unconventional FPC settings under Tools->..., nothing triggers such warnings. Honestly, I'd hate it if it did !

Davo

Your doubt is correct. That is not the case. I often have compilers that differ, sometimes quite a lot, from the source repositories for testing patches.
And that is actually quite comfortable - for an old hand, not for beginners - because of fpc's build system.

[TRon]

I have never seen such a message. I keep my FPC installs in $HOME/bin/FPC, thats not, I expect, a normal place.  Depending on the machine I am using, I'll either be setting an explicit path to fpc in Lazarus (either initially) or under the Tools menu. Or, I just fiddle the PATH in my Lazarus startup script.

I prefer to not meddle with my path. And as far as I remember at least the compiler is perfectly happy without having itself in the path envar.

Do you see this message only when the initial setup dialog appears or when you change the compiler under Tools->... ?

At first setup dialog but depending on what other things Lazarus deems 'wrong' that dialog used to re-appear (I am not sure it still does that since 3.4)

See also my edit in my previous reply on what happens when you "change" the compiler. (as in using the exact same compiler but invoked differently)

I doubt that. Does sound a bit like the way Apple thinks ....

hmz, see picture.

[dbannon]

Ah, I think that says it all ! Lazarus likes the compiler to sound a bit like "fpc". We know its happy with fpc.bash, fpc.sh, ppcxxx etc.  Maybe you should use fpc-broken" ?

Davo

[TRon]

@dbannon:
It started with only the startup dialog, now it is also in the options dialog (and its seems to be getting more persistent with every new release).

The question is more where does it end. On windows such thing is not even possible (it insists on it being a .exe no matter how you name it and yes I do have a working workaround for that but it is preposterous that someone should even have to).

For me personally it is one step removed from staying the hell away from the IDE altogether.

Lazarus might perhaps believe it has any say in this but it actually hasn't. I did not move away from windows to get into the same kind of shitehole.

First world problems, I know

[Bogen85]

Would not a few line program compiled by FPC to redirect to your real compiler wrapper with the passed in arguments satisfy Lazarus in this case?
The path to the real one could even come from an environment variable or config file.

[TRon]

Would not a few line program compiled by FPC to redirect to your real compiler wrapper with the passed in arguments satisfy Lazarus in this case?
The path to the real one could even come from an environment variable or config file.

indeed it does but i quote myself:

.. and yes I do have a working workaround for that but it is preposterous that someone should even have to).