Fpc, building from source questions lazarus / 64-FPC development ---------------------------------------------------------------------- lagprogramming · 2015-09-01 14:00 Hi!. I have a couple of questions regarding building fpc. 1. I want to double check what I've understood reading Programmer's guide, Compiling the compiler. When you build the compiler from source you can add the exiting compiler path as parameter to the "make" utility by using "PP=pathtoexistingcompiler", but you can't pass as parameter the default configuration file of the existing fpc. The reason why you can't pass the default configuration file to "make" is that the compiler doesn't use this file at all when building itself. This means that the configuration file doesn't have any kind of influence in the building process of the compiler. I'm I right or wrong? 2. When building fpc from source, how do I find fpc's executable used by the "make" utility? You can specify the compiler by using the "PP" parameter. Without this parameter, will "make" search only for "fpc${DEFAULTEXECUTABLEEXTENSION}" or it searches for "ppc*${DEFAULTEXECUTABLEEXTENSION}" files too? 3. If I want to build fpc from source, do I need a full installation of a stable release? Is it possible to build fpc from source only by using the compiler executable for that platform, not a complete fpc install? 4. How can I find out if the user that starts an application has administrator/super_user rights? I'm looking for an existing function in one of rtl's units. If there is none, then I'd like some ideas on how to write one that works at least for windows and linux. 5. When building fpc for crosscompiling sometimes you don't need a toolchain. I'd like to know the situations when these files are not needed.    I'm not sure about the following examples, these are host to target examples: linux-x86_64 to win32-i386 linux-x86_64 to win64-x86_64 linux-x86_64 to linux-i386 linux-i386 to win32-i386 linux-i386 to win64-x86_64 win64-x86_64 to win32-i386    Are the above situations the only ones when CROSSBINDIR and BINUTILSPREFIX are completely ignored? I mean situations when the used doesn't need "${BINUTILSPREFIX}{"as","ar","ld"...}" executables.    I'm not sure about the list presented above, reason why I'd like somebody to check it and explain the situation.    Thank you! ---------------------------------------------------------------------- Jonas Maebe · 2015-09-01 14:10 Quote from: lagprogramming on September 01, 2015, 04:00:43 pm   Hi!. I have a couple of questions regarding building fpc. 1. I want to double check what I've understood reading Programmer's guide, Compiling the compiler. When you build the compiler from source you can add the exiting compiler path as parameter to the "make" utility by using "PP=pathtoexistingcompiler", but you can't pass as parameter the default configuration file of the existing fpc. The reason why you can't pass the default configuration file to "make" is that the compiler doesn't use this file at all when building itself. This means that the configuration file doesn't have any kind of influence in the building process of the compiler. I'm I right or wrong? Correct. Quote2. When building fpc from source, how do I find fpc's executable used by the "make" utility? You can specify the compiler by using the "PP" parameter. Without this parameter, will "make" search only for "fpc${DEFAULTEXECUTABLEEXTENSION}" or it searches for "ppc*${DEFAULTEXECUTABLEEXTENSION}" files too? It will search for the fpc binary, and if it can't find that one, also for ppc386. It does not search for anything else, regardless of your platform. Quote3. If I want to build fpc from source, do I need a full installation of a stable release? Is it possible to build fpc from source only by using the compiler executable for that platform, not a complete fpc install? You need a full installation of the *latest* stable release. It is possible to build with less, but this is not supported and if you run into trouble, you are on your own. Quote4. How can I find out if the user that starts an application has administrator/super_user rights? I'm looking for an existing function in one of rtl's units. If there is none, then I'd like some ideas on how to write one that works at least for windows and linux. There is no such RTL function. On Unix platforms, you probably need FpGeteuid. I have no clue about Windows. ---------------------------------------------------------------------- avra · 2015-09-02 07:03 Quote from: lagprogramming on September 01, 2015, 04:00:43 pm3. If I want to build fpc from source, do I need a full installation of a stable release? Is it possible to build fpc from source only by using the compiler executable for that platform, not a complete fpc install? If you take a look into CodeTyphon installation archive you can find what is minimally needed for a successful FPC source compilation. Subarchive for each supported platform can be found at CodeTyphonIns\installbin\allzips\binfpc. ---------------------------------------------------------------------- marcov · 2015-09-02 08:11 Quote from: lagprogramming on September 01, 2015, 04:00:43 pm 2. When building fpc from source, how do I find fpc's executable used by the "make" utility? You can specify the compiler by using the "PP" parameter. Without this parameter, will "make" search only for "fpc${DEFAULTEXECUTABLEEXTENSION}" or it searches for "ppc*${DEFAULTEXECUTABLEEXTENSION}" files too? fwiw make info |grep "FPC\..."  (grep can of course be implemented using tprocess) Quote3. If I want to build fpc from source, do I need a full installation of a stable release? Is it possible to build fpc from source only by using the compiler executable for that platform, not a complete fpc install? In addition to what Jonas said about this, the tricks can also be a bit target dependent and there is also a profound difference between "usually working" and "always working". e.g. with a fully installed release .inc files are regenerated when needed, while with a partial install a commit that only updates e.g. the ini (but not the .inc) it will suddenly break. Quote4. How can I find out if the user that starts an application has administrator/super_user rights? I'm looking for an existing function in one of rtl's units. If there is none, then I'd like some ideas on how to write one that works at least for windows and linux. Unix will probably be something like (fpgeteuid=0)    and for  Windows winutils.iswindowsadmin I'm not sure if it really is useful to make this platform independent since nearly everything you do with it (and what "admin"  means) is OS dependent again. ---------------------------------------------------------------------- lagprogramming · 2015-09-02 13:24 3. @avra QuoteIf you take a look into CodeTyphon installation archive you can find what is minimally needed for a successful FPC source compilation. Thank you but I'm trying to reinvent the wheel here. If I fail, I'd like to do it in a original style, like no one did it before. 2. @marcov Quotemake info |grep "FPC\..."  (grep can of course be implemented using tprocess)This is awesome. I didn't knew about the "info" parameter, but this opens new questions. Based on the following lines I'd like somebody to explain or check my statements: == Package info == Package Name..... fpc Package Version.. 3.1.1 == Configuration info == FPC.......... /usr/bin/ppcx64 FPC Version.. 2.6.4 Package Name is a name of the source files. Package Version is a version of the source files. FPC is the compiler used to build the source files. FPC Version is the version of the compiler that will build the source files.    If the above is right, how do "FPC" and "FPC Version" lines appear when fpc compiler can't be found, will they look like this? FPC.......... FPC Version.. Notice the empty(like '') values. Or will the lines completely miss from the output?    In windows, I see there is a full path of the compiler executable, like: "FPC.......... C:/lazarus/fpc/2.6.4/bin/i386-win32/ppc386.exe". From where did this value came from, is make.exe searching for the compiler in the same directory where make.exe lies, is fpc related data stored within windows registry? 3. Quotee.g. with a fully installed release .inc files are regenerated when needed, while with a partial release a commit that only updates e.g. the ini (but not the .inc) will suddenly break.   Is the installation process of a stable fpc release doing more than the following two steps? - extract binary and text files to a destination directory; - configure default configuration file.    I mean is the installation process also updating the PATH or windows registries, modifying installed text files based on the installation path, or who knows what else might be done? ---------------------------------------------------------------------- lagprogramming · 2015-09-08 18:42 What about building fpc for crosscompiling!?    Assuming that in the first step I build a development fpc from source using the latest stable fpc release.    In the second step I'd like to build fpc for crosscompiling. Is there a problem if I use the development version of fpc instead of the stable one? The development version is the one built at first step. The source files remain unchanged between the two steps. I ask because after reading about the 3 steps cycle, I think there shouldn't be problem. If there would have been a problem, the problem would have appeared at first step, when building the "native" compiler, right!? If an error would appear at second step it would appear no matter the compiler used.    Is the above rationale valid? ---------------------------------------------------------------------- molly · 2015-09-08 19:04 QuoteIn the second step I'd like to build fpc for crosscompiling. Is there a problem if I use the development version of fpc instead of the stable one?Last time i tried that failed as it insisted on cross- compiling with the stable release (2.6.4) . But that might have been a small oversight at that time. ---------------------------------------------------------------------- Leledumbo · 2015-09-09 09:12 Quote from: lagprogramming on September 08, 2015, 08:42:06 pmIs there a problem if I use the development version of fpc instead of the stable one? Yes, it's not supported and not guaranteed to succeed. If it works, lucky you. If it doesn't, don't complain. Only the latest stable release is supported to build either latest stable release itself or trunk. ---------------------------------------------------------------------- Jonas Maebe · 2015-09-14 07:58 Quote from: lagprogramming on September 08, 2015, 08:42:06 pm   What about building fpc for crosscompiling!?    Assuming that in the first step I build a development fpc from source using the latest stable fpc release.    In the second step I'd like to build fpc for crosscompiling. Is there a problem if I use the development version of fpc instead of the stable one? The development version is the one built at first step. Building a development version of FPC using a compiler built from the same sources is indeed ok, also for cross-compiling. ---------------------------------------------------------------------- lagprogramming · 2015-09-15 19:18 5. When building fpc for crosscompiling sometimes you don't need a toolchain. I'd like to know the situations when these files are not needed.    I'm not sure about the following examples, these are host to target examples: linux-x86_64 to win32-i386 linux-x86_64 to win64-x86_64 linux-x86_64 to linux-i386 linux-i386 to win32-i386 linux-i386 to win64-x86_64 win64-x86_64 to win32-i386    Are the above situations the only ones when CROSSBINDIR and BINUTILSPREFIX are completely ignored? I mean situations when the used doesn't need "${BINUTILSPREFIX}{"as","ar","ld"...}" executables.    I'm not sure about the list presented above, reason why I'd like somebody to check it and explain the situation. ---------------------------------------------------------------------- Jonas Maebe · 2015-09-15 19:20 The only situation where it's not required is when targeting Win32 or Win64. ---------------------------------------------------------------------- lagprogramming · 2015-09-15 19:30 Quote from: Jonas Maebe on September 15, 2015, 09:20:01 pmThe only situation where it's not required is when targeting Win32 or Win64. Do HOSTOS, HOSTCPU and TARGETCPU matter? ---------------------------------------------------------------------- Jonas Maebe · 2015-09-15 19:31 Win32 and Win64 are both only supported for a single target cpu architecture. The host is irrelevant. ---------------------------------------------------------------------- lagprogramming · 2015-09-15 19:33 What about linux-x86_64 to linux-i386 and linux-i386 to linux-x86_64? ---------------------------------------------------------------------- marcov · 2015-09-15 19:49 Besides toolchain availability, there is also the need for the extended type for i386, afaik it makes crosscompiling the compiler from hostcpu=anything to targetcpu=i386 is not possible because the i386 part of the compiler cg uses extended? ---------------------------------------------------------------------- lagprogramming · 2015-09-16 08:13 I reformulate the question because I'd like to be sure I've expressed it right. Probably, the following commands might fail. I'd like to know when they will fail. a. Host OS is linux and host CPU is x86_64 make crossall crossinstall OS_TARGET=linux CPU_TARGET=i386 INSTALL_PREFIX=~/freepascalcompiler/ b. Host OS is linux and host CPU is i386 make crossall crossinstall OS_TARGET=linux CPU_TARGET=x86_64 INSTALL_PREFIX=~/freepascalcompiler/    I assume that a SUBARCH parameter has no influence in these two situations. Reasons for failure might include: binutils is not built using adecvate parameters, missing proper CROSSBINUTILS parameter to the "make" command, and who knows what else...    Will CROSSBINUTILS parameter have an influence upon adding it to the above examples, or it would be completely ignored same as when targetting win32/win64?    If CROSSBINUTILS has an influence, then how comes "make crossall crossinstall OS_TARGET=linux CPU_TARGET=i386 INSTALL_PREFIX=~/freepascalcompiler/" works fine even though I can't find any "i386-*" file on HDD. I would have expected for something like having "i386-linux-{as,ld,...}" files. @marcov Quote from: marcov on September 15, 2015, 09:49:42 pmBesides toolchain availability, there is also the need for the extended type for i386, afaik it makes crosscompiling the compiler from hostcpu=anything to targetcpu=i386 is not possible because the i386 part of the compiler cg uses extended?    Can you reformulate your answer for the above two examples(a and b), I'm not sure I understand it. As far as I know all x86_64 CPUs support extended(as 80b floating value) and CPU_TARGET doesn't need extended support because the compiler will be used on the host CPU.    This paragraph is in the case you meant that you can't build fpc for x86_64 on a 80386 CPU. From your answer I speculate that a 80386 CPU doesn't have extended support. For this reason a linux-i386 host that runs on a 80386 CPU can not build fpc for crosscompiling to linux-x86_64. This aspect would link to a different forum thread(posted recently) regarding extended type use within win64, where I've noticed the presence of "sfpux80" unit. Can't fpc emulate extended on a 80386 CPU? I'm getting lost.    Can you also take a look at: http://forum.lazarus.freepascal.org/index.php/topic,29678.msg18766 0.html#msg187660 ? ---------------------------------------------------------------------- Jonas Maebe · 2015-09-21 09:44 Quote from: lagprogramming on September 16, 2015, 10:13:30 am   Will CROSSBINUTILS parameter have an influence upon adding it to the above examples, or it would be completely ignored same as when targetting win32/win64? The parameters are not ignored for win32 and win64. However, by default those targets use an assembler and linker that are built into the compiler. As a result, the compiler won't use any Binutils. With an external assembler and/or linker, that parameter will have an effect. Quote   If CROSSBINUTILS has an influence, then how comes "make crossall crossinstall OS_TARGET=linux CPU_TARGET=i386 INSTALL_PREFIX=~/freepascalcompiler/" works fine even though I can't find any "i386-*" file on HDD. I would have expected for something like having "i386-linux-{as,ld,...}" files. The compiler also uses an internal assembler by default on Linux for i386 and x86_64.  You do need an i386-linux-ld file to cross-compile from Linux/x86_64 to Linux/i386, otherwise you get the error message "pp.pas(228,1) Error: Util i386-linux-ld not found, switching to external linking". QuoteAs far as I know all x86_64 CPUs support extended(as 80b floating value) Microsoft has deprecated the use of the x87 FPU (wich is necessary for extended 80 bit floating point support) under Win64, so FPC doesn't support it on that platform. ---------------------------------------------------------------------- lagprogramming · 2015-09-21 12:31 QuoteThe compiler also uses an internal assembler by default on Linux for i386 and x86_64.  You do need an i386-linux-ld file to cross- compile from Linux/x86_64 to Linux/i386, otherwise you get the error message "pp.pas(228,1) Error: Util i386-linux-ld not found, switching to external linking".   I don't have that file either. I wonder if compiling binutils with "multitarget" parameter is what makes the difference. This "multitarget" parameter adds support to binutils for cross compiling (does not work with gas). Maybe if binutils is not compiled with this parameter then that's the situation when users need these i386-* files. Hmm... If that would be true then how would I find out if binutils was compiled with this parameter? ---------------------------------------------------------------------- Jonas Maebe · 2015-09-21 12:40 It is unrelated to the way your Binutils are compiled. The compiler looks for a file with a particular file name, it does not test its capabilities. Similarly, the makefile compares the host and target of the compiler binary, and if they are different tells the compiler to add the prefix when calling external utilities. ---------------------------------------------------------------------- lagprogramming · 2015-10-07 06:39 How do I build fpc for a target different than host?    For example, using linux how do I build the fpc binaries for win64? Can I also "install"(group) the binary files in a directory? ---------------------------------------------------------------------- molly · 2015-10-07 07:09 Quote from: lagprogramming on October 07, 2015, 08:39:20 am   How do I build fpc for a target different than host?    For example, using linux how do I build the fpc binaries for win64? Can I also "install"(group) the binary files in a directory? perhaps something like: make crosszipinstall CPU_TARGET=%TARGET_CPU% OS_TARGET=%TARGET_OS% CROSSBINDIR=%BINUTILS_PATH% BINUTILSPREFIX=%TARGET_CPU%-%TARGET_OS%- >> %LOG_FILE% ? Which, for me, creates a zipfile with all necessary files to deploy on the target. Ehm, i meant creates a zip file with the necessary files to cross- compile. I still need the following additional line make compiler OS_TARGET=%TARGET_OS% CPU_TARGET=%TARGET_CPU% FPC="path/and/filename/to/cross-compiler" ---------------------------------------------------------------------- Jonas Maebe · 2015-10-07 07:56 Note that we don't officially support building a full installer for a target different than the host. We only support building cross- compilers. You will e.g. miss several utilities (fpc binary etc) in the crosszip/crossinstall. ---------------------------------------------------------------------- molly · 2015-10-07 08:02 Yeah i noticed my error a little too late, i'm more into cross- compiling myself. oficially not supported. Ok, i understand. But out of interest on the subject, isn't that what the fpcbuild repo is for ? (i truly have no idea). ---------------------------------------------------------------------- Jonas Maebe · 2015-10-07 08:24 The fpcbuild repository is to build complete releases (with documentation etc). But that one, too, only supports building a release that's hosted on the build platform (either native or cross). ---------------------------------------------------------------------- molly · 2015-10-07 08:44 ok, thank you very much for your answer Jonas :thumbsup: