Hello.

While trying to build FPC from today CVS sources on the BeOS platform (using "make beoszip" from the root directory):

I had to add two paths on the Makefile.fpc (./rtl/beos/) : ----------
[compiler]
includedir=$(INC) $(PROCINC) $(UNIXINC) $(RTL)/objpas/classes $(RTL)/ objpas/sysutils
----------

After a "fpcmake" there... the "make beoszip" goes nicely until it dies saying that "as" can't be found (it list my $PATH, and it _should_ find "as" there).

Same happens with "sh" and "ar". Dropping symlinks to those binaries one the compiler directory makes it work.

After that, I tried to recompile the RTL with "make rtl smart", and now it does find "ar" (because of the symlink) but fails with "Error: Can't call the linker, switching to external linking". The generated ppas.sh shows a line where the error is evident:

"../../fpc-1.9.1/bin/beos/ar rs ./libpsystem.a ./SYSTEM.sl/system*.o"

As the FS in BeOS is case sensitive, ar fails because all the *.o are in the "./system/" directory, not in "./SYSTEM/".

If I can be of any help on testing fixes/workarounds for this, let me know.

Thanks.

Oscar Lesta.

BiPolar wrote

Hello. While trying to build FPC from today CVS sources on the BeOS platform (using "make beoszip" from the root directory):

I guess the main problem is that the 1.0.x BeOS rtl contains a lot of patches which aren't merged into 1.9.x sources.

I tried to implement a better solution, commited. Please tell me, if it works.

After a "fpcmake" there... the "make beoszip" goes nicely until it dies saying that "as" can't be found (it list my $PATH, and it _should_ find "as" there).

$PATH doesn't matter, the compiler searches only in the dir where the compiler executable is and in the dirs specified by -FD

How good does a non smartlinked BeOS version work?

Maybe Peter knows more :)

Effectively, there is no 1.9 BeOS. After the Unix reform, the BeOS would be written from scratch. Oco (IRC) said he'd look at it, but I haven't heard from his experiences (or expected troubles) yet.

Hello again Florian.

> While trying to build FPC from today CVS sources on the BeOS > platform

[...]

================
make[4]: *** No rule to make target `classes.pp', needed by `classes.ppu'. Stop.
================

BeOS's classes.pp is still on the FCL, not on the RTL as for most other plataforms.

ppc386 does list all the dirs in my PATH variable. Maybe the output will be more clear:

==========
/boot/develop/BePascal>ppc386 -Sd -Xs -FU./units TestApp2 beobj.pp(62,3) Error: Assembler .:/boot/home/config/bin:/bin:/boot/ apps:/boot/preferences:/boot/beos/apps:/boot/beos/preferences:/boot/ develop/tools/gnupro/bin:/boot/home/config/scripts:/boot/develop/tools/ fpc/bin/beos/as not found, switching to external
beobj.pp(62,3) Fatal: There were 1 errors compiling module, stopping ==========

> Same happens with "sh" and "ar". Dropping symlinks to those binaries > one the compiler directory makes it work. How good does a non smartlinked BeOS version work?

It has its issues:
- the mentioned issue with as, ar, sh, etc.
- doesn't reads the config file.
- fpc bails out with a "can't execute ppc386.exe". (The problem seems to be on ./utils/Makefile.fpc where UNIX is defined for Linux and FreeBSD, but not for BeOS.)
- I got the "Internal error 200309041" [ compiler/rgobj.pas (746, 17) ] while trying to compile PasDoc 0.8.8 ( The error is on pasdoc_gen.pas (1514) )

But, besides that, it does compiles all the sources of BePascal, and also compiles our test apps (GUI) and that works ok. (the size of the binary is ~20% bigger :-( )

Most of the issues seems to be related to IFDEFs that "fails" on BeOS,
for example, on fpc.pp:
--------------------------------
{$ifdef UNIX}
    exeext='';
{$else UNIX}
  {$ifdef AMIGA}
    exeext='';
  {$else}
    exeext='.exe';
  {$endif}
{$endif UNIX}
--------------------------------

And on BeOS fpc tries to use "ppc386.exe".

Maybe the problem with finding as, ar, etc, and also the not reading of the ".fpc.cfg" (that on BeOS shouldn't have the dot in front, BTW) are related to that: some define is not defined, and the code gets mixed unix/dos stuffs (an older version of FPC used to send " /C /bin/sh" to shell, being /C from COMSPEC /C :-) ).

Well, that's all for now. Many thanks for FPC.

---
Oscar Lesta.
(not on the mail list, please CC any reply)

size of the binaries has low priority. Functionality and stability is much more important. And comparing size of binaries without smartlinking also doesn't give an indication of the real size of code required by the program.

i_beos.pas misses the extradefines : 'UNIX;HASUNIX';

But that will maybe trigger a lot of new errors because of the Unix redesign.