failure to build cross compiler
lazarus / 62-General

----------------------------------------------------------------------
ghieber · 2015-03-16 04:05

I am running Lazarus / fpc 2.6.4 on Linux, Fedora 19.

I tried to build some cross compilers. While arm-linux compiled
without problems, building a compiler for avr-embedded failed. With
both

make all OS_TARGET=embedded CPU_TARGET=avr CROSSOPT=-O-

as suggested some time ago by "FPK" on StackOverflow, and

sudo make crossinstall CPU_TARGET=avr OS_TARGET=embedded
CROSSBINDIR=/usr/local/bin
  BINUTILPREFIX=avr- INSTALL_PREFIX=/tmp/fpc CROSSOPT=-O-

I get the same error message:
Code: [Select]make: -iVSPTPSOTO: Kommando nicht gefunden          //
command not found
make install CROSSINSTALL=1
make[1]: -iVSPTPSOTO: Kommando nicht gefunden
make[1]: Entering directory `/home/georg/devel/fpc-2.6.4'
make compiler_cycle RELEASE=1
make[2]: -iVSPTPSOTO: Kommando nicht gefunden
make[2]: Entering directory `/home/georg/devel/fpc-2.6.4'
make -C compiler cycle
make[3]: -iVSPTPSOTO: Kommando nicht gefunden
make[3]: Entering directory `/home/georg/devel/fpc-2.6.4/compiler'
make OS_TARGET= CPU_TARGET= CROSSBINDIR= BINUTILSPREFIX=
CROSSCYCLEBOOTSTRAP=1 rtlclean rtl
make[4]: Entering directory `/home/georg/devel/fpc-2.6.4/compiler'
make -C  clean
make: Entering an unknown directory
make: *** clean: Datei oder Verzeichnis nicht gefunden.  Schluss.   
 // file or directory not found. bye.
make: Leaving an unknown directory
make[4]: *** [rtlclean] Fehler 2
// errors 2
make[4]: Leaving directory `/home/georg/devel/fpc-2.6.4/compiler'
make[3]: *** [cycle] Fehler 2
make[3]: Leaving directory `/home/georg/devel/fpc-2.6.4/compiler'
make[2]: *** [compiler_cycle] Fehler 2
make[2]: Leaving directory `/home/georg/devel/fpc-2.6.4'
make[1]: *** [build-stamp.avr-embedded] Fehler 2
make[1]: Leaving directory `/home/georg/devel/fpc-2.6.4'
make: *** [crossinstall] Fehler 2

Also, the same happens with sources of version 2.6.4 and 3.1.1, SVN
trunk of today.

I know that the avr compiler is tagged "experimental", so problems are
to be expected. This seems to be one in the makefiles, and as this
absolutely unknown territory to me, maybe someone can help - or give
me a hint, which previous version compiled the AVR - compiler.

Thanks in advance
Georg

----------------------------------------------------------------------
engkin · 2015-03-16 04:22

I don't know, but when you said "experimental" I concluded that it
should not be in the trunk or 2.6.4 branch. Looking for a possible
experimental branch, I can see avr32. Would that be it?

----------------------------------------------------------------------
marcov · 2015-03-16 04:51

Quote from: ghieber on March 16, 2015, 05:05:31 am
Code: [Select]make: -iVSPTPSOTO: Kommando nicht gefunden          //
command not found

That one means that FPC is not found. It takes a full install of FPC
to build fpc.

If it _is_ installed, it might not be in the $PATH

----------------------------------------------------------------------
ghieber · 2015-03-16 13:13

@engkin:
"experimental" is a quote from the wiki. It looks like the avr port
has been in a separate branch for some time, but it went back into the
trunk some time ago. It defitively is there.
# Information about the state of the avr port is scarce, there are a
few bits and pieces scattered all over the web, the latest (from 2011)
the one I quoted from "FPK". It is obviously not something very high
on the priority list.

@marcov:
Thanks. I will certainly follow this hint, even if I have my doubts.
I checked out the 3.1.1 trunk, then built the native compiler for my
system (with the 2.6.4 that is installed as part of Lazarus as a
starting compiler) and installed it in the /tmp/fpc directory. After
that, I built a arm-linux cross compiler, which I also installed in
the a.m. directory. This worked. Only the avr compiler failed. I will,
however, recompile the arm and capture the whole make ouput.

I then downloaded the 2.6.4. stable source, and tried to build the avr
compiler from there, same result.

And, the 2.6.4 compiler definitely is in the path. it's in /usr/bin,
like "everything else"....

----------------------------------------------------------------------
ghieber · 2015-03-17 04:46

Problem solved, see end of post!

I leave the post here anyway, maybe It helps others to avoid the
!@#%§grrr... error I made.
Near the end however, there is an observation in a source file that
stands, and that may be a problem, even if it has nothing to do with
my issue.

----------------------------------------------------------------------
------------------------------------

I did some more experiments, so far with the following results:

First, I made a fresh checkout of the SVN trunk. On that, I built a
native compiler:

Code: [Select]make distclean
[georg@georg1 trunk]$ make cycle
[georg@georg1 trunk]$ make all >& makeall.log
[georg@georg1 trunk]$ sudo make install
PP=/home/georg/fpc/trunk/compiler/ppcx64 INSTALL_PREFIX=/usr/local
and put a symlink to the ppcx64 binary into /usr/local/bin.
As in the path /usr/local/bin comes before /usr/local, executing fpc
invokes the 3.1.1 compiler.
So far, so good.

Next step:
Code: [Select]make distclean
[georg@georg1 trunk]$ sudo make all crossinstall  OS_TARGET=linux
CPU_TARGET=arm CROSSBINDIR=/usr/local/bin BINUTILSPREFIX=arm-linux-
INSTALL_PREFIX=/usr/local >& makearm.log
Binutils are still there, from yesterday. In the
/usr/local/lib/fpc/3.1.1 branch correctly appears ppcrossarm, and arm-
linux subdirs under units and fpmkinst. The first lines of makearm.log
are:
Code: [Select]make compiler_cycle RELEASE=1
make[1]: Entering directory `/home/georg/fpc/trunk'
make -C compiler cycle
make[2]: Entering directory `/home/georg/fpc/trunk/compiler'
make OS_TARGET=linux CPU_TARGET=x86_64 CROSSBINDIR= BINUTILSPREFIX=
CROSSCYCLEBOOTSTRAP=1 rtlclean rtl CYCLELEVEL=1
make[3]: Entering directory `/home/georg/fpc/trunk/compiler'
make -C /home/georg/fpc/trunk/rtl clean
make[4]: Entering directory `/home/georg/fpc/trunk/rtl'
/bin/rm -f fpcmade.x86_64-linux Package.fpc ./ppas.sh script.res
link.res 
/bin/rm -f *.s *_ppas.sh
make -C linux clean
make[5]: Entering directory `/home/georg/fpc/trunk/rtl/linux'
/bin/rm -f /home/georg/fpc/trunk/rtl/units/x86_64-linux/prt0.o
/home/georg/fpc/trunk/rtl/units/x86_64-linux/dllprt0.o
/home/georg/fpc/trunk/rtl/units/x86_64-linux/cprt0.o
/home/georg/fpc/trunk/rtl/units/x86_64-linux/gprt0.o
/home/georg/fpc/trunk/rtl/units/x86_64-linux/abitag.o
/bin/rm -f /home/georg/fpc/trunk/rtl/units/x86_64-linux/system.ppu
/home/georg/fpc/trunk/rtl/units/x86_64-linux/fpintres.ppu
/home/georg/fpc/trunk/rtl/units/x86_64-linux/si_prc.ppu
/home/georg/fpc/trunk/rtl/units/x86_64-linux/si_c.ppu
/home/georg/fpc/trunk/rtl/units/x86_64-linux/si_g.ppu
/home/georg/fpc/trunk/rtl/units/x86_64-linux/si_dll.ppu

ppcrossarm, identifies itself as "Free Pascal Compiler version 3.1.1
[2015/03/16] for arm".
So far, so good.

Next step:
Code: [Select]make distclean
sudo make all crossinstall  OS_TARGET=embedded CPU_TARGET=avr
CROSSBINDIR=/usr/local/bin BINUTILSPREFIX=avr-
INSTALL_PREFIX=/usr/local >& makeavr.log
results in the same error as yesterday, makeavr.log is:
Code: [Select]make: -iVSPTPSOTO: Kommando nicht gefunden
make compiler_cycle RELEASE=1
make[1]: -iVSPTPSOTO: Kommando nicht gefunden
make[1]: Entering directory `/home/georg/fpc/trunk'
make -C compiler cycle
make[2]: -iVSPTPSOTO: Kommando nicht gefunden
make[2]: Entering directory `/home/georg/fpc/trunk/compiler'
make OS_TARGET= CPU_TARGET= CROSSBINDIR= BINUTILSPREFIX=
CROSSCYCLEBOOTSTRAP=1 rtlclean rtl CYCLELEVEL=1
make[3]: Entering directory `/home/georg/fpc/trunk/compiler'
make -C  clean
make: Entering an unknown directory
make: *** clean: Datei oder Verzeichnis nicht gefunden.  Schluss.
make: Leaving an unknown directory
make[3]: *** [rtlclean] Fehler 2
make[3]: Leaving directory `/home/georg/fpc/trunk/compiler'
make[2]: *** [cycle] Fehler 2
make[2]: Leaving directory `/home/georg/fpc/trunk/compiler'
make[1]: *** [compiler_cycle] Fehler 2
make[1]: Leaving directory `/home/georg/fpc/trunk'
make: *** [build-stamp.avr-embedded] Fehler 2

The problem, IMHO, is not a missing or unfindable fpc. It is there,
and in the path. Looking into the Makefile reveals, that the
-iVSPTPSOTO option string is at one place added to the content of a
variable FPC to result in FPC_COMPILERINFO, if the latter does not
exist. The error is consistent with $FPC being empty, or too short, so
that finally -iVSPTPSOTO is interpreted as a command instead of
options. A command, that of course does not exist.

As Makefile is created by fpcMake, partly from built in logic, partly
from information stored in Makefile.fpc,  Looking into the sources of
fpcMake, I made one observation:
fpcmmain.pp, line 88 ff
Code: [Select]      CpuSuffix : array[TCpu] of string=(
   // why without underscore?? - GH
        '_i386','_m68k','_powerpc','_sparc','_x86_64','_arm','_powerpc
64','avr','_armeb', '_armel', '_mips', '_mipsel', '_mips64',
'_mips64el', '_jvm','_i8086','_aarch64'
      );
"avr" is the only item without a leading underscore. I changed this,
just as a try, recompiled fpcmake and rebuilt Makefile, but to no
avail. Anyway, I would like to bring this to the attention of the
developers, it looks strange and results in some strings not following
the usual pattern.

Uff. Long post. I hope it helps somebody to find an answer....

appended 17.3.15:

Problem seems to be much simpler (as usual....) , and to lay in my
sequence:

make distclean
sudo make all crossinstal....

The building make has to run as root to install it's products in
/usr/local.... . Consequently it creates unit directories and files
owned by root, which the following make distclean, under my normal
account, fails to clean. aparently the following make for a different
target gets confused by the leftover junk.

Now I managed to compile an avr compiler, the make process crashes
later compiling the rtl with it.
when compiling system.pp, the compiler stops with an Internal error
200309041 in one of the .inc's. Turning off optimization stops it
doing so, but now the same occurs in another .inc.
This is a hickup of the register allocation, and so something that is
to be expected from an "experimental", i.e. known to be buggy,
compiler.

Problem (of generating the cross compiler) solved.