Hi,
This began with my attempt to build and install cross compilers for Linux i386, Win32, and Win64 and has resulted in the discovery that using the wiki steps for cross compiler building doesn't work under Debian 10. If I use fpcupdeluxe, I can get further, but there are several issues that cause building cross compilers from the command line almost impossible.
Problem 1: The first issue is that setting up the fpc.cfg file doesn't work as documented. I can build the compiler, but the information on setting up the paths for the COMPONENT and RTL libraries doesn't explain much, and as documented they just don't work.
Problem 2 : Prior to debian 10, multi-arch support was different. Starting with Debian 10, development libraries and compilers are installed and additional architectures are added through dpkg or directly in /etc/apt/sources.list. The x86_64 gcc, g++, tools, and linker all support building and linking 32 bit executable programs with the -m2 linker and assembler switches using the 64 bit tools. FPC is setup to use a linker script but the libraries are searched for in the x86_64 folders, and fail when the cario object file is linked.
Problem 3: This problem is consistent across FPC and fpcupdeluxe versions. and seem to stem from the fpc.cfg file.
There is so much information on the FPC wike and so much out f date or wrong information it is a very time consuming task to even figure which, if any, steps are correct in making this happen
I cross develop on Linux all the time for many platforms, and none of the mainstream compilers are so poorly documented. If you pull buildroot, yocto, or many other will thought out and designed tools, building cross platform programs using gcc and g++ is pretty simple to build, and debug with QEMU all on an Intel based PC.
As much as I like FPC and Lazarus, some basic cleanup and modernizing of the installation and cross building of all compilers and components should be considered.
These path problems have been an issue for several years and are not getting better. And these problems don't exist in gcc or g++ since adding new architectures are a mater of adding them with dpkg, running apt update, and apt upgrade once the initial development tools are installed for the host platform.
I have been reading some of the comments about which Linux to support, and the ongoing debates over the quality of FPC and lazarus when compared to Delphi. As an alpha and beta tester for both Turbo Pascal and Delphi versions 1.0, I can say with certainty that developers want to accomplish the development task without spending hours, days, and weeks, trying to figure out outdated and convoluted documentation.
One person wrote this system is getting to complicated to install. This affects professional developers considering this tool due to the instability and time spent just building a cross compiler in attempting to figure out which set of instructions is correct.
FPC needs to be documented as the text mode interface and foundational code generator for lazarus. Lazarus should be optional, and when installed should not affect the Free Pascal paths, but simply add to those paths.
If you look at buildroot or yocto, both allow multiple installations to be maintained in the same home directory and the paths are set when changing into the base folder of each product. Another example is the UEFI toolkit, EDK and EDKII, both which support setting the path to any version by having clear documentation on how to set the paths up.
Nothing in this wiki seems complete, and most of it is hard to determine if it currently applies or not. One reader commented this project can't get a big company to support it because there is no direction or commitment to make a plan.
That is very true, and if this project doesn't set priorities and get some of these simple issues resolved, no small company will risk a project on using this tool and it will die on the vine.
It high time you get the foundational Delphi Components finished and debugged, and provide documentation on how to setup these paths, or better yet, make a smart installer that gets the job done, so professional developers who want to use this tool, can do so knowing the documentation is up to date and setting the cross compiler and component libraries up can be done in minutes and not days.
Some help with this would be nice, but it would be even nicer if the documentation were updated so experienced developers in other tools could get this to work and the same questions were not repeatedly necessary to answer.
It's one thing when noobies have to answer the same questions over and over, and 30-45 year veterans who write drivers operating systems, and custom embedded systems can't figure the documentation out because its not important to the project.