Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Thu, 2018-07-05 at 00:20 +0200, Tomas Hajny wrote: > If you look into fpmake.pp in the same directory, you'll find out that the > proper command line for calling data2inc should be: > > data2inc -b -s fpcmake.ini fpcmake.inc fpcmakeini > > (add paths as necessary, e.g. the path to data2inc if not on PATH) Thank you Tomas, I didn't specify the correct options to data2inc. I managed to regenerate a makefile which reflected the changes in fpcmake.ini! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Thu, July 5, 2018 00:20, Tomas Hajny wrote: > On Wed, July 4, 2018 22:42, Christo wrote: >> On Wed, 2018-07-04 at 11:57 +0200, Tomas Hajny wrote: Oops, sorry, sent the previous e-mail too early by mistake. :-( . . > Invoking of data2inc from fpmake may not be as mature though (as suggested > by your experience with running make in the fpcm directory). I don't have > time for debugging ...the fpmake issue at the moment, but it's a FPC program and it should be possible to debug it the usual way to find out why it doesn't generate the .inc file as expected. Hope this helps Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Wed, July 4, 2018 22:42, Christo wrote: > On Wed, 2018-07-04 at 11:57 +0200, Tomas Hajny wrote: >> The .ini file should be translated to .inc using the data2inc utility >> (included with FPC as well) and then incorporated into the binary. This >> should happen automatically, but let's make sure it was the case for you >> as well. > > The .inc file is not regenerated when running make in the fpcm directory. > At first the data2inc utility couldn't be found, fixed that by specifying > DATA2INC=path/to/data2inc. This still didn't regenerate the .inc file. Did you try removing the fpcmake.inc before running make? > Tried > to generate only the .inc file by calling data2inc manually passing > unmodified > fpcmake.ini as input - this resulted in a parsing error: > > ~/fpc/3.1.1/utils/fpcm $ ../bin/x86_64-linux/data2inc fpcmake.ini > fpcmake.inc > processing file : fpcmake.ini > Some error with a \xxx constant or a stale (unescaped) backslash > Error in line : 35 Somewhere near :'OVERR' If you look into fpmake.pp in the same directory, you'll find out that the proper command line for calling data2inc should be: data2inc -b -s fpcmake.ini fpcmake.inc fpcmakeini (add paths as necessary, e.g. the path to data2inc if not on PATH) > Data2inc also gives an error when reading data2inc.exm, which seems > strange. I guess that this is again due to wrong parameters, but that's really just a guess. Anyway, running 'data2inc data2inc.exm demo.inc' as suggested within data2inc.exm works for me (using data2inc from the 3.0.4 installation, but that shouldn't make a difference). > Same error when testing data2inc of 3.0.4 (compiled from source). I've > already > deleted, restored and rebuild the utils directory of trunk but get the > same error. > > This is really strange because data2inc seems like a very mature tool. Indeed - I'm pretty sure that it should work when using the right parameters. Invoking of data2inc from fpmake may not be as mature though (as suggested by your experience with running make in the fpcm directory). I don't have time for debugging ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Wed, 2018-07-04 at 11:57 +0200, Tomas Hajny wrote: > The .ini file should be translated to .inc using the data2inc utility > (included with FPC as well) and then incorporated into the binary. This > should happen automatically, but let's make sure it was the case for you > as well. The .inc file is not regenerated when running make in the fpcm directory. At first the data2inc utility couldn't be found, fixed that by specifying DATA2INC=path/to/data2inc. This still didn't regenerate the .inc file. Tried to generate only the .inc file by calling data2inc manually passing unmodified fpcmake.ini as input - this resulted in a parsing error: ~/fpc/3.1.1/utils/fpcm $ ../bin/x86_64-linux/data2inc fpcmake.ini fpcmake.inc processing file : fpcmake.ini Some error with a \xxx constant or a stale (unescaped) backslash Error in line : 35 Somewhere near :'OVERR' Data2inc also gives an error when reading data2inc.exm, which seems strange. Same error when testing data2inc of 3.0.4 (compiled from source). I've already deleted, restored and rebuild the utils directory of trunk but get the same error. This is really strange because data2inc seems like a very mature tool. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Wed, July 4, 2018 10:50, Christo Crause wrote: > On Wed, Jul 4, 2018 at 9:21 AM, Tomas Hajny wrote: >> On Wed, July 4, 2018 07:53, Christo wrote: >> > Any hints on how to compile and use fpcmake so that changes in the ini >> > file ends up in the generated MakeFile? >> >> I assume that you updated fpcmake.ini in /fpcsrc/utils/fpcm/ (or without >> /fpcsrc if using a checkout of the fpc repository rather than fpcbuild) >> and rebuilt either all utils, or just fpcmake, right? Could you please >> check whether fpcmake.inc (in the same directory) got updated during the >> rebuild (this should reflect your changes to fpcmake.ini)? If I >> understand >> it correctly, you copied the resulting updated fpcmake binary into the >> respective RTL directory and tried to regenerate the Makefile there, >> correct? > > My update procedure is basically what you describe: I manually added the > changes from r30766 fpcmake.ini to trunk, then call make inside the fpcm > directory, then execute the newly compiled fpcmake with the Makefile.fpc > file in the fpcm directory as test. > > Tonight I will check if fpcmake.inc got updated. Thanks for this hint, I > don't yet know how the different fpcmake pieces fit together. The .ini file should be translated to .inc using the data2inc utility (included with FPC as well) and then incorporated into the binary. This should happen automatically, but let's make sure it was the case for you as well. Apart from that, I would make sure that the right (newly compiled) fpcmake binary was really called rather than some previously existing one - I believe that building puts the new one in a subdirectory called 'bin' rather than the main fpcm directory, that's why I asked whether you copied it there if called using the ./fpcmake path. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Wed, Jul 4, 2018 at 9:21 AM, Tomas Hajny wrote: > On Wed, July 4, 2018 07:53, Christo wrote: > > Any hints on how to compile and use fpcmake so that changes in the ini > > file ends up in the generated MakeFile? > > I assume that you updated fpcmake.ini in /fpcsrc/utils/fpcm/ (or without > /fpcsrc if using a checkout of the fpc repository rather than fpcbuild) > and rebuilt either all utils, or just fpcmake, right? Could you please > check whether fpcmake.inc (in the same directory) got updated during the > rebuild (this should reflect your changes to fpcmake.ini)? If I understand > it correctly, you copied the resulting updated fpcmake binary into the > respective RTL directory and tried to regenerate the Makefile there, > correct? My update procedure is basically what you describe: I manually added the changes from r30766 fpcmake.ini to trunk, then call make inside the fpcm directory, then execute the newly compiled fpcmake with the Makefile.fpc file in the fpcm directory as test. Tonight I will check if fpcmake.inc got updated. Thanks for this hint, I don't yet know how the different fpcmake pieces fit together. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Wed, July 4, 2018 07:53, Christo wrote: . . > I'm trying to move Florian's changes in the target-subdir branch to trunk. > I've updated fpcmake.ini, but when I compile fpcmake and execute > ./fpcmake -Tall -w Makefile.fpc the regenerated MakeFile doesn't have any of > the modifications in fpcmake.ini. > > Any hints on how to compile and use fpcmake so that changes in the ini > file ends up in the generated MakeFile? I assume that you updated fpcmake.ini in /fpcsrc/utils/fpcm/ (or without /fpcsrc if using a checkout of the fpc repository rather than fpcbuild) and rebuilt either all utils, or just fpcmake, right? Could you please check whether fpcmake.inc (in the same directory) got updated during the rebuild (this should reflect your changes to fpcmake.ini)? If I understand it correctly, you copied the resulting updated fpcmake binary into the respective RTL directory and tried to regenerate the Makefile there, correct? Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Sun, 2017-12-03 at 19:05 +0100, Florian Klämpfl wrote: > Am 29.11.2017 um 06:36 schrieb Christo: > > > > On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: > > > > > > I am looking for an easy way to have all cortex-m compilers available > > > at the same time to be able to do automated building/testing > > There is a similar problem with the AVR target having several > > subarchitectures. One option I think is to have a subarch defined by > > the compiler, then it would be easy to lay out the compiled unit > > structure in fpc.cfg according to subarch. I've made an attempt at > > adding a subarch define to my local compiler source for AVR, but > > haven't developed the idea further. I'm not a compiler dev so there > > may be better options. > Subarch directories are imo the best solution, I have a half-backen patch for > this, not yet > finished > though. I'm trying to move Florian's changes in the target-subdir branch to trunk. I've updated fpcmake.ini, but when I compile fpcmake and execute ./fpcmake -Tall -w Makefile.fpc the regenerated MakeFile doesn't have any of the modifications in fpcmake.ini. Any hints on how to compile and use fpcmake so that changes in the ini file ends up in the generated MakeFile? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
I am doing something similar to what you are doing, see below I also needed to create a softlink so that fpc can call ppcrossarm, it expects to call ppcarm By using 'INSTALL_UNITDIR' there is no need to copy files at the end. You will need to do a little tweak in fpc.cfg, after this it is transparent to handle the different subarchs, at least for arm and mipsel ;-) Now I can use fpc to select matching arch/subarch and Lazarus works just fine. Michael fpc-cfg change: # searchpath for units and other system dependent things #ifdef embedded -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch/* -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch/rtl #else -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/* -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/rtl #endif --- snip Buildscript: CROSSOPT="-O1 -gw2 -dDEBUG" #CROSSOPT="-O1 -gw2 -dDEBUG -godwarfcpp" SUBARCH=armv6m make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- || exit 1 make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- INSTALL_UNITDIR=/usr/local/lib/fpc/3.1.1/units/arm-embedded/$SUBARCH/rtl || exit 1 #mv /usr/local/lib/fpc/3.1.1/ppcrossarm /usr/local/lib/fpc/3.1.1/ppcrossarm-$SUBARCH SUBARCH=armv7m make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- || exit 1 make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- INSTALL_UNITDIR=/usr/local/lib/fpc/3.1.1/units/arm-embedded/$SUBARCH/rtl || exit 1 #mv /usr/local/lib/fpc/3.1.1/ppcrossarm /usr/local/lib/fpc/3.1.1/ppcrossarm-$SUBARCH SUBARCH=armv7em make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- || exit 1 make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- INSTALL_UNITDIR=/usr/local/lib/fpc/3.1.1/units/arm-embedded/$SUBARCH/rtl || exit 1 #cp /usr/local/lib/fpc/3.1.1/ppcrossarm /usr/local/lib/fpc/3.1.1/ppcrossarm-$SUBARCH ln -sf /usr/local/lib/fpc/3.1.1/ppcrossarm /usr/local/bin/ppcarm Am 22.02.18 um 21:35 schrieb Christo: On Mon, 2017-12-04 at 08:22 +0100, Michael Ring wrote: Hi Florian! I would like to work on this patch, can you share it with me? Thank you, Michael Am 03.12.17 um 19:05 schrieb Florian Klämpfl: Am 29.11.2017 um 06:36 schrieb Christo: On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: I am looking for an easy way to have all cortex-m compilers available at the same time to be able to do automated building/testing There is a similar problem with the AVR target having several subarchitectures. One option I think is to have a subarch defined by the compiler, then it would be easy to lay out the compiled unit structure in fpc.cfg according to subarch. I've made an attempt at adding a subarch define to my local compiler source for AVR, but haven't developed the idea further. I'm not a compiler dev so there may be better options. Subarch directories are imo the best solution, I have a half-backen patch for this, not yet finished though. I've made a script file (attached) that iterates through the different subarchitectures available for the AVR compiler, calls make and then moves the compiled units to a subdirectory. I think the logic of this script should be moved to the existing rtl makefile so that all subarchitectures for a target gets generated and sorted in one go. Of course then the default fpc.cfg ideally needs to be updated to reflect the subarch folder structure for ARM and AVR. I'm putting this out there hoping that someone familiar with the topic and makefile syntax can help with a patch for FPC. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
Michael, I have just noticed a target-subdir folder in svn.freepascal.org/svn/fpc/branches/target-subdir/ It seems as if rev 30766 contains Florian's first modifications to implementation the subarch subfolder option. On 4 Dec 2017 9:23 am, "Michael Ring" wrote: Hi Florian! I would like to work on this patch, can you share it with me? Thank you, Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Mon, 2017-12-04 at 08:22 +0100, Michael Ring wrote: > Hi Florian! > > I would like to work on this patch, can you share it with me? > > Thank you, > > Michael > > > Am 03.12.17 um 19:05 schrieb Florian Klämpfl: > > > > Am 29.11.2017 um 06:36 schrieb Christo: > > > > > > On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: > > > > > > > > I am looking for an easy way to have all cortex-m compilers available > > > > at the same time to be able to do automated building/testing > > > There is a similar problem with the AVR target having several > > > subarchitectures. One option I think is to have a subarch defined by > > > the compiler, then it would be easy to lay out the compiled unit > > > structure in fpc.cfg according to subarch. I've made an attempt at > > > adding a subarch define to my local compiler source for AVR, but > > > haven't developed the idea further. I'm not a compiler dev so there > > > may be better options. > > Subarch directories are imo the best solution, I have a half-backen patch > > for this, not yet > > finished > > though. I've made a script file (attached) that iterates through the different subarchitectures available for the AVR compiler, calls make and then moves the compiled units to a subdirectory. I think the logic of this script should be moved to the existing rtl makefile so that all subarchitectures for a target gets generated and sorted in one go. Of course then the default fpc.cfg ideally needs to be updated to reflect the subarch folder structure for ARM and AVR. I'm putting this out there hoping that someone familiar with the topic and makefile syntax can help with a patch for FPC. build-AVR-embedded-rtl-all.sh Description: application/shellscript ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Mon, 2017-12-04 at 08:22 +0100, Michael Ring wrote: > Hi Florian! > > I would like to work on this patch, can you share it with me? > Am 03.12.17 um 19:05 schrieb Florian Klämpfl: > > > > Am 29.11.2017 um 06:36 schrieb Christo: > > > > > > On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: > > > > > > > > I am looking for an easy way to have all cortex-m compilers available > > > > at the same time to be able to do automated building/testing > > > There is a similar problem with the AVR target having several > > > subarchitectures. One option I think is to have a subarch defined by > > > the compiler, then it would be easy to lay out the compiled unit > > > structure in fpc.cfg according to subarch. I've made an attempt at > > > adding a subarch define to my local compiler source for AVR, but > > > haven't developed the idea further. I'm not a compiler dev so there > > > may be better options. > > Subarch directories are imo the best solution, I have a half-backen patch > > for this, not yet > > finished > > though. I've missed a critical bit om information until now - there is a config file macro replacement option called $FPCSUBARCH available since r29316. At the moment I've modified my .fpc.cfg to use the following include to locate RTL units: #IFDEF EMBEDDED -Fu~/fpc/$fpcversion/rtl/units/$fpctarget/$FPCSUBARCH/ #ELSE -Fu~/fpc/$fpcversion/rtl/units/$fpctarget/ #ENDIF So far I've compiled the AVR RTL for different subarch types, then copied the units into their respective subdirectories. Once this is done switching between different controllers irrespective of subarch type works. The additional work required is in my opinion: * Change makefile to automatically compile all available controllers by subarch type and specify output directory as rtl/units/$FPCTARGET/$FPCSUBARCH/ or as appropriate for directory configuration. * Update fpc.cfg template to reflect change in default rtl directory structure. Not sure if this approach will work for all embedded targets though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
Hi Florian! I would like to work on this patch, can you share it with me? Thank you, Michael Am 03.12.17 um 19:05 schrieb Florian Klämpfl: Am 29.11.2017 um 06:36 schrieb Christo: On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: I am looking for an easy way to have all cortex-m compilers available at the same time to be able to do automated building/testing There is a similar problem with the AVR target having several subarchitectures. One option I think is to have a subarch defined by the compiler, then it would be easy to lay out the compiled unit structure in fpc.cfg according to subarch. I've made an attempt at adding a subarch define to my local compiler source for AVR, but haven't developed the idea further. I'm not a compiler dev so there may be better options. Subarch directories are imo the best solution, I have a half-backen patch for this, not yet finished though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
Am 29.11.2017 um 06:36 schrieb Christo: > On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: >> I am looking for an easy way to have all cortex-m compilers available >> at the same time to be able to do automated building/testing > > There is a similar problem with the AVR target having several > subarchitectures. One option I think is to have a subarch defined by > the compiler, then it would be easy to lay out the compiled unit > structure in fpc.cfg according to subarch. I've made an attempt at > adding a subarch define to my local compiler source for AVR, but > haven't developed the idea further. I'm not a compiler dev so there > may be better options. Subarch directories are imo the best solution, I have a half-backen patch for this, not yet finished though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: > I am looking for an easy way to have all cortex-m compilers available > at the same time to be able to do automated building/testing There is a similar problem with the AVR target having several subarchitectures. One option I think is to have a subarch defined by the compiler, then it would be easy to lay out the compiled unit structure in fpc.cfg according to subarch. I've made an attempt at adding a subarch define to my local compiler source for AVR, but haven't developed the idea further. I'm not a compiler dev so there may be better options. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?
I am looking for an easy way to have all cortex-m compilers available at the same time to be able to do automated building/testing Inspired by the -V parameter of fpc I started my journey and ended up with something different. My question is now did I go down the correct path or is there a better way to fulfill my requirements: - I want to be able to switch between armv6m, armv7m and armv7em without the need to build the matching compiler/rtl - I want lazarus to use fpc as start compiler, I want to be able to configure the whole compiler switching via Project settings. - I want to be able to use lazbuild so that I can do automated builds of my lazarus projects. I found this helpful page: http://wiki.freepascal.org/FPC_Version_Switcher#Setting_the_fpc_frontend_executable_path but in the end this approach did not work for me, FPC version switcher is not available in lazarus svn (or I am too blind to find it) and in the end I had some issues with using lazbuild when defining the -V switch in my project settings. In the end I came up with the following approach: Build ppcrossarm and make sure that the rtls do end up in those directories: /usr/local/lib/fpc/3.1.1/units/arm-embedded/armv6m/rtl /usr/local/lib/fpc/3.1.1/units/arm-embedded/armv7m/rtl /usr/local/lib/fpc/3.1.1/units/arm-embedded/armv7em/rtl created a softlink so that the crosscompiler can be caled via /usr/local/bin/fpc ln -sf /usr/local/lib/fpc/3.1.1/ppcrossarm /usr/local/bin/ppcarm added the following to my /etc/fpc.cfg: #ifdef embedded -Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch/rtl #endif and then I add the following lines to the user-defined project settings in Lazarus: -Cparmv7em -XP/usr/local/bin/arm-none-eabi- -Wpnucleof411re -dnucleof411re I thought about putting -Fu/usr/local/lib/fpc/3.1.1/units/arm-embedded/armv7em/rtl in the project Settings so that I do not need to tweak /etc/fpc.cfg but I do not like the fact that I have to hardcode paths there, is there a better way? If yes then I'd prefer that a lot over tweaking /etc/fpc.cfg Michael -- Here's how I build the cross-compiler: SUBARCH=armv6m #SUBARCH=armv7m #SUBARCH=armv7em make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- || exit 1 make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- INSTALL_UNITDIR=/usr/local/lib/fpc/3.1.1/units/arm-embedded/$SUBARCH/rtl || exit 1 cp /usr/local/lib/fpc/3.1.1/ppcrossarm /usr/local/lib/fpc/3.1.1/ppcrossarm-$SUBARCH ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal