Poplog on Intel EM64T

Some time ago there was a question if Polog works on Intel EM64T
processors. Now I can report that I just istalled Poplog on
2.66 GHz Intel Pentium D processor. The only problems during
istallaion happend because the machine runs 64-bit Debian and
X files are in /usr/lib (there was also a Lesstif problem,
Debian seem to ship an old version of Lesstif). I did only
minimal test, but it seems that everthing that works on Amd64
machines also works on Intel machines.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl

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.
>

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.
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. Also (but that is old news) on Debian one needs libncurses.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl

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/pr...NUX_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/pr...g/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/pr...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

Aaron Sloman wrote:
> Waldek Hebisch wroc.pl> writes:
> [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.
>

I am affraid that conditionals should be restored.

> > 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/pr...NUX_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:
>

The linking proper works fine. I just had to modify CHECK_LINUX_FACILITIES
and LINK_MOTIF_POPLOG to convince them that X (and Lesstif) is present.

> > 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.
>

Well, the first thing that newpop does is to relink the system. That
step failed due to lack '-lncurses' in poplink_cmnd.motif.sh. Poplog
install succeds even if that step fails, I just mentioned that
the first step still fails.


--
Waldek Hebisch
hebisch@math.uni.wroc.pl

Waldek Hebisch <hebisch@math.uni.wroc.pl> writes:

> Date: Thu, 19 Oct 2006 14:02:25 +0000 (UTC)
> Organization: Politechnika Wroclawska
>
> Aaron Sloman wrote:
> > Waldek Hebisch wroc.pl> writes:
> > [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 am affraid that conditionals should be restored.

Added to my 'Todo' list!

>
> > > 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/pr...NUX_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:
> >
>
> The linking proper works fine. I just had to modify CHECK_LINUX_FACILITIES
> and LINK_MOTIF_POPLOG to convince them that X (and Lesstif) is present.

I was under the impression that the locations of those files had to
be known to the poplog poplink mechanism, and it was not enough for
them to be present in one of the standard places. Maybe recent
versions of linux leave the searching to the operating system
(sensibly).

> > > 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.
> >
>
> Well, the first thing that newpop does is to relink the system. That
> step failed due to lack '-lncurses' in poplink_cmnd.motif.sh. Poplog
> install succeds even if that step fails, I just mentioned that
> the first step still fails.

I presume that if it is needed in poplink_cmnd.motif.sh (saved from
an earlier run of poplink) then it is also needed in poplink_cmnd,
which is recreated whenever poplink (pgcomp) is run?

I was under the impression that that the link command did not need
to include '-lncurses' because it is already in

$popsrc/termcap.p

and will be used at compile time (by pgcomp).

Perhaps (as usual!) I don't understand enough about the mechanisms.

Thanks for all your help.

Incidentally if you have changed any scripts in ways that do not
depend on your local setup, could you email them to me. It may
speed up changes I should make!

Thanks.
Aaron

Aaron Sloman <A.Sloman@cs.bham.ac.uk> wrote:
> Waldek Hebisch <hebisch@math.uni.wroc.pl> writes:
> > The linking proper works fine. I just had to modify CHECK_LINUX_FACILITIES
> > and LINK_MOTIF_POPLOG to convince them that X (and Lesstif) is present.
>
> I was under the impression that the locations of those files had to
> be known to the poplog poplink mechanism, and it was not enough for
> them to be present in one of the standard places. Maybe recent
> versions of linux leave the searching to the operating system
> (sensibly).
>

You need to give a _list_ of directories which contain all libraries
which you use. Linker searches trough all of the list to find
a library. Since /usr/bin is on the list anyway, linker has
no problem to find X libraries there (note that redundant
/usr/X11R6/lib does not hurt). I would speculate that
move of X libraries to /usr/bin is intended to simplify linking:
there is no need to specify extra directories.

> > > > 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.
> > >
> >
> > Well, the first thing that newpop does is to relink the system. That
> > step failed due to lack '-lncurses' in poplink_cmnd.motif.sh. Poplog
> > install succeds even if that step fails, I just mentioned that
> > the first step still fails.
>
> I presume that if it is needed in poplink_cmnd.motif.sh (saved from
> an earlier run of poplink) then it is also needed in poplink_cmnd,
> which is recreated whenever poplink (pgcomp) is run?
>
> I was under the impression that that the link command did not need
> to include '-lncurses' because it is already in
>
> $popsrc/termcap.p
>
> and will be used at compile time (by pgcomp).
>

The first link uses distributed poplink_cmnd.motif.sh (pgcomp is
_not_ run). Since the rest of install works I assume that
pgcomp is doing its job (so the _second_ link is successful).

--
Waldek Hebisch
hebisch@math.uni.wroc.pl