In article <d61sbr$el...@soapbox.cs.bham.ac.uk>,
<A.Sloman@cs.bham.ac.uk> wrote:
>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.)
(I assume you mean you vet the relay from usenet? Don't think there's
much one can do about the current spamming of the newsgroup. Sadly.)
OK -- if I find I need to post a lot, I will. At the moment, I'd
rather not if you don't mind, because it also means I have to set up
handling at this end. (I keep each list I'm on in a separate mailbox,
so *my* mail doesn't keep bugging me each time there's a post!)
>
>
>> 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.
Only about a year ago.
>
>I suggest you start from 15.6 (badly named, but never mind), available
>here
I suspect I ought to continue along this path for now, as I'm just
beginning to find my way around this distribution [not that easy! (:-)].
I'll try installing 15.6 on Linux though, and see what it looks like.
>
>
>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.
This is part (most) of the problem. BeOS is "mostly posix", and a
high proportion of Linux and other Unix sources compile and run
directly on BeOS, but usually they don't have to tinker with memory
areas and so on as poplog does. With my post, I guess I was hoping
for some general pointers as to where pop does this sort of thing,
so I could start looking for differences.
>
>
>Have you read the poplog porting guide (ppg) and other documents in
>here:
> http://www.cs.bham.ac.uk/research/poplog/sysdoc/
Yes, I have them. I suspect there's a lot more to be gleaned from
the porting guide in particular [though I was a bit put off by the
"OUT OF DATE" comment at the top!]
>
k_changed
>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).
This is the path I'm following. Though I do admit to still being
confused about the intended purpose of the various '***pop11's.
'newpop11' is just what a freshly linked system is named, I gather,
and 'corepop' and 'corepop11' are the same file (hstorical difference),
but in the end we have 'corepop11', 'basepop11', and plain 'pop11'.
Why are they all there? How do they differ?
>
>If you are lucky that minimal executable will be $usepop/pop/pop/corepop
>included in the v15.6 linux package.
I'm afraid this is unlikely. For a start, the library names in BeOS
differ, so Linux executables never run directly under BeOS; relinking
at least is required.
>
>If that does not work, you'll have to go into cross compiling mode on a
>linux system, as in the porting guide.
Very probably... (:-/) I'm trying to defer this as long as possible,
though.
> <useful instructions noted and snipped...>
>
>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
>path names were all expanded at the time poplink_cmnd file was created.
>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.
I think I have this under control. In fact I edited poplink_cmnd to
use direct pathnames in my setup, so I think it works fine.
>
>
>giving google
>
> linux brk_addr
>
>produces lots of references. Maybe one of them will answer your
>question.
I wish... (:-/) They all seem to assume one *knows* its function
already. However, I'm beginning to believe that it is not my
immediate problem at least, and (with help from some on this list,
and more digging in the source code) have some beginning of understanding
of what it does. On linux at least it is the top address available
for stack storage, associated with the 'brk()' call. How BeOS handles
this isn't yet clear.
>
>
>This suggests to me that porting without changing system calls in the
>poplog sources is doomed to fail, alas.
Afraid so. I'm pretty sure I'll end up cross-compiling, but I have to
find out what needs changing first. I'm stepping through with the
debugger at the moment, to try and locate exactly where it fails.
Maybe that'll work.
Many thanks for your detailed response.
-- Pete --
|