[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Fri, 13 May 2005 09:34:51 +0000 (UTC) 
Subject:Re: Porting problems 
From:A . Sloman 
Volume-ID: 

Hi Pete,

If you plan to communicate frequently to pop-forum during the porting
process, it would be useful if you could join the list so that I don't
have to 'approve' every message. (I suppress quite a lot of spam.)

Write to majordomo at cs.bham.ac.uk with a one line message

    subscribe pop-forum

That will also ensure that you get all replies, e.g. those that come via
comp.lang.pop to pop-forum.

You can do the same later with 'unsubscribe pop-forum' to end your
membership of the list.

> Hi all.  I've finally [after several years!] got round to a serious
> effort to port poplog (15.53) to the Be OS.

That could be quite an old poplog distribution.

I suggest you start from 15.6 (badly named, but never mind), available
here

    http://www.cs.bham.ac.uk/research/poplog/v15.6

Detailed instructions are in the AREADME.txt file. Installation (on
linux) is much easier than ever before and the poplog system has been
re-structured (still in progress) by introducing the directory

    $usepop/pop/packages/

with different sub-directories for different extensions to the core
poplog, instead of depending on the $poplocal/local directory (which
should be left for really local stuff, not part of the normal
distribution).

E.g. AI teaching stuff that is not specifically about one of the
poplog languages or tools is moved to the teaching sub-directory, and
a lot of old files have been replaced by newer ones from bham.

Brent Fulgham reported that the changes made porting to debian
much easier:
    http://www.cs.bham.ac.uk/research/poplog/debian

> However, progress is
> painful, and I'm hoping soemone here may have a pointer or two.
>
> As a basis, BeOS on the x86 machines uses a standard ELF object format
> and the gcc compiler, so the linux files are a good start.  Of course
> the executables do not actually execute, becuase libraries don't match.

I think it will be useful if you can summarise the differences between
BeOS and linux in libraries that poplog will have to depend on. Then
people who know poplog well may be able to help you.

If you are lucky the relinking and rebuilding done by the v15.6
installation script will work for you. If not, you'll have work
to do.

Have you read the poplog porting guide (ppg) and other documents in
here:
    http://www.cs.bham.ac.uk/research/poplog/sysdoc/

My guess is that you will need to find or create a minimal pop11
executable that runs on BeOS then recompile and relink everything
starting from it (the new installation script relinks everything without
recompiling).

If you are lucky that minimal executable will be $usepop/pop/pop/corepop
included in the v15.6 linux package.

If that does not work, you'll have to go into cross compiling mode on a
linux system, as in the porting guide.

If it does work, you may still need to change something that is
operating system specific in the files used to create the three system
saved images (for compiling, archiving and linking poplog). Those system
building sources are in here:

    $usepop/pop/src/syscomp/*

If corepop runs, then you can use it to rebuild the system saved images
for compiling system sources, archiving them and linking (popc.psv,
poplibr.psv and poplink.psv). These saved images run on top of the
corepop binary.

If you can build them but things don't work after that, you may have to
change something in the syscomp directory, or something in the run time
sources directory
	$usepop/pop/src/
or something in
	$usepop/pop/extern/lib

The stuff in the sysdoc directory explains how to use the three main
system saved images to recompile everything in your environment (using
pgcomp), archive the binaries (using pglibr) then relink (using pglink).

If that all works then use 'pglink -core' to create a new version of
corepop (It creates a newpop11, which you copy -- using cp not mv -- to
corepop).

> I first tried poplink_cmnd to see if I could create runnable files,
> but got a lot of undefined references.

Exactly what they are could make a difference to what you should do
next.

Also if you have an old v15.53 one problem may be wrong path names in
the poplink_cmnd file. Until very recently the environment variables in
That's one of the changes in v15.6: the environment variables are
used in poplink_cmnd, so that the system is not location dependent.

But it sounds as if you got beyond that.

> First, there is '___brk_addr' in 'aextern.s'.  I've actually scoured
> my linux system to see if I could find any reference to this, but failed,

giving google

    linux brk_addr

produces lots of references. Maybe one of them will answer your
question.

If it is in aextern.s then it may be relevant to dynamic linking.

> so I really have no idea whther something like it is needed or not.
> I gather it has something to do with available stack, and I know that
> stack space is completely different on Be from Linux (but I don't
> remember how!)

This suggests to me that porting without changing system calls in the
poplog sources is doomed to fail, alas.

Since I know nothing about BeOS and have other urgent tasks, I'll leave
this for now. Maybe someone with more knowledge can help.

Aaron