In article <d7h95v$25j...@soapbox.cs.bham.ac.uk>,
<A.Sloman@cs.bham.ac.uk> wrote:
>
> (By the way, it may be hard for some readers to remember the
>context of your messages, so it is worth either expanding the subject
>line, as I have done, or adding a reminder at the beginning of each
>message.)
Sorry, yes. I usually do...
>
>> [...]
>> pglibr -c ./ *.w
>>
>> But this gives a mishap:
>>
>> ar: $popobjlib/src.olb: No such file or directory
>
>I must change the sysdoc documentation. Sometimes './' works and
>sometimes it doesn't. I don't know why.
Actually, now that I undestand the command better, I don't see how
it *could* work, because it seems to require the library file name (or
directory); the 'current directory' should be irrelevant.
[....]
>>
>> Which brings up the question -- what exactly is the reason for
>> 'pgcomp', 'pglibr', etc.? What advantage do they give over the
>> straight pop operations?
>
>They pcomp (compile sourcefiles) pglibr (archive .o and .w files)
>pglink (create files for linking and run the system linker) are
>used for three different stages in the process of creating a newpop11
>that is a candidate for a *user* basepop11, the run-time executable.
>
>Think of pgcomp as being like cc, pglibr as like ar, and pglink as
>loosely analogous to ld.
>
But this doesn't really get at my question. What puzzles me is why
one should use those scripts at all. In fact in both compiling and
linking as above, replacing 'pgcomp' with 'popc' and 'pglibr' with
'poplibr' seems to work identically. There must be occasions when the
scripts are more useful, but I haven't run across them yet.
>
>
>It is an unusually complex system. Sometimes I am surprised that the end
>result works so well and is so robust (at least on the unix/linux/vms
>systems I have used in the past).
I've actually succeeded now in creating a modified pop11 on Linux (as
I described I wanted to do) and copied that over to BeOS for comparison,
but I even ran into what is apparently a linux gcc bug/peculiarity on the
way (which I was able to bypass, so I won't go into it here).
I find that the problem *is* with the brk() call, but it's not clear
what's going wrong, yet.
Thanks for your description of how to modify the popc environment.
Following it, I was able to incorporate a modified sysdefs.p without
trouble.
> [....]
>
>I hope that in your case it will suffice to change things in syscomp,
>then rebuild the system saved images, then recompile everything.
I believe so. Have to determine what the basic storage allocation
problem is, first, though.
>
>
>poplog on unix/linux has always been designed so that instead of
>scattering its files all around the system they remain within
>a directory tree accessed relative to the environment variable $usepop
Yep -- this is a great help!
>
>This means that you can have a lot of different versions of poplog in
>the same machine and switch between them simply by clearing the
>environment variables, redefining $usepop, and then sourcing
>$usepop/pop/com/poplog(.sh) to set up the other environment variables.
That's exactly what I'm doing.
>
>If BeOS requires each program to have entries in system tables etc.,
>as I understand windows does, then you lose that benefit.
Fortunately, NO! BeOS is probably even better than Unix at encapsulating
things.
Thanks again.
-- Pete --
|