[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Thu Oct 19 12:20:03 2006 
Subject:pop-forum Re: Poplog on Intel EM64T (and motif) 
From:Aaron Sloman 
Volume-ID: 

Waldek Hebisch wroc.pl> writes:

> Date: Thu, 19 Oct 2006 01:00:24 +0000 (UTC)
> Organization: Politechnika Wroclawska
>
> Aaron Sloman <A.Sloman@cs.bham.ac.uk> wrote:
> >
> > Regarding the Lesstif problem, I previously reported a problem with
> > Motif in the version of 64 bit Poplog linked on the free poplog
> > site:
> >
> > > As far as I can tell everything works except that if linked with
> > > Motif, Poplog's graphical windows do not trap the 'close' event
> > > properly and treat it as 'destroy', which kills the whole process.
> > > So by default that version of Poplog has been linked without Motif.
> >
>
[WH]
> Yes, this this problem is (or at least was -- I did not try recently)
> also present with Lesstif. My problem was that Lesstif (at least on
> Debian) still do not have 'XmTextFieldGetAdd' and 'XmTextGetAddMode'
> so I had to re-add conditionals that were in earlier versions.

Hmm, I wonder if those conditionals (removing those two identifiers
in Linux Poplog) should be restored.

I have no idea whether anyone really needs those two functions.

> The second problem was that X libraries on 64-bit Debian are in /usr/lib.
> I suspect that all in the future all versions of Debian will have X in
> /usr/lib.

It's more general than Debian: x.org is now widely used instead of
XFree86, e.g. also in Fedora Core 5.

I can see how moving everything into a central place has some
advantages (less complex search lists, etc.) but it really makes
grep and ls take much longer, and reduces modularity.

(It used to be easy to switch between two versions of the X window
system simply by changing a symbolic link -- as you can still do
with poplog!)

So poplog's linking mechanisms now need to change, alas.
Also the script for checking for the availability of X11 libraries.

    http://www.cs.bham.ac.uk/research/projects/poplog/com/CHECK_LINUX_FACILITIES

I have not had time to look into the details that need to be changed
in Poplog. To sort out the linking will require coordinating things
in these interacting files:

    $usepop/pop/com/popenv (and popenv.sh)
        environmental variables set up
        (invoked by the poplog (or poplog.sh) startup script)

    $usepop/pop/src/syscomp
        Pop-11 code for building the poplink.psv saved image
        I.e.
            $usepop/pop/src/syscomp/poplink_main.p
            (and files it uses)

    $usepop/pop/pop/pglink
        script for running the poplink.psv saved image
        to create
            $usepop/pop/pop/poplink*.o
            $usepop/pop/pop/poplink_cmnd

Unfortunately, I don't think the relationships between those files
have ever been documented. (If anyone can find documentation, please
let me know.)

If we are lucky, and the system is sufficiently modular, it will
suffice to change just the popenv and popenv.sh scripts.

> Also (but that is old news) on Debian one needs libncurses.

I was under the impression that this had been fixed according to
your recommendations in

    $popsrc/termcap.p

in March 2005 (in poplog V15.6)

So poplog now does not use termcap at all, only curses or, in linux,
ncurses.

This was merged into the version of 64bit linux poplog here

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

If you have made any recent changes I would like to be able to merge
them with that version.

The tar file is

    http://www.cs.bham.ac.uk/research/projects/poplog/amd64-v15.6/bham-linux-poplog-v15.6-amd64.tar.gz
    (about 23 Mbytes, last rebuilt 17 April 2006)

If required I can produce a 'core' version without all the library
packages (in $usepop/pop/packages/*)

[I should do that anyway, to simplify providing different versions.
of poplog. But it will require people to download two tarballs to
install poplog.]

Cheers

Aaron