Discussion:
[Axiom-developer] Broken hypertex
Waldek Hebisch
2006-10-13 15:50:32 UTC
Permalink
Playing with build-improvements I have noticed that hypertex is broken:
clicking on "NAG link" and then on "Browser pages for individual routines"
freezes hypertex windows and gives the following error message at
Unexpected end of #<string-input stream from " ...">.

I have tracked down the error to src/interp/server.boot.pamphlet. In
the function serverReadLine we have:

....
action = $LispCommand =>
$NeedToSignalSessionManager := true
stringBuf := MAKE_-STRING $sockBufferLength
sockGetString($MenuServer, stringBuf, $sockBufferLength)
form := unescapeStringsInForm READ_-FROM_-STRING stringBuf
protectedEVAL form
....

After return from sockGetString content of stringBuf is all spaces,
and READ-FROM-STRING can not find anything to read and signals error.

I have put diagnostic printout in the function get_string_buf (in
src/lib/sockio-c.c.pamphlet) and from that I see that get_string_buf
is called and gets correct data. So the problem seem to be in
gcl foreign function interface.

I have seen this behaviour on two different machines, one 32-bit Athlon,
another 64-bit Athlon, both using gcl bundled with Axiom.
--
Waldek Hebisch
***@math.uni.wroc.pl
Gabriel Dos Reis
2006-10-13 16:52:32 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

| Playing with build-improvements I have noticed that hypertex is broken:

Is that reproducible with silver?

-- Gaby
Waldek Hebisch
2006-10-13 22:21:49 UTC
Permalink
Post by Gabriel Dos Reis
Is that reproducible with silver?
Probably no: when I tried build-improvements with gcl-2.6.7 the problem
went away.
--
Waldek Hebisch
***@math.uni.wroc.pl
Gabriel Dos Reis
2006-10-13 22:32:06 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| >
| > | Playing with build-improvements I have noticed that hypertex is broken:
| >
| > Is that reproducible with silver?
| >
|
| Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| went away.

Interesting.

We have a case to investigate. I seem to remember, but I'm not sure,
that the socket interface may have changed from 2.6.7 to 2.6.8pre.
Bill?

-- Gaby
Vanuxem Grégory
2006-10-14 00:18:24 UTC
Permalink
Post by Gabriel Dos Reis
| >
| >
| > Is that reproducible with silver?
| >
|
| Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| went away.
Interesting.
We have a case to investigate. I seem to remember, but I'm not sure,
that the socket interface may have changed from 2.6.7 to 2.6.8pre.
First, do you have installed (make install) Axiom ? If no (or may be
yes, I have never tested), there are two files named util.ht in the
sources, Tim is working on them, try the twos (try the other one i.e.
copy it to /mnt/something*, the diff and find programs will help you).
Personally I don't remember which I use but not the "regular one" since
I do not install Axiom. If this mail is unrelated to your issue after
these tests or if you do not understand it, forget this mail and sorry
for the inconvenience.

So with my version of Gold (the last)
"

BOOT>si::*gcl-extra-version*

8

~> it's gcl-2.6.8

The output of « "NAG link" and then on "Browser pages for individual
routines" » is

There is no constructor matching pattern "Nag*"


I have this output with Axiom Version: Axiom 3.0 Beta (February 2005)
too. It comes from a "Debian stable" package (with a little modification
(see the end of http://wiki.axiom-developer.org/AxiomBinaries)). Camm
can you look at this issue (forget the wiki bug), I did not report this
as a bug on the BTS, it seems to me that I'm alone. I can report it if
you can reproduce it.


Greg

PS : I'm really tired it's 2:18 in France, if this is not understandable
ask me I will try to elaborate tomorrow.
Gabriel Dos Reis
2006-10-14 00:36:17 UTC
Permalink
Vanuxem Grégory <***@wanadoo.fr> writes:

| Le samedi 14 octobre 2006 à 00:32 +0200, Gabriel Dos Reis a écrit :
| > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| >
| > | Gabriel Dos Reis wrote:
| > | > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| > | >
| > | > | Playing with build-improvements I have noticed that hypertex is broken:
| > | >
| > | > Is that reproducible with silver?
| > | >
| > |
| > | Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| > | went away.
| >
| > Interesting.
| >
| > We have a case to investigate. I seem to remember, but I'm not sure,
| > that the socket interface may have changed from 2.6.7 to 2.6.8pre.
|
| First, do you have installed (make install) Axiom ?

yes -- I always use axiom.build-improvements that way :-)

| If no (or may be
| yes, I have never tested), there are two files named util.ht in the
| sources, Tim is working on them, try the twos (try the other one i.e.
| copy it to /mnt/something*, the diff and find programs will help you).
| Personally I don't remember which I use but not the "regular one" since
| I do not install Axiom. If this mail is unrelated to your issue after
| these tests or if you do not understand it, forget this mail and sorry
| for the inconvenience.
|
| So with my version of Gold (the last)
| "
|
| BOOT>si::*gcl-extra-version*
|
| 8
|
| ~> it's gcl-2.6.8
|
| The output of « "NAG link" and then on "Browser pages for individual
| routines" » is
|
| There is no constructor matching pattern "Nag*"

I can reproduce that behaviour with the build-improvement branch (I'm
using system-installed GCL-2.6.7). This is on i686-suse-linux.
It would seem like that is not windows-specific issue then.

| I have this output with Axiom Version: Axiom 3.0 Beta (February 2005)
| too. It comes from a "Debian stable" package (with a little modification
| (see the end of http://wiki.axiom-developer.org/AxiomBinaries)). Camm
| can you look at this issue (forget the wiki bug), I did not report this
| as a bug on the BTS, it seems to me that I'm alone. I can report it if
| you can reproduce it.
|
|
| Greg
|
| PS : I'm really tired it's 2:18 in France, if this is not understandable
| ask me I will try to elaborate tomorrow.

I can understand what it is like. When I was in France [and young :-)]
I tend to work very late, almost in the central timezone. Now that
I'm in central timezone, I feel like I work in western Europe
timezone, except when I don't because of daytime job :-)

-- Gaby
Vanuxem Grégory
2006-10-14 00:53:56 UTC
Permalink
Post by Gabriel Dos Reis
| >
| > | >
| > | >
| > | > Is that reproducible with silver?
| > | >
| > |
| > | Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| > | went away.
| >
| > Interesting.
| >
| > We have a case to investigate. I seem to remember, but I'm not sure,
| > that the socket interface may have changed from 2.6.7 to 2.6.8pre.
|
| First, do you have installed (make install) Axiom ?
yes -- I always use axiom.build-improvements that way :-)
| If no (or may be
| yes, I have never tested), there are two files named util.ht in the
| sources, Tim is working on them, try the twos (try the other one i.e.
| copy it to /mnt/something*, the diff and find programs will help you).
| Personally I don't remember which I use but not the "regular one" since
| I do not install Axiom. If this mail is unrelated to your issue after
| these tests or if you do not understand it, forget this mail and sorry
| for the inconvenience.
|
| So with my version of Gold (the last)
| "
|
| BOOT>si::*gcl-extra-version*
|
| 8
|
| ~> it's gcl-2.6.8
|
| The output of « "NAG link" and then on "Browser pages for individual
| routines" » is
|
| There is no constructor matching pattern "Nag*"
I can reproduce that behaviour with the build-improvement branch (I'm
using system-installed GCL-2.6.7). This is on i686-suse-linux.
It would seem like that is not windows-specific issue then.
| I have this output with Axiom Version: Axiom 3.0 Beta (February 2005)
| too. It comes from a "Debian stable" package (with a little modification
| (see the end of http://wiki.axiom-developer.org/AxiomBinaries)).
Hmm... I forgot to say that this version use GCL-2.6.6 (this was the
main purpose of my email):

***@ellipse:~$ axiom
GCL (GNU Common Lisp) 2.6.6 CLtL1 Jan 20 2005 00:03:46
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License: GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
AXIOM Computer Algebra System
Version: Axiom 3.0 Beta (February 2005)
Timestamp: Monday March 21, 2005 at 01:36:09




Greg
Waldek Hebisch
2006-10-14 00:34:37 UTC
Permalink
Post by Gabriel Dos Reis
| >
| >
| > Is that reproducible with silver?
| >
|
| Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| went away.
Interesting.
We have a case to investigate. I seem to remember, but I'm not sure,
that the socket interface may have changed from 2.6.7 to 2.6.8pre.
Bill?
As I wrote in original message the problem seem to be with passing
strings from Lisp to C functions. AFAICS sockio.lisp.pamphlet
assumes that it will pass pointer to original string buffer. But
apparently gcl passes pointer to a copy. Code to pass strings
(in lsp/gcl-2.6.8pre/o/cmpaux.c) changed slightly compared to
gcl-2.6.7, so maybe this is the reason.
--
Waldek Hebisch
***@math.uni.wroc.pl
Gabriel Dos Reis
2006-10-14 00:55:23 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| >
| > | Gabriel Dos Reis wrote:
| > | > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| > | >
| > | > | Playing with build-improvements I have noticed that hypertex is broken:
| > | >
| > | > Is that reproducible with silver?
| > | >
| > |
| > | Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| > | went away.
| >
| > Interesting.
| >
| > We have a case to investigate. I seem to remember, but I'm not sure,
| > that the socket interface may have changed from 2.6.7 to 2.6.8pre.
| > Bill?
|
| As I wrote in original message the problem seem to be with passing
| strings from Lisp to C functions. AFAICS sockio.lisp.pamphlet
| assumes that it will pass pointer to original string buffer. But
| apparently gcl passes pointer to a copy. Code to pass strings
| (in lsp/gcl-2.6.8pre/o/cmpaux.c) changed slightly compared to
| gcl-2.6.7, so maybe this is the reason.

I understand your description. I was trying to relate it to a much
bigger picture. I was asking Bill whether that is the incompatible
changes in GCL-2.6.8pre's socket stuff he told me about at the last Axiom
conference call.

It is important that as we work on "fixing" things, we do clearly
understand what we are fixing.

-- Gaby
Waldek Hebisch
2006-10-14 01:09:41 UTC
Permalink
[ Charset ISO-8859-1 unsupported, converting... ]
Post by Vanuxem Grégory
Post by Gabriel Dos Reis
| >
| >
| > Is that reproducible with silver?
| >
|
| Probably no: when I tried build-improvements with gcl-2.6.7 the problem
| went away.
Interesting.
We have a case to investigate. I seem to remember, but I'm not sure,
that the socket interface may have changed from 2.6.7 to 2.6.8pre.
First, do you have installed (make install) Axiom ? If no (or may be
yes, I have never tested), there are two files named util.ht in the
sources, Tim is working on them, try the twos (try the other one i.e.
copy it to /mnt/something*, the diff and find programs will help you).
Personally I don't remember which I use but not the "regular one" since
I do not install Axiom. If this mail is unrelated to your issue after
these tests or if you do not understand it, forget this mail and sorry
for the inconvenience.
So with my version of Gold (the last)
"
BOOT>si::*gcl-extra-version*
8
~> it's gcl-2.6.8
The output of ? "NAG link" and then on "Browser pages for individual
routines" ? is
There is no constructor matching pattern "Nag*"
This I consider as "normal" output. For me the browser just freezes.
I should add that I chose this page because it is the shortest path
to freeze the browser -- I can freeze it an another pages (which
in earlier versions work fine).

Investigating further I have noticed that gcl-2.6.8pre2 in silver is
different then gcl-2.6.8pre in build improvements. In particular
the function object_to_string in gcl-2.6.8pre2/o/cmpaux.c is like
gcl-2.6.7 while the version in gcl-2.6.8pre is different.
--
Waldek Hebisch
***@math.uni.wroc.pl
Vanuxem Grégory
2006-10-14 10:53:09 UTC
Permalink
Le samedi 14 octobre 2006 à 03:09 +0200, Waldek Hebisch a écrit :
[...]
Post by Waldek Hebisch
Post by Vanuxem Grégory
The output of ? "NAG link" and then on "Browser pages for individual
routines" ? is
There is no constructor matching pattern "Nag*"
This I consider as "normal" output. For me the browser just freezes.
I should add that I chose this page because it is the shortest path
to freeze the browser -- I can freeze it an another pages (which
in earlier versions work fine).
Investigating further I have noticed that gcl-2.6.8pre2 in silver is
different then gcl-2.6.8pre in build improvements. In particular
the function object_to_string in gcl-2.6.8pre2/o/cmpaux.c is like
gcl-2.6.7 while the version in gcl-2.6.8pre is different.
Exactly, a typo (& instead of %), no ? I think Camm read this mailing
list but writing directly to him would be a good idea.

Greg
Waldek Hebisch
2006-10-14 15:47:22 UTC
Permalink
Post by Vanuxem Grégory
Post by Waldek Hebisch
Investigating further I have noticed that gcl-2.6.8pre2 in silver is
different then gcl-2.6.8pre in build improvements. In particular
the function object_to_string in gcl-2.6.8pre2/o/cmpaux.c is like
gcl-2.6.7 while the version in gcl-2.6.8pre is different.
Exactly, a typo (& instead of %), no ? I think Camm read this mailing
list but writing directly to him would be a good idea.
To summarize: both gcl-2.6.7 and gcl-2.6.8pre2 pass address of actual
data (which is what Axiom expects), gcl-2.6.8pre in build-improvements
copies strings and passes address of the copy (which breaks hypertex
interface). When I change object_to_string in gcl-2.6.8pre to match
that of gcl-2.6.7 (or gcl-2.6.8pre2) hypertex works.

Since gcl-2.6.8pre2 seem to be latest gcl version Camm can probably
just do nothing (just remember so that problem is not re-introduced
later).

Concerning build-improvements: I can use gcl-2.6.7 when testing hypertex.
--
Waldek Hebisch
***@math.uni.wroc.pl
Gabriel Dos Reis
2006-10-14 16:23:29 UTC
Permalink
Waldek Hebisch <***@math.uni.wroc.pl> writes:

| > Le samedi 14 octobre 2006 ? 03:09 +0200, Waldek Hebisch a écrit :
| > > Investigating further I have noticed that gcl-2.6.8pre2 in silver is
| > > different then gcl-2.6.8pre in build improvements. In particular
| > > the function object_to_string in gcl-2.6.8pre2/o/cmpaux.c is like
| > > gcl-2.6.7 while the version in gcl-2.6.8pre is different.
| >
| > Exactly, a typo (& instead of %), no ? I think Camm read this mailing
| > list but writing directly to him would be a good idea.
| >
|
| To summarize: both gcl-2.6.7 and gcl-2.6.8pre2 pass address of actual
| data (which is what Axiom expects), gcl-2.6.8pre in build-improvements
| copies strings and passes address of the copy (which breaks hypertex
| interface). When I change object_to_string in gcl-2.6.8pre to match
| that of gcl-2.6.7 (or gcl-2.6.8pre2) hypertex works.
|
| Since gcl-2.6.8pre2 seem to be latest gcl version Camm can probably
| just do nothing (just remember so that problem is not re-introduced
| later).

That is interesting.
gcl-2.6.8pre in build-improvements was updated on September 17, 2006
to reflect what was in GCL cvs tree at the time.

I don't know when gcl-2.6.8pre2 was made.

-- Gaby
root
2006-10-14 16:41:11 UTC
Permalink
Post by Gabriel Dos Reis
I don't know when gcl-2.6.8pre2 was made.
from CHANGELOG in Gold:

20060821 tpd lsp/Makefile add gcl-2.6.8pre2
Gabriel Dos Reis
2006-10-14 18:28:13 UTC
Permalink
root <***@axiom-developer.org> writes:

| > I don't know when gcl-2.6.8pre2 was made.
|
| from CHANGELOG in Gold:
|
| 20060821 tpd lsp/Makefile add gcl-2.6.8pre2

Aha; so the faulty change in gcl-2.6.8pre is much more recent.
Thanks!

-- Gaby
Vanuxem Grégory
2006-10-14 21:48:59 UTC
Permalink
Post by Waldek Hebisch
Post by Vanuxem Grégory
Post by Waldek Hebisch
Investigating further I have noticed that gcl-2.6.8pre2 in silver is
different then gcl-2.6.8pre in build improvements. In particular
the function object_to_string in gcl-2.6.8pre2/o/cmpaux.c is like
gcl-2.6.7 while the version in gcl-2.6.8pre is different.
Exactly, a typo (& instead of %), no ? I think Camm read this mailing
list but writing directly to him would be a good idea.
To summarize: both gcl-2.6.7 and gcl-2.6.8pre2 pass address of actual
data (which is what Axiom expects), gcl-2.6.8pre in build-improvements
copies strings and passes address of the copy (which breaks hypertex
interface). When I change object_to_string in gcl-2.6.8pre to match
that of gcl-2.6.7 (or gcl-2.6.8pre2) hypertex works.
Since gcl-2.6.8pre2 seem to be latest gcl version Camm can probably
just do nothing (just remember so that problem is not re-introduced
later).
No, GCL included in build-improvements is more recent than
gcl-2.6.8pre2. The code that you describe is in gcl-2.6.8pre just
checked out today and in gcl-2.7 (cvs HEAD).

Greg
Camm Maguire
2006-10-15 01:23:17 UTC
Permalink
Greetings, and thanks for the report! Typeo should be gone now in
both branches.

Just wanted to note that the only way you can guarantee that you don't
get a copy out of object_to_string is to write a null character at the
end of the lisp string body yourself, as there is extra room only in
special circumstances.

Take care,
Post by Waldek Hebisch
Post by Vanuxem Grégory
Post by Waldek Hebisch
Investigating further I have noticed that gcl-2.6.8pre2 in silver is
different then gcl-2.6.8pre in build improvements. In particular
the function object_to_string in gcl-2.6.8pre2/o/cmpaux.c is like
gcl-2.6.7 while the version in gcl-2.6.8pre is different.
Exactly, a typo (& instead of %), no ? I think Camm read this mailing
list but writing directly to him would be a good idea.
To summarize: both gcl-2.6.7 and gcl-2.6.8pre2 pass address of actual
data (which is what Axiom expects), gcl-2.6.8pre in build-improvements
copies strings and passes address of the copy (which breaks hypertex
interface). When I change object_to_string in gcl-2.6.8pre to match
that of gcl-2.6.7 (or gcl-2.6.8pre2) hypertex works.
Since gcl-2.6.8pre2 seem to be latest gcl version Camm can probably
just do nothing (just remember so that problem is not re-introduced
later).
Concerning build-improvements: I can use gcl-2.6.7 when testing hypertex.
--
Waldek Hebisch
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Gabriel Dos Reis
2006-10-16 00:32:24 UTC
Permalink
Camm Maguire <***@enhanced.com> writes:

| Greetings, and thanks for the report! Typeo should be gone now in
| both branches.

Great! I'll update build-improvements later, assuming I still have
connectivity.

-- Gaby
Bill Page
2006-10-14 16:12:42 UTC
Permalink
Post by Gabriel Dos Reis
| >
| > | >
| > | > | Playing with build-improvements I have noticed that
| > | >
| > | > Is that reproducible with silver?
| > | >
| > |
| > | Probably no: when I tried build-improvements with
| > | gcl-2.6.7 the problem went away.
| >
| > Interesting.
| >
| > We have a case to investigate. I seem to remember, but
| > I'm not sure, that the socket interface may have changed
| > from 2.6.7 to 2.6.8pre. Bill?
The change in the socket interface is due only to the better
treatment of data types in 2.6.8pre and should not be the
source of any functional changes.
Post by Gabriel Dos Reis
|
| As I wrote in original message the problem seem to be with
| passing strings from Lisp to C functions. AFAICS sockio.lisp.
| pamphlet assumes that it will pass pointer to original string
| buffer. But apparently gcl passes pointer to a copy. Code to
| pass strings (in lsp/gcl-2.6.8pre/o/cmpaux.c) changed slightly
| compared to gcl-2.6.7, so maybe this is the reason.
I think the change has been quite substantial. See the diff output
below.
Post by Gabriel Dos Reis
I understand your description. I was trying to relate it to a
much bigger picture. I was asking Bill whether that is the
incompatible changes in GCL-2.6.8pre's socket stuff he told me
about at the last Axiom conference call.
No.
Post by Gabriel Dos Reis
It is important that as we work on "fixing" things, we do
clearly understand what we are fixing.
I agree. I think this thread could benefit by a more explicit
reference to the source code. See below.
Post by Gabriel Dos Reis
[...]
Post by Waldek Hebisch
Post by Vanuxem Grégory
The output of ? "NAG link" and then on "Browser pages for
individualroutines" ? is
There is no constructor matching pattern "Nag*"
This I consider as "normal" output. For me the browser
just freezes. I should add that I chose this page because it
is the shortest path to freeze the browser -- I can freeze it
an another pages (which in earlier versions work fine).
Investigating further I have noticed that gcl-2.6.8pre2 in
silver is different then gcl-2.6.8pre in build improvements.
In particular the function object_to_string in gcl-2.6.8pre2/o/
cmpaux.c is like gcl-2.6.7 while the version in gcl-2.6.8pre
is different.
Exactly, a typo (& instead of %), no ? I think Camm read this
mailing list but writing directly to him would be a good idea.
I agree. The following line in the diff output below

+ if (x->st.st_dim == leng && leng & sizeof(object)

should actually read

+ if (x->st.st_dim == leng && leng % sizeof(object)

Regards,
Bill Page.

Note: axiom--main--1 is "Axiom Gold".

$ diff -au ~/repository/axiom--main--1/lsp/gcl-2.6.8pre/o/cmpaux.c \
~/axiom.silver/build-improvements/lsp/gcl-2.6.8pre/o/cmpaux.c
--- /home/page/repository/axiom--main--1/lsp/gcl-2.6.8pre/o/cmpaux.c
2005-12-01 16:18:23.000000000 -0600
+++ /home/page/axiom.silver/build-improvements/lsp/gcl-2.6.8pre/o/cmpaux.c
2006-08-25 14:08:41.000000000 -0500
@@ -34,6 +34,8 @@
#include "include.h"
#define dcheck_type(a,b) check_type(a,b)

+#include "page.h"
+
DEFUNO_NEW("SPECIALP",object,fSspecialp,SI
,1,1,NONE,OO,OO,OO,OO,void,siLspecialp,(object sym),"")
{
@@ -205,6 +207,31 @@
return(i);
}

+fixnum
+object_to_fixnum(object x)
+{
+ fixnum i=0;
+
+ switch (type_of(x)) {
+ case t_character:
+ i = char_code(x); break;
+ case t_fixnum:
+ i = fix(x); break;
+ case t_bignum:
+ i = number_to_double(x);
+ break;
+ case t_ratio:
+ i = number_to_double(x); break;
+ case t_shortfloat:
+ i = sf(x); break;
+ case t_longfloat:
+ i = lf(x); break;
+ default:
+ FEerror("~S cannot be coerce to a C int.", 1, x);
+ }
+ return(i);
+}
+
float
object_to_float(object x)
{
@@ -256,26 +283,31 @@
have a null character in the fillpointer position. */

char *
-object_to_string(object x)
-{ unsigned int leng;
+object_to_string(object x) {
+
+ unsigned int leng;
+ long np;
+ char *res;
+
if (type_of(x)!=t_string) FEwrong_type_argument(sLstring,x);
leng= x->st.st_fillp;
/* user has thoughtfully provided a null terminated string ! */
- if (leng > 0 && leng < x->st.st_dim && x->st.st_self[leng]==0)
+ if (leng > 0 && leng < x->st.st_dim && x->st.st_self[leng]==0)
return x->st.st_self;
- if (x->st.st_dim == leng
- && ( leng % sizeof(object))
- )
- { x->st.st_self[leng] = 0;
- return x->st.st_self;
- }
- else
- {char *res=malloc(leng+1);
- bcopy(x->st.st_self,res,leng);
- res[leng]=0;
- return res;
- }}

+ np=page(x->st.st_self);
+ if (x->st.st_dim == leng && leng & sizeof(object)
+ && np<MAXPAGE && (type_map[np]==t_relocatable ||
type_map[np]==t_contiguous)) {
+ x->st.st_self[leng] = 0;
+ return x->st.st_self;
+ }
+
+ res=malloc(leng+1);
+ bcopy(x->st.st_self,res,leng);
+ res[leng]=0;
+ return res;
+
+}

/* typedef int (*FUNC)(); */

[***@axiom-developer o]$
Gabriel Dos Reis
2006-10-14 16:37:00 UTC
Permalink
"Bill Page" <***@synthesis.anikast.ca> writes:

| On October 13, 2006 8:55 PM Gabriel Dos Reis wrote:
| >
| > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| >
| > | Gabriel Dos Reis wrote:
| > | > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| > | >
| > | > | Gabriel Dos Reis wrote:
| > | > | > Waldek Hebisch <***@math.uni.wroc.pl> writes:
| > | > | >
| > | > | > | Playing with build-improvements I have noticed that
| > | > | > | hypertex is broken:
| > | > | >
| > | > | > Is that reproducible with silver?
| > | > | >
| > | > |
| > | > | Probably no: when I tried build-improvements with
| > | > | gcl-2.6.7 the problem went away.
| > | >
| > | > Interesting.
| > | >
| > | > We have a case to investigate. I seem to remember, but
| > | > I'm not sure, that the socket interface may have changed
| > | > from 2.6.7 to 2.6.8pre. Bill?
|
| The change in the socket interface is due only to the better
| treatment of data types in 2.6.8pre and should not be the
| source of any functional changes.

That is good to know; thanks!

[...]

| > It is important that as we work on "fixing" things, we do
| > clearly understand what we are fixing.
| >
|
| I agree. I think this thread could benefit by a more explicit
| reference to the source code. See below.

[...]

| >
| > Exactly, a typo (& instead of %), no ? I think Camm read this
| > mailing list but writing directly to him would be a good idea.
| >
|
| I agree. The following line in the diff output below
|
| + if (x->st.st_dim == leng && leng & sizeof(object)
|
| should actually read
|
| + if (x->st.st_dim == leng && leng % sizeof(object)

I just updated my version of gcl-2.6.8pre and saw that the typo is
still there. I'll check in a fix later, unless Camm beats me at it.

-- Gaby
root
2006-10-14 17:51:44 UTC
Permalink
Post by Gabriel Dos Reis
| >
| > Exactly, a typo (& instead of %), no ? I think Camm read this
| > mailing list but writing directly to him would be a good idea.
| >
|
| I agree. The following line in the diff output below
|
| + if (x->st.st_dim == leng && leng & sizeof(object)
|
| should actually read
|
| + if (x->st.st_dim == leng && leng % sizeof(object)
I just updated my version of gcl-2.6.8pre and saw that the typo is
still there. I'll check in a fix later, unless Camm beats me at it.
I checked Gold's version of gcl-2.6.7, gcl-2.6.8pre, and gcl-2.6.8pre2
and this line is the same in all three versions.

I'm not sure what version of gcl-2.6.8pre you're using.

t
Gabriel Dos Reis
2006-10-14 18:38:26 UTC
Permalink
root <***@axiom-developer.org> writes:

| > | >
| > | > Exactly, a typo (& instead of %), no ? I think Camm read this
| > | > mailing list but writing directly to him would be a good idea.
| > | >
| > |
| > | I agree. The following line in the diff output below
| > |
| > | + if (x->st.st_dim == leng && leng & sizeof(object)
| > |
| > | should actually read
| > |
| > | + if (x->st.st_dim == leng && leng % sizeof(object)
| >
| > I just updated my version of gcl-2.6.8pre and saw that the typo is
| > still there. I'll check in a fix later, unless Camm beats me at it.
|
| I checked Gold's version of gcl-2.6.7, gcl-2.6.8pre, and gcl-2.6.8pre2
| and this line is the same in all three versions.
|
| I'm not sure what version of gcl-2.6.8pre you're using.

GCL CVS. (Camm kindly welcomed me on te GCL project.)
So I have (separate) copies, up-to-date, of gcl-2.6.8pre, gcl-2.7
(trunk).

-- Gaby
Waldek Hebisch
2006-10-14 21:57:37 UTC
Permalink
Post by Vanuxem Grégory
Post by Waldek Hebisch
Since gcl-2.6.8pre2 seem to be latest gcl version Camm can probably
just do nothing (just remember so that problem is not re-introduced
later).
No, GCL included in build-improvements is more recent than
gcl-2.6.8pre2. The code that you describe is in gcl-2.6.8pre just
checked out today and in gcl-2.7 (cvs HEAD).
Yes, the names fooled me.
--
Waldek Hebisch
***@math.uni.wroc.pl
root
2006-10-14 22:06:37 UTC
Permalink
Post by Waldek Hebisch
Post by Vanuxem Grégory
Post by Waldek Hebisch
Since gcl-2.6.8pre2 seem to be latest gcl version Camm can probably
just do nothing (just remember so that problem is not re-introduced
later).
No, GCL included in build-improvements is more recent than
gcl-2.6.8pre2. The code that you describe is in gcl-2.6.8pre just
checked out today and in gcl-2.7 (cvs HEAD).
Yes, the names fooled me.
The problem is that Axiom is running fairly close to the CVS HEAD
version of GCL but there is no way to distinguish exactly which
checkout will work on which platform and contains which errors.

This problem is highlighted on the Fedora 5 build which will not
run on gcl-2.6.8pre2 and requires a prior version. Since I was
unable to distinguish the two checkouts automatically there are
two snapshots in the zips directory.

t
Page, Bill
2006-10-18 03:23:38 UTC
Permalink
Camm,

I have succeeded in compiling gcl-2.6.8pre on MAC OSX 10.2 on the
SourceForge compile farm 'ppc-osx3' server, however some patches
were necessary. This machine has Xcode installed by not Fink.

First, I checked out gcl-2.6.8pre from cvs on October 15, 2006,
created a tarball and scp'd it and the standard gnu gettext-0.15
and sed-4.1.4 tarballs to my home directory on SourceForge.

Next I compiled and installed gettext and sed with
--prefix=/home/users/b/bi/billpage/osx
creating the ~/osx/bin and ~/osx/lib directories. These are
apparently required to satisfy the gcl build dependencies on
OSX 10.2. (Note: A Fink installation might also have provided
these in the /sw directory.)

Then I added:

export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
export LIBRARY_PATH=/home/users/b/bi/billpage/osx/lib:$LIBRARY_PATH
export CPPFLAGS="-no-cpp-precomp"
cd osx

to ~/.profile so that after re-login the environment was set
appropriately.

I untarred gcl into the osx directory creating ~/osx/gcl-2.6.8pre
Then I applied the following patches (most of which have been
previously reported on the gcl email list by other people):

------------------------
ppc-osx3:~/osx billpage$ diff -Naur old/gcl* new/gcl*

This patch required so libintl is found in $LIBRARY_PATH.

diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.defs
new/gcl-2.6.8pre/h/powerpc-macosx.defs
--- old/gcl-2.6.8pre/h/powerpc-macosx.defs Thu Jul 15 09:28:43 2004
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15 22:07:45 2006
@@ -6,7 +6,7 @@

# Set this to avoid warnings when linking against libncurses.
# This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` /sw/lib/libintl.dylib
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl

# Set this for the linker to operate correctly.
MACOSX_DEPLOYMENT_TARGET = 10.2
@@ -32,4 +32,4 @@
# This appears to be no longer necessary on Panther.
ARRS = libtool -static -o

-FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
\ No newline at end of file
+FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`

This patch is required to define sbrk.

diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.h
new/gcl-2.6.8pre/h/powerpc-macosx.h
--- old/gcl-2.6.8pre/h/powerpc-macosx.h Thu Dec 8 17:31:25 2005
+++ new/gcl-2.6.8pre/h/powerpc-macosx.h Sun Oct 15 21:32:23 2006
@@ -38,8 +38,9 @@
#undef SET_REAL_MAXPAGE
#define SET_REAL_MAXPAGE { my_sbrk(0); real_maxpage = (int)
mach_maplimit/PAGESIZE; }

-#define sbrk my_sbrk
+#include <unistd.h> /* to get sbrk defined */
extern void *my_sbrk(int incr);
+#define sbrk my_sbrk


/** (si::save-system "...") a.k.a. unexec implementation */

This patch is required to remove functions symbols from plt.

diff -Naur old/gcl-2.6.8pre/o/makefile new/gcl-2.6.8pre/o/makefile
--- old/gcl-2.6.8pre/o/makefile Fri Sep 15 10:45:18 2006
+++ new/gcl-2.6.8pre/o/makefile Mon Oct 16 22:03:52 2006
@@ -154,7 +154,7 @@
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
- grep -v '[^ \t_]_' |\
+ grep -v 'restFP' | grep -v 'saveFP' | grep -v
'[^ \t_]_' |\
$(AWK) '{A[++k]=$$0} END {for (i=1;i<=k;i++) \
printf("MY_PLT(%s)%s\n",A[i],i==k ? "" :
",");}' >$@

This patch is required to find malloc.h on some OSX machines.

diff -Naur old/gcl-2.6.8pre/o/unexmacosx.c
new/gcl-2.6.8pre/o/unexmacosx.c
--- old/gcl-2.6.8pre/o/unexmacosx.c Thu Dec 15 10:48:43 2005
+++ new/gcl-2.6.8pre/o/unexmacosx.c Tue Oct 17 18:55:04 2006
@@ -124,7 +124,13 @@
#endif
#include <mach-o/nlist.h>
#include <mach-o/getsect.h>
+/* not <sys/malloc.h> */
+/* not <malloc.h> */
+#if defined (HAVE_MALLOC_MALLOC_H)
#include <malloc/malloc.h>
+#else
+#include <objc/malloc.h>
+#endif

#include <sys/mman.h>

ppc-osx3:~/osx billpage$

------------------------

Finally I built gcl with the following commands:

./configure --prefix=/home/users/b/bi/billpage/osx \
--disable-tkconfig --disable-statsysbfd --enable-locbfd
make
make install

---------

The resulting gcl binary (unixport/saved_gcl) in available here:

http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin

I would be very happy if anyone with a MAC OSX machine would try
this version of gcl on their systems and let me know of any
problems.

I am currently working on completing the Axiom build based on the
new build-improvements branch.

Regards,
Bill Page.
root
2006-10-18 05:59:35 UTC
Permalink
Bill,

Are you able to do save-system in gcl on OSX?
That's my current limitation.

t
root
2006-10-18 06:05:11 UTC
Permalink
i have gcl-2.6.8pre2 running but cannot do save-system
i have rebuilt the makefiles so the bootsys and depsys
steps are run in a clean gcl rather than saving an image.
i'm working on getting interpsys to build.
a gcl version that can do save-system would short-circuit the effort
and allow me to get the system running.

i read your patches and it appears that at least one of them might
solve the problem.

unfortunately i have a 3 day meeting in work starting this morning
but i'll try to get your patches applied by this weekend.

t
Camm Maguire
2006-10-18 15:24:38 UTC
Permalink
Greetings! And thanks so much for looking into this! Comments
below.
Post by Page, Bill
Camm,
I have succeeded in compiling gcl-2.6.8pre on MAC OSX 10.2 on the
SourceForge compile farm 'ppc-osx3' server, however some patches
were necessary. This machine has Xcode installed by not Fink.
First, I checked out gcl-2.6.8pre from cvs on October 15, 2006,
created a tarball and scp'd it and the standard gnu gettext-0.15
and sed-4.1.4 tarballs to my home directory on SourceForge.
Next I compiled and installed gettext and sed with
--prefix=/home/users/b/bi/billpage/osx
creating the ~/osx/bin and ~/osx/lib directories. These are
apparently required to satisfy the gcl build dependencies on
OSX 10.2. (Note: A Fink installation might also have provided
these in the /sw directory.)
I thought that gettext was no longer required, as it was included in
the local bfd build (from configure.in:)

cd binutils/bfd && chmod +x configure && ./configure --with-included-gettext && cd ../..

We do need sed. I guess OSX has none, or it is incompatible?

Is Fink so non-standard that it must be avoided? What is the
canonical way to get gnu software on OSX?
Post by Page, Bill
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
export LIBRARY_PATH=/home/users/b/bi/billpage/osx/lib:$LIBRARY_PATH
export CPPFLAGS="-no-cpp-precomp"
cd osx
to ~/.profile so that after re-login the environment was set
appropriately.
I untarred gcl into the osx directory creating ~/osx/gcl-2.6.8pre
Then I applied the following patches (most of which have been
------------------------
ppc-osx3:~/osx billpage$ diff -Naur old/gcl* new/gcl*
This patch required so libintl is found in $LIBRARY_PATH.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.defs
new/gcl-2.6.8pre/h/powerpc-macosx.defs
--- old/gcl-2.6.8pre/h/powerpc-macosx.defs Thu Jul 15 09:28:43 2004
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15 22:07:45 2006
@@ -6,7 +6,7 @@
# Set this to avoid warnings when linking against libncurses.
# This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` /sw/lib/libintl.dylib
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
# Set this for the linker to operate correctly.
MACOSX_DEPLOYMENT_TARGET = 10.2
@@ -32,4 +32,4 @@
# This appears to be no longer necessary on Panther.
ARRS = libtool -static -o
-FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
\ No newline at end of file
+FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
OK, this is going in, but I think we can lose the -lintl too. Anyone
want to try to verify?
Post by Page, Bill
This patch is required to define sbrk.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.h
new/gcl-2.6.8pre/h/powerpc-macosx.h
--- old/gcl-2.6.8pre/h/powerpc-macosx.h Thu Dec 8 17:31:25 2005
+++ new/gcl-2.6.8pre/h/powerpc-macosx.h Sun Oct 15 21:32:23 2006
@@ -38,8 +38,9 @@
#undef SET_REAL_MAXPAGE
#define SET_REAL_MAXPAGE { my_sbrk(0); real_maxpage = (int)
mach_maplimit/PAGESIZE; }
-#define sbrk my_sbrk
+#include <unistd.h> /* to get sbrk defined */
extern void *my_sbrk(int incr);
+#define sbrk my_sbrk
/** (si::save-system "...") a.k.a. unexec implementation */
I don't get this one, as we emulate sbrk here. Where is the system
definition required?
Post by Page, Bill
This patch is required to remove functions symbols from plt.
diff -Naur old/gcl-2.6.8pre/o/makefile new/gcl-2.6.8pre/o/makefile
--- old/gcl-2.6.8pre/o/makefile Fri Sep 15 10:45:18 2006
+++ new/gcl-2.6.8pre/o/makefile Mon Oct 16 22:03:52 2006
@@ -154,7 +154,7 @@
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
- grep -v '[^ \t_]_' |\
+ grep -v 'restFP' | grep -v 'saveFP' | grep -v
'[^ \t_]_' |\
$(AWK) '{A[++k]=$$0} END {for (i=1;i<=k;i++) \
OK. This is quite ugly, but its a hack to begin with. Suggestions
most welcome.
Post by Page, Bill
This patch is required to find malloc.h on some OSX machines.
diff -Naur old/gcl-2.6.8pre/o/unexmacosx.c
new/gcl-2.6.8pre/o/unexmacosx.c
--- old/gcl-2.6.8pre/o/unexmacosx.c Thu Dec 15 10:48:43 2005
+++ new/gcl-2.6.8pre/o/unexmacosx.c Tue Oct 17 18:55:04 2006
@@ -124,7 +124,13 @@
#endif
#include <mach-o/nlist.h>
#include <mach-o/getsect.h>
+/* not <sys/malloc.h> */
+/* not <malloc.h> */
+#if defined (HAVE_MALLOC_MALLOC_H)
#include <malloc/malloc.h>
+#else
+#include <objc/malloc.h>
+#endif
#include <sys/mman.h>
OK, I take it you are using objc/malloc.h. We need configure code to
look for this, and bomb if it cannot find one, just on macosx. I'll
take a stab unless someone else wants to.

May I suggest we also lose the diagnostic output on save-system on
this platform?

Thanks again! Will post when something is checked in.

BTW, I'm pushing 2.6.8 (in the guise of 2.6.7) and all the apps
through the Debian autobuilder system before releasing 2.6.8. Please
let me know of any other 2.6.8 issues you may be encountering in your
axiom work asap. Bug fix only at this point, of course.

Take care,
Post by Page, Bill
ppc-osx3:~/osx billpage$
------------------------
./configure --prefix=/home/users/b/bi/billpage/osx \
--disable-tkconfig --disable-statsysbfd --enable-locbfd
make
make install
---------
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
I would be very happy if anyone with a MAC OSX machine would try
this version of gcl on their systems and let me know of any
problems.
I am currently working on completing the Axiom build based on the
new build-improvements branch.
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire
2006-10-18 17:24:39 UTC
Permalink
Greetings! OK I think this is in now on branches 2.6.8 and head.
Please let me know if problems persist.

Take care,
Post by Page, Bill
Camm,
I have succeeded in compiling gcl-2.6.8pre on MAC OSX 10.2 on the
SourceForge compile farm 'ppc-osx3' server, however some patches
were necessary. This machine has Xcode installed by not Fink.
First, I checked out gcl-2.6.8pre from cvs on October 15, 2006,
created a tarball and scp'd it and the standard gnu gettext-0.15
and sed-4.1.4 tarballs to my home directory on SourceForge.
Next I compiled and installed gettext and sed with
--prefix=/home/users/b/bi/billpage/osx
creating the ~/osx/bin and ~/osx/lib directories. These are
apparently required to satisfy the gcl build dependencies on
OSX 10.2. (Note: A Fink installation might also have provided
these in the /sw directory.)
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
export LIBRARY_PATH=/home/users/b/bi/billpage/osx/lib:$LIBRARY_PATH
export CPPFLAGS="-no-cpp-precomp"
cd osx
to ~/.profile so that after re-login the environment was set
appropriately.
I untarred gcl into the osx directory creating ~/osx/gcl-2.6.8pre
Then I applied the following patches (most of which have been
------------------------
ppc-osx3:~/osx billpage$ diff -Naur old/gcl* new/gcl*
This patch required so libintl is found in $LIBRARY_PATH.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.defs
new/gcl-2.6.8pre/h/powerpc-macosx.defs
--- old/gcl-2.6.8pre/h/powerpc-macosx.defs Thu Jul 15 09:28:43 2004
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15 22:07:45 2006
@@ -6,7 +6,7 @@
# Set this to avoid warnings when linking against libncurses.
# This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` /sw/lib/libintl.dylib
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
# Set this for the linker to operate correctly.
MACOSX_DEPLOYMENT_TARGET = 10.2
@@ -32,4 +32,4 @@
# This appears to be no longer necessary on Panther.
ARRS = libtool -static -o
-FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
\ No newline at end of file
+FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
This patch is required to define sbrk.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.h
new/gcl-2.6.8pre/h/powerpc-macosx.h
--- old/gcl-2.6.8pre/h/powerpc-macosx.h Thu Dec 8 17:31:25 2005
+++ new/gcl-2.6.8pre/h/powerpc-macosx.h Sun Oct 15 21:32:23 2006
@@ -38,8 +38,9 @@
#undef SET_REAL_MAXPAGE
#define SET_REAL_MAXPAGE { my_sbrk(0); real_maxpage = (int)
mach_maplimit/PAGESIZE; }
-#define sbrk my_sbrk
+#include <unistd.h> /* to get sbrk defined */
extern void *my_sbrk(int incr);
+#define sbrk my_sbrk
/** (si::save-system "...") a.k.a. unexec implementation */
This patch is required to remove functions symbols from plt.
diff -Naur old/gcl-2.6.8pre/o/makefile new/gcl-2.6.8pre/o/makefile
--- old/gcl-2.6.8pre/o/makefile Fri Sep 15 10:45:18 2006
+++ new/gcl-2.6.8pre/o/makefile Mon Oct 16 22:03:52 2006
@@ -154,7 +154,7 @@
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
- grep -v '[^ \t_]_' |\
+ grep -v 'restFP' | grep -v 'saveFP' | grep -v
'[^ \t_]_' |\
$(AWK) '{A[++k]=$$0} END {for (i=1;i<=k;i++) \
This patch is required to find malloc.h on some OSX machines.
diff -Naur old/gcl-2.6.8pre/o/unexmacosx.c
new/gcl-2.6.8pre/o/unexmacosx.c
--- old/gcl-2.6.8pre/o/unexmacosx.c Thu Dec 15 10:48:43 2005
+++ new/gcl-2.6.8pre/o/unexmacosx.c Tue Oct 17 18:55:04 2006
@@ -124,7 +124,13 @@
#endif
#include <mach-o/nlist.h>
#include <mach-o/getsect.h>
+/* not <sys/malloc.h> */
+/* not <malloc.h> */
+#if defined (HAVE_MALLOC_MALLOC_H)
#include <malloc/malloc.h>
+#else
+#include <objc/malloc.h>
+#endif
#include <sys/mman.h>
ppc-osx3:~/osx billpage$
------------------------
./configure --prefix=/home/users/b/bi/billpage/osx \
--disable-tkconfig --disable-statsysbfd --enable-locbfd
make
make install
---------
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
I would be very happy if anyone with a MAC OSX machine would try
this version of gcl on their systems and let me know of any
problems.
I am currently working on completing the Axiom build based on the
new build-improvements branch.
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Gabriel Dos Reis
2006-10-24 01:21:53 UTC
Permalink
Camm Maguire <***@enhanced.com> writes:

| Greetings! OK I think this is in now on branches 2.6.8 and head.
| Please let me know if problems persist.

Camm --

I just checked out GCL-2.6.8pre for build with Axiom.
The build appears to fail when "makeinfo" is not present in the build
environment.
[...]
(see the transcript file for additional information)
Output written on gcl-si.dvi (149 pages, 329240 bytes).
Transcript written on gcl-si.log.
makeinfo --html gcl-si.texi
make[3]: makeinfo: Command not found
make[3]: *** [gcl-si/index.html] Error 127
make[3]: Leaving directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
[...]

That behaviour breaks Axiom build. It is a regression from previous
versions.

-- Gaby
Camm Maguire
2006-10-24 15:00:58 UTC
Permalink
Greetings, and thanks!

Should we make makeinfo a build dependency of GCL? We cannot generate
any documentation without it. I.e. we can

1) silently skip documentation when makeinfo is absent

or

2) bomb if it is not found in configure.

Take care,
Post by Gabriel Dos Reis
| Greetings! OK I think this is in now on branches 2.6.8 and head.
| Please let me know if problems persist.
Camm --
I just checked out GCL-2.6.8pre for build with Axiom.
The build appears to fail when "makeinfo" is not present in the build
environment.
[...]
(see the transcript file for additional information)
Output written on gcl-si.dvi (149 pages, 329240 bytes).
Transcript written on gcl-si.log.
makeinfo --html gcl-si.texi
make[3]: makeinfo: Command not found
make[3]: *** [gcl-si/index.html] Error 127
make[3]: Leaving directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
[...]
That behaviour breaks Axiom build. It is a regression from previous
versions.
-- Gaby
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Gabriel Dos Reis
2006-10-24 16:40:50 UTC
Permalink
Camm Maguire <***@enhanced.com> writes:

| Greetings, and thanks!
|
| Should we make makeinfo a build dependency of GCL? We cannot generate
| any documentation without it. I.e. we can
|
| 1) silently skip documentation when makeinfo is absent
|
| or
|
| 2) bomb if it is not found in configure.

My preference would be for (1).
The reason is that there are packages, e.g. Axiom, that are only
interested in the GCL image not the documentation. They should be
given a chance to build and use the image.

-- Gaby
Camm Maguire
2006-10-25 22:43:40 UTC
Permalink
Greetings! OK, should be optional now. Please let me know if not.

Take care,
Post by Gabriel Dos Reis
| Greetings, and thanks!
|
| Should we make makeinfo a build dependency of GCL? We cannot generate
| any documentation without it. I.e. we can
|
| 1) silently skip documentation when makeinfo is absent
|
| or
|
| 2) bomb if it is not found in configure.
My preference would be for (1).
The reason is that there are packages, e.g. Axiom, that are only
interested in the GCL image not the documentation. They should be
given a chance to build and use the image.
-- Gaby
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Gabriel Dos Reis
2006-10-27 01:11:37 UTC
Permalink
Camm Maguire <***@enhanced.com> writes:

| Greetings! OK, should be optional now. Please let me know if not.

Camm --

Thanks for the quick fix.

Now, the build progressed further but still I hit a regression when I
try to install it in a specifc location (it worked with earlier versions):

make[4]: [gcl-si.info] Error 1 (ignored)
make[4]: Leaving directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
make[4]: Entering directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
mkdir -p /usr/share/info/
[ -f /usr/share/info/dir ] || touch /usr/share/info/dir
grep gcl-si /usr/share/info/dir >/dev/null 2>&1 || \
echo "* GCL Doc: (gcl-si.info). GNU Common Lisp specific Documentation." >> /usr/share/info/dir
/bin/sh: /usr/share/info/dir: Permission denied
make[4]: *** [install] Error 1

My preliminary analysis is that GCL is insisting to install info files
in a directory (/usr/share/info) which is not part of what is
specified as --prefix and on which I do not have a write permission
(and even if I had a write permission, it would still be wrong).

I don't think I would be able to provide a fix right now as I have to
watch a sick baby.

-- Gaby
Gabriel Dos Reis
2006-10-27 01:27:02 UTC
Permalink
Gabriel Dos Reis <***@integrable-solutions.net> writes:

| Camm Maguire <***@enhanced.com> writes:
|
| | Greetings! OK, should be optional now. Please let me know if not.
|
| Camm --
|
| Thanks for the quick fix.
|
| Now, the build progressed further but still I hit a regression when I
| try to install it in a specifc location (it worked with earlier versions):
|
| make[4]: [gcl-si.info] Error 1 (ignored)
| make[4]: Leaving directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
| make[4]: Entering directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
| mkdir -p /usr/share/info/
| [ -f /usr/share/info/dir ] || touch /usr/share/info/dir
| grep gcl-si /usr/share/info/dir >/dev/null 2>&1 || \
| echo "* GCL Doc: (gcl-si.info). GNU Common Lisp specific Documentation." >> /usr/share/info/dir
| /bin/sh: /usr/share/info/dir: Permission denied
| make[4]: *** [install] Error 1
|
| My preliminary analysis is that GCL is insisting to install info files
| in a directory (/usr/share/info) which is not part of what is
| specified as --prefix and on which I do not have a write permission
| (and even if I had a write permission, it would still be wrong).

In configure.in, GCL as a machinery to check for where to install the
info files. With a default value as $prefix/share/info. That is perfect.
However, down the road, GCL changes its mind and wanted to know
whether /usr/share/info/dir exits, and if it does then it would install the
info files there. That is not right.

if test -f "${INFO_DIR}dir" ; then true;else
if test -f /usr/share/info/dir ; then
INFO_DIR=/usr/share/info/
else true;
fi
fi

I'll be checking in a patch that removes that.

-- Gaby
Gabriel Dos Reis
2006-10-27 02:25:52 UTC
Permalink
Gabriel Dos Reis <***@integrable-solutions.net> writes:

[...]

| In configure.in, GCL as a machinery to check for where to install the
| info files. With a default value as $prefix/share/info. That is perfect.
| However, down the road, GCL changes its mind and wanted to know
| whether /usr/share/info/dir exits, and if it does then it would install the
| info files there. That is not right.
|
| if test -f "${INFO_DIR}dir" ; then true;else
| if test -f /usr/share/info/dir ; then
| INFO_DIR=/usr/share/info/
| else true;
| fi
| fi
|
| I'll be checking in a patch that removes that.

With the removal patch in, I'm able to a successful build GCL inside
Axiom. Complete Axiom build is under way.

-- Gaby
Camm Maguire
2006-10-27 14:01:05 UTC
Permalink
Thanks! I'll be doing likewise in cvs head.

Take care,
Post by Gabriel Dos Reis
|
| | Greetings! OK, should be optional now. Please let me know if not.
|
| Camm --
|
| Thanks for the quick fix.
|
| Now, the build progressed further but still I hit a regression when I
|
| make[4]: [gcl-si.info] Error 1 (ignored)
| make[4]: Leaving directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
| make[4]: Entering directory `/home/gdr/build/axiom/lsp/gcl-2.6.8pre/info'
| mkdir -p /usr/share/info/
| [ -f /usr/share/info/dir ] || touch /usr/share/info/dir
| grep gcl-si /usr/share/info/dir >/dev/null 2>&1 || \
| echo "* GCL Doc: (gcl-si.info). GNU Common Lisp specific Documentation." >> /usr/share/info/dir
| /bin/sh: /usr/share/info/dir: Permission denied
| make[4]: *** [install] Error 1
|
| My preliminary analysis is that GCL is insisting to install info files
| in a directory (/usr/share/info) which is not part of what is
| specified as --prefix and on which I do not have a write permission
| (and even if I had a write permission, it would still be wrong).
In configure.in, GCL as a machinery to check for where to install the
info files. With a default value as $prefix/share/info. That is perfect.
However, down the road, GCL changes its mind and wanted to know
whether /usr/share/info/dir exits, and if it does then it would install the
info files there. That is not right.
if test -f "${INFO_DIR}dir" ; then true;else
if test -f /usr/share/info/dir ; then
INFO_DIR=/usr/share/info/
else true;
fi
fi
I'll be checking in a patch that removes that.
-- Gaby
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-10-18 06:16:17 UTC
Permalink
Tim,
Post by root
Are you able to do save-system in gcl on OSX?
That's my current limitation.
Yes. The following sequence works:

gcl
(si:save-system "whatever")
(quit)
./whatever
(+ 1 1)

Can you suggest a more significant test?

Regards,
Bill Page.
root
2006-10-18 06:31:25 UTC
Permalink
Post by Page, Bill
Post by root
Are you able to do save-system in gcl on OSX?
That's my current limitation.
gcl
(si:save-system "whatever")
(quit)
./whatever
(+ 1 1)
Can you suggest a more significant test?
nope. that's all i need. now i can trash the work i've been doing
and get the system together. great news.

why did you need gettext and sed? i've grabbed tarballs of both,
saved your instructions, and will try to follow your lead on this.

t
Page, Bill
2006-10-18 07:04:44 UTC
Permalink
Tim,
Post by root
...
why did you need gettext and sed? i've grabbed tarballs of both,
saved your instructions, and will try to follow your lead on
this.
The gcl build needs gnu msgfmt and libintl from gettext since at
least some part of gcl (binutils and debian) trys to provide
localized messages. On your system you might find this in the
/sw directory if you've previously installed Fink. But I wanted
to avoid that.

On the OSX 10.2 system I am using at SourceForge, the 'sed' editor
is quite old and complained about some of the sed scripts in the
gcl build, so I just locally replaced it with the new version.
This might not be a problem on newer releases of OSX. (10.8 just
released?)

The critical thing was really the patch to o/unexmacosx.c. This
part of gcl is borrowed from emacs but it is based on a version
of emacs that is now quite old. I started by trying to use a newer
version of unexmacosx.c from the emacs source distribution, but the
gcl-specific modifications were beyond my level of understanding.
In the end I opted to backport just the minimum changes that allowed
the old version to compile. But I wouldn't be too surprized if this
was broken again in newer releases of OSX.

Have you tried downloading and running the binary that I posted
in an earlier message?

http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin

Regards,
Bill Page.
root
2006-10-18 10:57:44 UTC
Permalink
Post by Page, Bill
Have you tried downloading and running the binary that I posted
in an earlier message?
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
nope. i'll download it later tonight --t
root
2006-10-18 10:58:39 UTC
Permalink
Post by Page, Bill
Have you tried downloading and running the binary that I posted
in an earlier message?
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
nope. i'll download it later tonight --t
Page, Bill
2006-10-18 18:11:02 UTC
Permalink
Camm,
Post by Camm Maguire
Post by Page, Bill
I have succeeded in compiling gcl-2.6.8pre on MAC OSX 10.2 on the
SourceForge compile farm 'ppc-osx3' server, however some patches
were necessary. This machine has Xcode installed by not Fink.
First, I checked out gcl-2.6.8pre from cvs on October 15, 2006,
created a tarball and scp'd it and the standard gnu gettext-0.15
and sed-4.1.4 tarballs to my home directory on SourceForge.
Next I compiled and installed gettext and sed with
--prefix=/home/users/b/bi/billpage/osx
creating the ~/osx/bin and ~/osx/lib directories. These are
apparently required to satisfy the gcl build dependencies on
OSX 10.2. (Note: A Fink installation might also have provided
these in the /sw directory.)
I thought that gettext was no longer required, as it was included
in the local bfd build (from configure.in:)
cd binutils/bfd && chmod +x configure && ./configure
--with-included-gettext && cd ../..
If I remove my local osx/bin from the PATH and try again I get
the error message "msgfmt: command not found" shown below.

---------

$ ./configure --prefix=/home/users/b/bi/billpage/osx \
--disable-tkconfig --disable-statsysbfd --enable-locbfd
$ make
cd binutils/intl && make
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 intl-compat.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 bindtextdom.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 dcgettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 dgettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 gettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 finddomain.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 loadmsgcat.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 localealias.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 textdomain.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 l10nflist.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 explodename.c
rm -f libintl.a
ar cru libintl.a intl-compat.o bindtextdom.o dcgettext.o dgettext.o
gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o
l10nflist.o explodename.o
ranlib libintl.a
cd binutils/bfd && make
make all-recursive
Making all in doc
make[3]: Nothing to be done for `all'.
Making all in po
( if test 'x.' != 'x.'; then \
posrcprefix='../'; \
else \
posrcprefix="../"; \
fi; \
rm -f SRC-POTFILES-t SRC-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
-e "***@.*@ $posrcprefix& \\\\@" < ./SRC-POTFILES.in \
| sed -e '$s/\\$//') > SRC-POTFILES-t \
&& chmod a-w SRC-POTFILES-t \
&& mv SRC-POTFILES-t SRC-POTFILES )
( rm -f BLD-POTFILES-t BLD-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
-e "***@.*@ ../& \\\\@" < ./BLD-POTFILES.in \
| sed -e '$s/\\$//') > BLD-POTFILES-t \
&& chmod a-w BLD-POTFILES-t \
&& mv BLD-POTFILES-t BLD-POTFILES )
cd .. \
&& CONFIG_FILES=po/Makefile.in:po/Make-in \
CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
file=./`echo fr | sed 's,.*/,,'`.gmo \
&& rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: msgfmt: command not found
make[3]: *** [fr.gmo] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [binutils/bfd/libbfd.a] Error 2

---------

gcl-2.6.8pre/binutils/bfd/config.log confirms:

Invocation command line was

$ ./configure --with-included-gettext

But apparently recursive makefile in bfd/po does not make
use of the included gettext. Maybe this is a binutils bug?
Post by Camm Maguire
We do need sed. I guess OSX has none, or it is incompatible?
This OSX 10.2 has an old sed that is not compatible.
Post by Camm Maguire
Is Fink so non-standard that it must be avoided? What is
the canonical way to get gnu software on OSX?
I don't know. This SourceForge server is the closest I have
ever been to a MAC and it's probably a few thousand miles
away from here... :-) But I have heard that many people would
like to try to avoid installing "foreign" package systems like
Fink.
Post by Camm Maguire
Post by Page, Bill
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
export
LIBRARY_PATH=/home/users/b/bi/billpage/osx/lib:$LIBRARY_PATH
Post by Page, Bill
export CPPFLAGS="-no-cpp-precomp"
cd osx
to ~/.profile so that after re-login the environment was set
appropriately.
I untarred gcl into the osx directory creating ~/osx/gcl-2.6.8pre
Then I applied the following patches (most of which have been
------------------------
ppc-osx3:~/osx billpage$ diff -Naur old/gcl* new/gcl*
This patch required so libintl is found in $LIBRARY_PATH.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.defs
new/gcl-2.6.8pre/h/powerpc-macosx.defs
--- old/gcl-2.6.8pre/h/powerpc-macosx.defs Thu Jul 15
09:28:43 2004
Post by Page, Bill
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15
22:07:45 2006
Post by Page, Bill
@@ -6,7 +6,7 @@
# Set this to avoid warnings when linking against libncurses.
# This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`
/sw/lib/libintl.dylib
Post by Page, Bill
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
# Set this for the linker to operate correctly.
MACOSX_DEPLOYMENT_TARGET = 10.2
@@ -32,4 +32,4 @@
# This appears to be no longer necessary on Panther.
ARRS = libtool -static -o
-FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
\ No newline at end of file
+FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
OK, this is going in, but I think we can lose the -lintl too.
Anyone want to try to verify?
I think you are right.

If I 'make clean' and write:

+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15
...
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`

and just adding:

export PATH=/home/users/b/bi/billpage/osx/bin:$PATH

(to avoid gettext bug) then trying configure & make as above
works fine.
Post by Camm Maguire
Post by Page, Bill
This patch is required to define sbrk.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.h
new/gcl-2.6.8pre/h/powerpc-macosx.h
--- old/gcl-2.6.8pre/h/powerpc-macosx.h Thu Dec 8 17:31:25 2005
+++ new/gcl-2.6.8pre/h/powerpc-macosx.h Sun Oct 15 21:32:23 2006
@@ -38,8 +38,9 @@
#undef SET_REAL_MAXPAGE
#define SET_REAL_MAXPAGE { my_sbrk(0); real_maxpage = (int)
mach_maplimit/PAGESIZE; }
-#define sbrk my_sbrk
+#include <unistd.h> /* to get sbrk defined */
extern void *my_sbrk(int incr);
+#define sbrk my_sbrk
/** (si::save-system "...") a.k.a. unexec implementation */
I don't get this one, as we emulate sbrk here. Where is the system
definition required?
If I reverse this change and do 'make clean & configure & make'
I get the error "conflicting types for `my_sbrk'":

cd unixport && make saved_pre_gcl
ls: ../xgcl-2/*.o: No such file or directory
ls: ../mod/*.o: No such file or directory
ls: ../pcl/*.o: No such file or directory
ls: ../clcs/*.o: No such file or directory
ls: ../clcs/clcs_*.lisp: No such file or directory
gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer
-I/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/o -c -o sys_pre_gcl.o
sys_pre_gcl.c
../h/../h/protoize.h:465: warning: could not use precompiled header
'/usr/include/unistd-gcc3.p', because:
../h/../h/protoize.h:465: warning: macro 'valloc' defined by
../h/config.h conflicts with precomp
In file included from ../h/../h/protoize.h:465,
from ../h/include.h:70,
from sys_pre_gcl.c:3:
/usr/include/unistd.h:203: conflicting types for `my_sbrk'
../h/config.h:42: previous declaration of `my_sbrk'
make[1]: *** [sys_pre_gcl.o] Error 1
make: *** [unixport/saved_pre_gcl] Error 2

-------
Post by Camm Maguire
Post by Page, Bill
This patch is required to remove functions symbols from plt.
diff -Naur old/gcl-2.6.8pre/o/makefile new/gcl-2.6.8pre/o/makefile
--- old/gcl-2.6.8pre/o/makefile Fri Sep 15 10:45:18 2006
+++ new/gcl-2.6.8pre/o/makefile Mon Oct 16 22:03:52 2006
@@ -154,7 +154,7 @@
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
- grep -v '[^ \t_]_' |\
+ grep -v 'restFP' | grep -v 'saveFP'
| grep -v
Post by Page, Bill
'[^ \t_]_' |\
$(AWK) '{A[++k]=$$0} END {for
(i=1;i<=k;i++) \
OK. This is quite ugly, but its a hack to begin with. Suggestions
most welcome.
I only vaguely understand what this is doing but 'restFP' and
'saveFP' are not removed from this list than the compile complains
about "function symbols" not used in a function ... or something
like that. The other names make sense to me. For example:

MY_PLT(__srget),
MY_PLT(__swbuf),
...

which derive from the implementation of getc(f) and putc(ch,f).
But see later in the message - I apparently have a problem with
__srget.
Post by Camm Maguire
Post by Page, Bill
This patch is required to find malloc.h on some OSX machines.
diff -Naur old/gcl-2.6.8pre/o/unexmacosx.c
new/gcl-2.6.8pre/o/unexmacosx.c
--- old/gcl-2.6.8pre/o/unexmacosx.c Thu Dec 15 10:48:43 2005
+++ new/gcl-2.6.8pre/o/unexmacosx.c Tue Oct 17 18:55:04 2006
@@ -124,7 +124,13 @@
#endif
#include <mach-o/nlist.h>
#include <mach-o/getsect.h>
+/* not <sys/malloc.h> */
+/* not <malloc.h> */
+#if defined (HAVE_MALLOC_MALLOC_H)
#include <malloc/malloc.h>
+#else
+#include <objc/malloc.h>
+#endif
#include <sys/mman.h>
OK, I take it you are using objc/malloc.h. We need configure code
to look for this, and bomb if it cannot find one, just on macosx.
I'll take a stab unless someone else wants to.
Makes sense to me. You are the autoconf wizard. :-)
Post by Camm Maguire
May I suggest we also lose the diagnostic output on save-system
on this platform?
Yes, it looks pretty ugly but maybe it is needed just a little
while longer (or optionally) to verify that si::save-system and
compiler::link are really working properly?
Post by Camm Maguire
Thanks again! Will post when something is checked in.
Thank you. I look forward to a finally finalized 2.6.8. The
evoluton of 2.6.8pre is causing us a little consternaton in
the current Axiom source distribution... :-)
Post by Camm Maguire
BTW, I'm pushing 2.6.8 (in the guise of 2.6.7) and all the apps
through the Debian autobuilder system before releasing 2.6.8.
Please let me know of any other 2.6.8 issues you may be
encountering in your axiom work asap. Bug fix only at this
point, of course.
Hmmmm... well I do currently have a problem with the Axiom build.
After successfully building bootsys and depsys the build fails
building interpsys with the following message:

start address -T 0xb8f000 Finished loading
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-apple
-darwin6.8/interp/bookvol5.o
Loading
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-apple
-darwin6.8/interp/util.o

Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Page, Bill
make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build/powerpc-ap
ple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1

---------

Something is strange about thid symbol "___srget" with the 3
underscore characters, I think??? The name "__srget" with 2
underscore characters is properly defined in /usr/include/stdio.h

I don't understand what is going on here.

Also prior to compiling depsys, bootsys was already successfully
created however it did have one oddity. The original Axiom load
commands like ')load postpar' run during building depsys fails
with an error message like "'postpar.8' does not exist" (Yes, that's
the digit 8 after the dot.). If I change the command to include the
.o like this: ')load postpar.o' everything seems fine and depsys
is built.

bootsys itself is actually built form a copy of gcl called 'lisp'
that is created using compiler::link. The 'lisp' image includes
several Axiom specific external routines. I.e.

echo '(compiler::link nil

"/home/users/b/bi/billpage/osx/axiom.build-improvements/build/powerpc-ap
ple-darwin6.8/bin/lisp" ' \
' (format nil "(progn (let ((*load-path* (cons ~S
*load-path*))'\
' (si::*load-types* ~S))' \
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on t))' \
' (setq compiler::*default-system-p* t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
'
"/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib
/cfuns-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib/
sockio-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib/
libspad.a")' \
| /home/users/b/bi/billpage/osx/bin/gcl

If I intervene and make Axiom use the original 'saved_gcl' to build
'bootsys' instead of using 'lisp', then the 'postpar.8' problem does
not occur and gcl finds the .o files anyway, as expected.

This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result images also
seem curious:

-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys

Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.

A test image of gcl created by

$ gcl
(si:save-system "test-image")
(quit)

is actually *larger* than the original saved_gcl.

-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image

Are all these problems related?

Any thing you can suggest would be greatly appreciated.

Regards,
Bill Page.
Post by Camm Maguire
Post by Page, Bill
---------
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
I would be very happy if anyone with a MAC OSX machine would try
this version of gcl on their systems and let me know of any
problems.
I am currently working on completing the Axiom build based on the
new build-improvements branch.
Camm Maguire
2006-10-18 20:30:50 UTC
Permalink
Greetings!
Post by Page, Bill
Camm,
Post by Camm Maguire
Post by Page, Bill
I have succeeded in compiling gcl-2.6.8pre on MAC OSX 10.2 on the
SourceForge compile farm 'ppc-osx3' server, however some patches
were necessary. This machine has Xcode installed by not Fink.
First, I checked out gcl-2.6.8pre from cvs on October 15, 2006,
created a tarball and scp'd it and the standard gnu gettext-0.15
and sed-4.1.4 tarballs to my home directory on SourceForge.
Next I compiled and installed gettext and sed with
--prefix=/home/users/b/bi/billpage/osx
creating the ~/osx/bin and ~/osx/lib directories. These are
apparently required to satisfy the gcl build dependencies on
OSX 10.2. (Note: A Fink installation might also have provided
these in the /sw directory.)
I thought that gettext was no longer required, as it was included
in the local bfd build (from configure.in:)
cd binutils/bfd && chmod +x configure && ./configure
--with-included-gettext && cd ../..
If I remove my local osx/bin from the PATH and try again I get
the error message "msgfmt: command not found" shown below.
---------
$ ./configure --prefix=/home/users/b/bi/billpage/osx \
--disable-tkconfig --disable-statsysbfd --enable-locbfd
$ make
cd binutils/intl && make
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 intl-compat.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 bindtextdom.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 dcgettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 dgettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 gettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 finddomain.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 loadmsgcat.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 localealias.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 textdomain.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 l10nflist.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 explodename.c
rm -f libintl.a
ar cru libintl.a intl-compat.o bindtextdom.o dcgettext.o dgettext.o
gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o
l10nflist.o explodename.o
ranlib libintl.a
cd binutils/bfd && make
make all-recursive
Making all in doc
make[3]: Nothing to be done for `all'.
Making all in po
( if test 'x.' != 'x.'; then \
posrcprefix='../'; \
else \
posrcprefix="../"; \
fi; \
rm -f SRC-POTFILES-t SRC-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
| sed -e '$s/\\$//') > SRC-POTFILES-t \
&& chmod a-w SRC-POTFILES-t \
&& mv SRC-POTFILES-t SRC-POTFILES )
( rm -f BLD-POTFILES-t BLD-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
| sed -e '$s/\\$//') > BLD-POTFILES-t \
&& chmod a-w BLD-POTFILES-t \
&& mv BLD-POTFILES-t BLD-POTFILES )
cd .. \
&& CONFIG_FILES=po/Makefile.in:po/Make-in \
CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
file=./`echo fr | sed 's,.*/,,'`.gmo \
&& rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: msgfmt: command not found
make[3]: *** [fr.gmo] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [binutils/bfd/libbfd.a] Error 2
Sigh. I suppose reconfigured here? The binutils configure scripts do
look for msgfmt. I'm surprised they don't step around a missing one,
or at least bomb. What does your binutils configure output say in
this regard?
Post by Page, Bill
---------
Invocation command line was
$ ./configure --with-included-gettext
But apparently recursive makefile in bfd/po does not make
use of the included gettext. Maybe this is a binutils bug?
Post by Camm Maguire
We do need sed. I guess OSX has none, or it is incompatible?
This OSX 10.2 has an old sed that is not compatible.
Post by Camm Maguire
Is Fink so non-standard that it must be avoided? What is
the canonical way to get gnu software on OSX?
I don't know. This SourceForge server is the closest I have
ever been to a MAC and it's probably a few thousand miles
away from here... :-) But I have heard that many people would
like to try to avoid installing "foreign" package systems like
Fink.
Post by Camm Maguire
Post by Page, Bill
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
export
LIBRARY_PATH=/home/users/b/bi/billpage/osx/lib:$LIBRARY_PATH
Post by Page, Bill
export CPPFLAGS="-no-cpp-precomp"
cd osx
to ~/.profile so that after re-login the environment was set
appropriately.
I untarred gcl into the osx directory creating ~/osx/gcl-2.6.8pre
Then I applied the following patches (most of which have been
------------------------
ppc-osx3:~/osx billpage$ diff -Naur old/gcl* new/gcl*
This patch required so libintl is found in $LIBRARY_PATH.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.defs
new/gcl-2.6.8pre/h/powerpc-macosx.defs
--- old/gcl-2.6.8pre/h/powerpc-macosx.defs Thu Jul 15
09:28:43 2004
Post by Page, Bill
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15
22:07:45 2006
Post by Page, Bill
@@ -6,7 +6,7 @@
# Set this to avoid warnings when linking against libncurses.
# This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`
/sw/lib/libintl.dylib
Post by Page, Bill
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
# Set this for the linker to operate correctly.
MACOSX_DEPLOYMENT_TARGET = 10.2
@@ -32,4 +32,4 @@
# This appears to be no longer necessary on Panther.
ARRS = libtool -static -o
-FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
\ No newline at end of file
+FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
OK, this is going in, but I think we can lose the -lintl too.
Anyone want to try to verify?
I think you are right.
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15
...
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
(to avoid gettext bug) then trying configure & make as above
works fine.
Post by Camm Maguire
Post by Page, Bill
This patch is required to define sbrk.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.h
new/gcl-2.6.8pre/h/powerpc-macosx.h
--- old/gcl-2.6.8pre/h/powerpc-macosx.h Thu Dec 8 17:31:25 2005
+++ new/gcl-2.6.8pre/h/powerpc-macosx.h Sun Oct 15 21:32:23 2006
@@ -38,8 +38,9 @@
#undef SET_REAL_MAXPAGE
#define SET_REAL_MAXPAGE { my_sbrk(0); real_maxpage = (int)
mach_maplimit/PAGESIZE; }
-#define sbrk my_sbrk
+#include <unistd.h> /* to get sbrk defined */
extern void *my_sbrk(int incr);
+#define sbrk my_sbrk
/** (si::save-system "...") a.k.a. unexec implementation */
I don't get this one, as we emulate sbrk here. Where is the system
definition required?
If I reverse this change and do 'make clean & configure & make'
cd unixport && make saved_pre_gcl
ls: ../xgcl-2/*.o: No such file or directory
ls: ../mod/*.o: No such file or directory
ls: ../pcl/*.o: No such file or directory
ls: ../clcs/*.o: No such file or directory
ls: ../clcs/clcs_*.lisp: No such file or directory
gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer
-I/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/o -c -o sys_pre_gcl.o
sys_pre_gcl.c
../h/../h/protoize.h:465: warning: could not use precompiled header
../h/../h/protoize.h:465: warning: macro 'valloc' defined by
../h/config.h conflicts with precomp
In file included from ../h/../h/protoize.h:465,
from ../h/include.h:70,
/usr/include/unistd.h:203: conflicting types for `my_sbrk'
../h/config.h:42: previous declaration of `my_sbrk'
make[1]: *** [sys_pre_gcl.o] Error 1
make: *** [unixport/saved_pre_gcl] Error 2
OK this is in.
Post by Page, Bill
-------
Post by Camm Maguire
Post by Page, Bill
This patch is required to remove functions symbols from plt.
diff -Naur old/gcl-2.6.8pre/o/makefile new/gcl-2.6.8pre/o/makefile
--- old/gcl-2.6.8pre/o/makefile Fri Sep 15 10:45:18 2006
+++ new/gcl-2.6.8pre/o/makefile Mon Oct 16 22:03:52 2006
@@ -154,7 +154,7 @@
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
- grep -v '[^ \t_]_' |\
+ grep -v 'restFP' | grep -v 'saveFP'
| grep -v
Post by Page, Bill
'[^ \t_]_' |\
$(AWK) '{A[++k]=$$0} END {for
(i=1;i<=k;i++) \
OK. This is quite ugly, but its a hack to begin with. Suggestions
most welcome.
I only vaguely understand what this is doing but 'restFP' and
'saveFP' are not removed from this list than the compile complains
about "function symbols" not used in a function ... or something
MY_PLT(__srget),
MY_PLT(__swbuf),
...
which derive from the implementation of getc(f) and putc(ch,f).
But see later in the message - I apparently have a problem with
__srget.
There is a notorious platform specific _ name mangling issue here.
See the LEADING_UNDERSCORE variable.
Post by Page, Bill
Post by Camm Maguire
Post by Page, Bill
This patch is required to find malloc.h on some OSX machines.
diff -Naur old/gcl-2.6.8pre/o/unexmacosx.c
new/gcl-2.6.8pre/o/unexmacosx.c
--- old/gcl-2.6.8pre/o/unexmacosx.c Thu Dec 15 10:48:43 2005
+++ new/gcl-2.6.8pre/o/unexmacosx.c Tue Oct 17 18:55:04 2006
@@ -124,7 +124,13 @@
#endif
#include <mach-o/nlist.h>
#include <mach-o/getsect.h>
+/* not <sys/malloc.h> */
+/* not <malloc.h> */
+#if defined (HAVE_MALLOC_MALLOC_H)
#include <malloc/malloc.h>
+#else
+#include <objc/malloc.h>
+#endif
#include <sys/mman.h>
OK, I take it you are using objc/malloc.h. We need configure code
to look for this, and bomb if it cannot find one, just on macosx.
I'll take a stab unless someone else wants to.
Makes sense to me. You are the autoconf wizard. :-)
Ugh. :-)
Post by Page, Bill
Post by Camm Maguire
May I suggest we also lose the diagnostic output on save-system
on this platform?
Yes, it looks pretty ugly but maybe it is needed just a little
while longer (or optionally) to verify that si::save-system and
compiler::link are really working properly?
OK.
Post by Page, Bill
Post by Camm Maguire
Thanks again! Will post when something is checked in.
Thank you. I look forward to a finally finalized 2.6.8. The
evoluton of 2.6.8pre is causing us a little consternaton in
the current Axiom source distribution... :-)
My apologies. So many moving parts. I have to get everything synched
on one image, however, if we want these apps in Etch. And there have
been so many gcc et. al. issues.

BTW, are we not updating

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/

anymore? Is there a latest official tarball somewhere for Etch (eta
this December)? Having a simple webpage with the filenames in some
sort of alphabetical/cronological sort order lets me automatically
know when the Debian package needs updating.
Post by Page, Bill
Post by Camm Maguire
BTW, I'm pushing 2.6.8 (in the guise of 2.6.7) and all the apps
through the Debian autobuilder system before releasing 2.6.8.
Please let me know of any other 2.6.8 issues you may be
encountering in your axiom work asap. Bug fix only at this
point, of course.
Hmmmm... well I do currently have a problem with the Axiom build.
After successfully building bootsys and depsys the build fails
start address -T 0xb8f000 Finished loading
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-apple
-darwin6.8/interp/bookvol5.o
Loading
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-apple
-darwin6.8/interp/util.o
Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Page, Bill
make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build/powerpc-ap
ple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
---------
Something is strange about thid symbol "___srget" with the 3
underscore characters, I think??? The name "__srget" with 2
underscore characters is properly defined in /usr/include/stdio.h
I don't understand what is going on here.
OK, your linker is prepending an underscore, and apparently
LEADING_UNDERSCORE was improperly set. Could you investigate? There
may also be a C compiler switch for this. Is this gcc?
Post by Page, Bill
Also prior to compiling depsys, bootsys was already successfully
created however it did have one oddity. The original Axiom load
commands like ')load postpar' run during building depsys fails
with an error message like "'postpar.8' does not exist" (Yes, that's
the digit 8 after the dot.). If I change the command to include the
.o like this: ')load postpar.o' everything seems fine and depsys
is built.
bootsys itself is actually built form a copy of gcl called 'lisp'
that is created using compiler::link. The 'lisp' image includes
several Axiom specific external routines. I.e.
echo '(compiler::link nil
"/home/users/b/bi/billpage/osx/axiom.build-improvements/build/powerpc-ap
ple-darwin6.8/bin/lisp" ' \
' (format nil "(progn (let ((*load-path* (cons ~S
*load-path*))'\
' (si::*load-types* ~S))' \
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on t))' \
' (setq compiler::*default-system-p* t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
'
"/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib
/cfuns-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib/
sockio-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib/
libspad.a")' \
| /home/users/b/bi/billpage/osx/bin/gcl
Can you post the output from this?
Post by Page, Bill
If I intervene and make Axiom use the original 'saved_gcl' to build
'bootsys' instead of using 'lisp', then the 'postpar.8' problem does
not occur and gcl finds the .o files anyway, as expected.
This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result images also
-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys
Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.
A test image of gcl created by
$ gcl
(si:save-system "test-image")
(quit)
is actually *larger* than the original saved_gcl.
-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image
Are all these problems related?
Any thing you can suggest would be greatly appreciated.
I also suspect compiler::link failure. It is also odd that
save-system images are so much bigger. Here is the tiny difference on
Linux:

ls -l /usr/lib/gcl-2.6.7/unixport/saved_gcl
-rwxr-xr-x 1 root root 9329131 Oct 18 13:43 /usr/lib/gcl-2.6.7/unixport/saved_gcl
/usr/lib/gcl-2.6.7/unixport/saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 18 2006 13:40:07
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Page, Bill
(si::save-system "/tmp/ff")
ls -l /tmp/ff
-rwxr-x--- 1 camm camm 9333267 Oct 18 16:25 /tmp/ff

compiler::link should be no smaller than saved_gcl. The raw files are
explicitly deleted as named and output by gcc -- the .tmp extension
appears non-std and might be expected to persist.

I'd make two images, one with

(si::save-system "foo")

and the other with

(compiler::link nil "bar")

And then in each, do a few tests, including looking at
si::*load-types*.


Lastly, you all in the axiom world might like to know that I'm about
to release an HOL88 Debian package build atop GCL. In addition to
providing an alternate theorem proving environment, one also has the
ML language built into the same image for potential use by axiom.
More on this later.

Take care,
Post by Page, Bill
Regards,
Bill Page.
Post by Camm Maguire
Post by Page, Bill
---------
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
I would be very happy if anyone with a MAC OSX machine would try
this version of gcl on their systems and let me know of any
problems.
I am currently working on completing the Axiom build based on the
new build-improvements branch.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Gabriel Dos Reis
2006-10-18 22:33:33 UTC
Permalink
Camm Maguire <***@enhanced.com> writes:

[...]

| Sigh. I suppose reconfigured here? The binutils configure scripts do
| look for msgfmt. I'm surprised they don't step around a missing one,
| or at least bomb.

It is GNU standard policy to support --disable-nls. Did you try it?

-- Gaby
Camm Maguire
2006-10-21 20:04:46 UTC
Permalink
Greetings! Just checking that my last message hee was not lost.

Take care,
Post by Page, Bill
Camm,
Post by Camm Maguire
Post by Page, Bill
I have succeeded in compiling gcl-2.6.8pre on MAC OSX 10.2 on the
SourceForge compile farm 'ppc-osx3' server, however some patches
were necessary. This machine has Xcode installed by not Fink.
First, I checked out gcl-2.6.8pre from cvs on October 15, 2006,
created a tarball and scp'd it and the standard gnu gettext-0.15
and sed-4.1.4 tarballs to my home directory on SourceForge.
Next I compiled and installed gettext and sed with
--prefix=/home/users/b/bi/billpage/osx
creating the ~/osx/bin and ~/osx/lib directories. These are
apparently required to satisfy the gcl build dependencies on
OSX 10.2. (Note: A Fink installation might also have provided
these in the /sw directory.)
I thought that gettext was no longer required, as it was included
in the local bfd build (from configure.in:)
cd binutils/bfd && chmod +x configure && ./configure
--with-included-gettext && cd ../..
If I remove my local osx/bin from the PATH and try again I get
the error message "msgfmt: command not found" shown below.
---------
$ ./configure --prefix=/home/users/b/bi/billpage/osx \
--disable-tkconfig --disable-statsysbfd --enable-locbfd
$ make
cd binutils/intl && make
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 intl-compat.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 bindtextdom.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 dcgettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 dgettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 gettext.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 finddomain.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 loadmsgcat.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 localealias.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 textdomain.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 l10nflist.c
gcc -c -DLOCALEDIR=\"/usr/local/share/locale\"
-DGNULOCALEDIR=\"/usr/local/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.
-I. -g -O2 explodename.c
rm -f libintl.a
ar cru libintl.a intl-compat.o bindtextdom.o dcgettext.o dgettext.o
gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o
l10nflist.o explodename.o
ranlib libintl.a
cd binutils/bfd && make
make all-recursive
Making all in doc
make[3]: Nothing to be done for `all'.
Making all in po
( if test 'x.' != 'x.'; then \
posrcprefix='../'; \
else \
posrcprefix="../"; \
fi; \
rm -f SRC-POTFILES-t SRC-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
| sed -e '$s/\\$//') > SRC-POTFILES-t \
&& chmod a-w SRC-POTFILES-t \
&& mv SRC-POTFILES-t SRC-POTFILES )
( rm -f BLD-POTFILES-t BLD-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
| sed -e '$s/\\$//') > BLD-POTFILES-t \
&& chmod a-w BLD-POTFILES-t \
&& mv BLD-POTFILES-t BLD-POTFILES )
cd .. \
&& CONFIG_FILES=po/Makefile.in:po/Make-in \
CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
file=./`echo fr | sed 's,.*/,,'`.gmo \
&& rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: msgfmt: command not found
make[3]: *** [fr.gmo] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [binutils/bfd/libbfd.a] Error 2
---------
Invocation command line was
$ ./configure --with-included-gettext
But apparently recursive makefile in bfd/po does not make
use of the included gettext. Maybe this is a binutils bug?
Post by Camm Maguire
We do need sed. I guess OSX has none, or it is incompatible?
This OSX 10.2 has an old sed that is not compatible.
Post by Camm Maguire
Is Fink so non-standard that it must be avoided? What is
the canonical way to get gnu software on OSX?
I don't know. This SourceForge server is the closest I have
ever been to a MAC and it's probably a few thousand miles
away from here... :-) But I have heard that many people would
like to try to avoid installing "foreign" package systems like
Fink.
Post by Camm Maguire
Post by Page, Bill
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
export
LIBRARY_PATH=/home/users/b/bi/billpage/osx/lib:$LIBRARY_PATH
Post by Page, Bill
export CPPFLAGS="-no-cpp-precomp"
cd osx
to ~/.profile so that after re-login the environment was set
appropriately.
I untarred gcl into the osx directory creating ~/osx/gcl-2.6.8pre
Then I applied the following patches (most of which have been
------------------------
ppc-osx3:~/osx billpage$ diff -Naur old/gcl* new/gcl*
This patch required so libintl is found in $LIBRARY_PATH.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.defs
new/gcl-2.6.8pre/h/powerpc-macosx.defs
--- old/gcl-2.6.8pre/h/powerpc-macosx.defs Thu Jul 15
09:28:43 2004
Post by Page, Bill
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15
22:07:45 2006
Post by Page, Bill
@@ -6,7 +6,7 @@
# Set this to avoid warnings when linking against libncurses.
# This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`
/sw/lib/libintl.dylib
Post by Page, Bill
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
# Set this for the linker to operate correctly.
MACOSX_DEPLOYMENT_TARGET = 10.2
@@ -32,4 +32,4 @@
# This appears to be no longer necessary on Panther.
ARRS = libtool -static -o
-FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
\ No newline at end of file
+FINAL_CFLAGS := `echo $(FINAL_CFLAGS) | sed -e 's:-g::g'`
OK, this is going in, but I think we can lose the -lintl too.
Anyone want to try to verify?
I think you are right.
+++ new/gcl-2.6.8pre/h/powerpc-macosx.defs Sun Oct 15
...
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`
export PATH=/home/users/b/bi/billpage/osx/bin:$PATH
(to avoid gettext bug) then trying configure & make as above
works fine.
Post by Camm Maguire
Post by Page, Bill
This patch is required to define sbrk.
diff -Naur old/gcl-2.6.8pre/h/powerpc-macosx.h
new/gcl-2.6.8pre/h/powerpc-macosx.h
--- old/gcl-2.6.8pre/h/powerpc-macosx.h Thu Dec 8 17:31:25 2005
+++ new/gcl-2.6.8pre/h/powerpc-macosx.h Sun Oct 15 21:32:23 2006
@@ -38,8 +38,9 @@
#undef SET_REAL_MAXPAGE
#define SET_REAL_MAXPAGE { my_sbrk(0); real_maxpage = (int)
mach_maplimit/PAGESIZE; }
-#define sbrk my_sbrk
+#include <unistd.h> /* to get sbrk defined */
extern void *my_sbrk(int incr);
+#define sbrk my_sbrk
/** (si::save-system "...") a.k.a. unexec implementation */
I don't get this one, as we emulate sbrk here. Where is the system
definition required?
If I reverse this change and do 'make clean & configure & make'
cd unixport && make saved_pre_gcl
ls: ../xgcl-2/*.o: No such file or directory
ls: ../mod/*.o: No such file or directory
ls: ../pcl/*.o: No such file or directory
ls: ../clcs/*.o: No such file or directory
ls: ../clcs/clcs_*.lisp: No such file or directory
gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer
-I/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/o -c -o sys_pre_gcl.o
sys_pre_gcl.c
../h/../h/protoize.h:465: warning: could not use precompiled header
../h/../h/protoize.h:465: warning: macro 'valloc' defined by
../h/config.h conflicts with precomp
In file included from ../h/../h/protoize.h:465,
from ../h/include.h:70,
/usr/include/unistd.h:203: conflicting types for `my_sbrk'
../h/config.h:42: previous declaration of `my_sbrk'
make[1]: *** [sys_pre_gcl.o] Error 1
make: *** [unixport/saved_pre_gcl] Error 2
-------
Post by Camm Maguire
Post by Page, Bill
This patch is required to remove functions symbols from plt.
diff -Naur old/gcl-2.6.8pre/o/makefile new/gcl-2.6.8pre/o/makefile
--- old/gcl-2.6.8pre/o/makefile Fri Sep 15 10:45:18 2006
+++ new/gcl-2.6.8pre/o/makefile Mon Oct 16 22:03:52 2006
@@ -154,7 +154,7 @@
print a}' \
k=$(LEADING_UNDERSCORE) |\
sort | \
- grep -v '[^ \t_]_' |\
+ grep -v 'restFP' | grep -v 'saveFP'
| grep -v
Post by Page, Bill
'[^ \t_]_' |\
$(AWK) '{A[++k]=$$0} END {for
(i=1;i<=k;i++) \
OK. This is quite ugly, but its a hack to begin with. Suggestions
most welcome.
I only vaguely understand what this is doing but 'restFP' and
'saveFP' are not removed from this list than the compile complains
about "function symbols" not used in a function ... or something
MY_PLT(__srget),
MY_PLT(__swbuf),
...
which derive from the implementation of getc(f) and putc(ch,f).
But see later in the message - I apparently have a problem with
__srget.
Post by Camm Maguire
Post by Page, Bill
This patch is required to find malloc.h on some OSX machines.
diff -Naur old/gcl-2.6.8pre/o/unexmacosx.c
new/gcl-2.6.8pre/o/unexmacosx.c
--- old/gcl-2.6.8pre/o/unexmacosx.c Thu Dec 15 10:48:43 2005
+++ new/gcl-2.6.8pre/o/unexmacosx.c Tue Oct 17 18:55:04 2006
@@ -124,7 +124,13 @@
#endif
#include <mach-o/nlist.h>
#include <mach-o/getsect.h>
+/* not <sys/malloc.h> */
+/* not <malloc.h> */
+#if defined (HAVE_MALLOC_MALLOC_H)
#include <malloc/malloc.h>
+#else
+#include <objc/malloc.h>
+#endif
#include <sys/mman.h>
OK, I take it you are using objc/malloc.h. We need configure code
to look for this, and bomb if it cannot find one, just on macosx.
I'll take a stab unless someone else wants to.
Makes sense to me. You are the autoconf wizard. :-)
Post by Camm Maguire
May I suggest we also lose the diagnostic output on save-system
on this platform?
Yes, it looks pretty ugly but maybe it is needed just a little
while longer (or optionally) to verify that si::save-system and
compiler::link are really working properly?
Post by Camm Maguire
Thanks again! Will post when something is checked in.
Thank you. I look forward to a finally finalized 2.6.8. The
evoluton of 2.6.8pre is causing us a little consternaton in
the current Axiom source distribution... :-)
Post by Camm Maguire
BTW, I'm pushing 2.6.8 (in the guise of 2.6.7) and all the apps
through the Debian autobuilder system before releasing 2.6.8.
Please let me know of any other 2.6.8 issues you may be
encountering in your axiom work asap. Bug fix only at this
point, of course.
Hmmmm... well I do currently have a problem with the Axiom build.
After successfully building bootsys and depsys the build fails
start address -T 0xb8f000 Finished loading
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-apple
-darwin6.8/interp/bookvol5.o
Loading
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-apple
-darwin6.8/interp/util.o
Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Page, Bill
make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build/powerpc-ap
ple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
---------
Something is strange about thid symbol "___srget" with the 3
underscore characters, I think??? The name "__srget" with 2
underscore characters is properly defined in /usr/include/stdio.h
I don't understand what is going on here.
Also prior to compiling depsys, bootsys was already successfully
created however it did have one oddity. The original Axiom load
commands like ')load postpar' run during building depsys fails
with an error message like "'postpar.8' does not exist" (Yes, that's
the digit 8 after the dot.). If I change the command to include the
.o like this: ')load postpar.o' everything seems fine and depsys
is built.
bootsys itself is actually built form a copy of gcl called 'lisp'
that is created using compiler::link. The 'lisp' image includes
several Axiom specific external routines. I.e.
echo '(compiler::link nil
"/home/users/b/bi/billpage/osx/axiom.build-improvements/build/powerpc-ap
ple-darwin6.8/bin/lisp" ' \
' (format nil "(progn (let ((*load-path* (cons ~S
*load-path*))'\
' (si::*load-types* ~S))' \
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on t))' \
' (setq compiler::*default-system-p* t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
'
"/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib
/cfuns-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib/
sockio-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/.././src/lib/
libspad.a")' \
| /home/users/b/bi/billpage/osx/bin/gcl
If I intervene and make Axiom use the original 'saved_gcl' to build
'bootsys' instead of using 'lisp', then the 'postpar.8' problem does
not occur and gcl finds the .o files anyway, as expected.
This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result images also
-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys
Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.
A test image of gcl created by
$ gcl
(si:save-system "test-image")
(quit)
is actually *larger* than the original saved_gcl.
-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image
Are all these problems related?
Any thing you can suggest would be greatly appreciated.
Regards,
Bill Page.
Post by Camm Maguire
Post by Page, Bill
---------
http://page.axiom-developer.org/gcl-2.6.8-osx10-20061017.bin
I would be very happy if anyone with a MAC OSX machine would try
this version of gcl on their systems and let me know of any
problems.
I am currently working on completing the Axiom build based on the
new build-improvements branch.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Waldek Hebisch
2006-10-19 01:28:21 UTC
Permalink
Post by Camm Maguire
Post by Page, Bill
&& rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: msgfmt: command not found
make[3]: *** [fr.gmo] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [binutils/bfd/libbfd.a] Error 2
Sigh. I suppose reconfigured here? The binutils configure scripts do
look for msgfmt. I'm surprised they don't step around a missing one,
or at least bomb. What does your binutils configure output say in
this regard?
I got the same error on Amd64 debian unstable:

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00750.html

I am affraid that '--with-included-gettext' (which IIRC gcl passes to bfd)
it treated as a promise to provide 'msgfmt'.
--
Waldek Hebisch
***@math.uni.wroc.pl
Bill Page
2006-10-21 22:16:19 UTC
Permalink
Camm,
Greetings! Just checking that my last message hee was not lost.
I was a bit confused because the message that you quote below is
my reply to you not your last message. :-) But anyway I presume you
...
Sigh. I suppose reconfigured here? The binutils configure scripts
do look for msgfmt. I'm surprised they don't step around a missing
one, or at least bomb. What does your binutils configure output say
in this regard?
I am not sure what you are asking. I showed out the partial output
from gcl-2.6.8pre/binutils/bfd/config.log below.
Post by Page, Bill
---------
Invocation command line was
$ ./configure --with-included-gettext
But apparently recursive makefile in bfd/po does not make
use of the included gettext. Maybe this is a binutils bug?
When I looked further in this log file it showed that inspite of
--with-included-gettext, the configure script also found the msgfmt
in my local bin directory. I didn't understand this so I tried to
reproduce the result but first I removed all the gettext and msgfmt
from by local bin, but left it in the path in order to use the
replacement for sed.

When I re-ran the gcl build it ran properly to completion without
any error. Hmmmm... don't know. Can't reproduce. So scrap this one.
Must have been my mistake.
...
Post by Page, Bill
But see later in the message - I apparently have a problem with
__srget.
There is a notorious platform specific _ name mangling issue here.
See the LEADING_UNDERSCORE variable.
...
Post by Page, Bill
Thank you. I look forward to a finally finalized 2.6.8. The
evoluton of 2.6.8pre is causing us a little consternaton in
the current Axiom source distribution... :-)
My apologies. So many moving parts. I have to get everything synched
on one image, however, if we want these apps in Etch. And there have
been so many gcc et. al. issues.
BTW, are we not updating
http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/
anymore? Is there a latest official tarball somewhere for Etch (eta
this December)? Having a simple webpage with the filenames in some
sort of alphabetical/cronological sort order lets me automatically
know when the Debian package needs updating.
One no one has been created any new tarballs lately. The latest version
in Axiom Gold is patch-50 but I don't think Tim created a tarball when
he release the patch. :-(
Post by Page, Bill
...
Something is strange about thid symbol "___srget" with the 3
underscore characters, I think??? The name "__srget" with 2
underscore characters is properly defined in /usr/include/stdio.h
I don't understand what is going on here.
OK, your linker is prepending an underscore, and apparently
LEADING_UNDERSCORE was improperly set. Could you investigate?
I tried to track this down. LEADING_UNDERSCORE is set to 1, which
seems to be correct when I use nm to look at the symbols in the
test file compiled by the gcl configure script. The raw symbol
"___srget" does have 3 underscores (two in the original name), and
cos appears as "_cos" etc. Everything works fine during the Axiom
build for quite a while (up to the start of the building interpsys)
until the

Error: Undefined symbol "___srget"

message appears. I would have presumed that this symbol would have
been needed long before this failure occured. I rather suspsect that
this error is a consequence of some deeper but silent problem, e.g.
failed compiler::link?
There may also be a C compiler switch for this. Is this gcc?
Yes it is

$ gcc --version
gcc (GCC) 3.1 20020420 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.

What sort of switch? How/when should I set it?
Post by Page, Bill
Also prior to compiling depsys, bootsys was already successfully
created however it did have one oddity. The original Axiom load
commands like ')load postpar' run during building depsys fails
with an error message like "'postpar.8' does not exist" (Yes, that's
the digit 8 after the dot.). If I change the command to include the
.o like this: ')load postpar.o' everything seems fine and depsys
is built.
bootsys itself is actually built form a copy of gcl called 'lisp'
that is created using compiler::link. The 'lisp' image includes
several Axiom specific external routines. I.e.
echo '(compiler::link nil
"/home/users/b/bi/billpage/osx/axiom.build-improvements/build/
powerpc-ap
Post by Page, Bill
ple-darwin6.8/bin/lisp" ' \
' (format nil "(progn (let ((*load-path* (cons ~S
*load-path*))'\
' (si::*load-types* ~S))' \
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on t))' \
' (setq compiler::*default-system-p* t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
'
"/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/..
/./src/lib
Post by Page, Bill
/cfuns-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/../
./src/lib/
Post by Page, Bill
sockio-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/../
./src/lib/
Post by Page, Bill
libspad.a")' \
| /home/users/b/bi/billpage/osx/bin/gcl
Can you post the output from this?
| /home/users/b/bi/billpage/osx/bin/gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c9000
mach_mapstart: 0x5f9000
heap_end: 0x5f9000
core_end: 0x5f9000
mach_brkpt: 0x5f9000
mach_maplimit: 0x201c9000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0xf000 rw rwx (no zone)
0x1d8000 0x421000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0x430000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x75e000
Lowest offset of all sections in __TEXT segment: 0xc30
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c8000
__text 0x1c30 0x1ad804
__picsymbol_stub 0x1af434 0x1998
__symbol_stub 0x1b0dcc 0
__cstring 0x1b0dcc 0x16110
__literal4 0x1c6edc 0x18
__literal8 0x1c6ef8 0x108
__const 0x1c7000 0x1f9c
__eh_frame 0x1c8f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c9000 0x430000
__data 0x1c9000 0xaee4
__la_symbol_ptr 0x1d3ee4 0x2d8
__nl_symbol_ptr 0x1d41bc 0x9e0
__dyld 0x1d4b9c 0x1c
__const 0x1d4bb8 0x2748
__bss 0x1d7300 0x9340
__common 0x1e0640 0x418970
3 LC_SEGMENT 0x38 __LINKEDIT 0x5f9000 0x165000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c8000 (sz: 0x1c8000)
Writing segment __DATA at 0x1c8000 - 0x1d7000 (sz: 0xf000)
section __data at 0x1c8000 - 0x1d2ee4 (sz: 0xaee4)
section __la_symbol_ptr at 0x1d2ee4 - 0x1d31bc (sz: 0x2d8)
section __nl_symbol_ptr at 0x1d31bc - 0x1d3b9c (sz: 0x9e0)
section __dyld at 0x1d3b9c - 0x1d3bb8 (sz: 0x1c)
section __const at 0x1d3bb8 - 0x1d6300 (sz: 0x2748)
section __bss at 0x1d6300 - 0x1df640 (sz: 0x9340)
section __common at 0x1df640 - 0x5f7fb0 (sz: 0x418970)
Writing segment __DATA at 0x5f8000 - 0x5f8000 (sz: 0)
WGCL (GNU Common Lisp) April 1994 131072 pages
Post by Page, Bill
If I intervene and make Axiom use the original 'saved_gcl' to build
'bootsys' instead of using 'lisp', then the 'postpar.8' problem does
not occur and gcl finds the .o files anyway, as expected.
This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result images also
-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys
Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.
A test image of gcl created by
$ gcl
(si:save-system "test-image")
(quit)
is actually *larger* than the original saved_gcl.
-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image
Are all these problems related?
Any thing you can suggest would be greatly appreciated.
I also suspect compiler::link failure. It is also odd that
save-system images are so much bigger. Here is the tiny difference on
ls -l /usr/lib/gcl-2.6.7/unixport/saved_gcl
-rwxr-xr-x 1 root root 9329131 Oct 18 13:43
/usr/lib/gcl-2.6.7/unixport/saved_gcl
/usr/lib/gcl-2.6.7/unixport/saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 18 2006 13:40:07
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE
BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Page, Bill
(si::save-system "/tmp/ff")
ls -l /tmp/ff
-rwxr-x--- 1 camm camm 9333267 Oct 18 16:25 /tmp/ff
compiler::link should be no smaller than saved_gcl. The raw files are
explicitly deleted as named and output by gcc -- the .tmp extension
appears non-std and might be expected to persist.
I'd make two images, one with
(si::save-system "foo")
and the other with
(compiler::link nil "bar")
And then in each, do a few tests, including looking at
si::*load-types*.
Ok, here are the result of your suggested tests below:

--------------

ppc-osx3:~/osx/axiom.build-improvements $ echo '(si::save-system "foo")' |
gcl > foo.log
ppc-osx3:~/osx/axiom.build-improvements $ echo '(compiler::link nil "bar")'
| gcl > bar.log
ppc-osx3:~/osx/axiom.build-improvements $ ls -l foo bar
-rwxr-xr-x 1 billpage 100 13029844 Oct 21 15:06 bar
-rwxr-xr-x 1 billpage 100 23708096 Oct 21 15:05 foo

ppc-osx3:~/osx/axiom.build-improvements $ cat foo.log

GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x16f8 0x1aafc8
__picsymbol_stub 0x1ac6c0 0x18e4
__symbol_stub 0x1adfa4 0
__cstring 0x1adfa4 0x15f5c
__literal4 0x1c3f00 0x18
__literal8 0x1c3f18 0x108
__const 0x1c4020 0x1f9c
__eh_frame 0x1c5fbc 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d68
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0x517000
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f48 (sz: 0x416d68)
Writing segment __DATA at 0x5f4000 - 0xb0c000 (sz: 0x518000)
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0 (sz: 0x1641c0)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header


ppc-osx3:~/osx/axiom.build-improvements $ cat bar.log

GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0x5f5000
core_end: 0x5f5000
mach_brkpt: 0x5f5000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0xf000 rw rwx (no zone)
0x1d6000 0x41f000 rw rwx (no zone)
0x5f5000 0x165000 r rwx (no zone)
0x75a000 0x40000 rw rwx (no zone)
0x79a000 0x40000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x165000 r rwx (no zone)
0x75a000 0x40000 rw rwx (no zone)
0x79a000 0x40000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x75a000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x38 __LINKEDIT 0x5f5000 0x165000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x1d5000 (sz: 0xf000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38 (sz: 0x41GCL
(GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/axiom.build-improvements/raw
_bar.tmp ..
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_autoload.lsp
NIL
#<"COMPILER" package>
#<"SLOOP" package>
#<"SERROR" package>
#<"ANSI-LOOP" package>
#<"DEFPACKAGE" package>
#<"TK" package>
#<"SYSTEM" package>

SYSTEM>
*COMMAND-ARGS*

SYSTEM>Initializing gcl_predlib.o
Initializing gcl_setf.o
Initializing gcl_arraylib.o
Initializing gcl_assert.o
Initializing gcl_defstruct.o
Initializing gcl_describe.o
Initializing gcl_iolib.o
Initializing gcl_listlib.o
Initializing gcl_mislib.o
Initializing gcl_numlib.o
Initializing gcl_packlib.o
Initializing gcl_seq.o
Initializing gcl_seqlib.o
Initializing gcl_trace.o
Initializing gcl_sloop.o
Initializing gcl_serror.o
Initializing gcl_destructuring_bind.o
Initializing gcl_loop.o
Initializing gcl_defpackage.o
Initializing gcl_make_defpackage.o
Initializing gcl_cmpinline.o
Initializing gcl_cmputil.o
Initializing gcl_debug.o
Initializing gcl_info.o
Initializing gcl_cmptype.o
Initializing gcl_cmpbind.o
Initializing gcl_cmpblock.o
Initializing gcl_cmpcall.o
Initializing gcl_cmpcatch.o
Initializing gcl_cmpenv.o
Initializing gcl_cmpeval.o
Initializing gcl_cmpflet.o
Initializing gcl_cmpfun.o
Initializing gcl_cmpif.o
Initializing gcl_cmplabel.o
Initializing gcl_cmplam.o
Initializing gcl_cmplet.o
Initializing gcl_cmploc.o
Initializing gcl_cmpmap.o
Initializing gcl_cmpmulti.o
Initializing gcl_cmpspecial.o
Initializing gcl_cmptag.o
Initializing gcl_cmptop.o
Initializing gcl_cmpvar.o
Initializing gcl_cmpvs.o
Initializing gcl_cmpwt.o

Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys-proclaim.lis
p
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys-proclaim.lis
p
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/sys-proclaim.
lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/sys-proclaim.
lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/tk-package.ls
p
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/tk-package.ls
p
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpmain.l
sp
Warning: COMPILE-FILE is being redefined.
Warning: COMPILE is being redefined.
Warning: DISASSEMBLE is being redefined.
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpmain.l
sp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_lfun_list
.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_lfun_list
.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpopt.ls
p
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpopt.ls
p
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_auto_new.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_auto_new.lsp

T
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb09000
core_end: 0xb0a000
mach_brkpt: 0x57df000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x2032c000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0
4 LC_SEGMENT 0x38 __LINKEDIT 0x201c7000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38 (sz: 0x416d58)
Writing segment __DATA at 0x5f4000 - 0xb09000 (sz: 0x515000)
Writing segment __LINKEDIT at 0xb09000 - 0xc6d1d4 (sz: 0x1641d4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
3948 unused bytes follow Mach-O header

"bar"

ppc-osx3:~/osx/axiom.build-improvements $ ./foo
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
si::*load-types*
(".o" ".lsp" ".lisp")
(+ 1 1)
2
(quit)
ppc-osx3:~/osx/axiom.build-improvements $ ./bar
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
si::*load-types*
(".o" ".lsp" ".lisp")
(+ 1 1)
2
(quit)
ppc-osx3:~/osx/axiom.build-improvements $

-----------

Besides the difference in size in the images, I don't see any
other visible problems. Does the output from the save-system
and compiler::link help? I have no idea what it should look
like.
Lastly, you all in the axiom world might like to know that I'm about
to release an HOL88 Debian package build atop GCL. In addition to
providing an alternate theorem proving environment, one also has the
ML language built into the same image for potential use by axiom.
More on this later.
That sounds very interesting.

I think we need to move this part of the message to a more conspicuous
place. :-)

Thanks.

Regards,
Bill Page.
Camm Maguire
2006-10-23 14:23:25 UTC
Permalink
Greetings!
Post by Bill Page
Camm,
Greetings! Just checking that my last message hee was not lost.
I was a bit confused because the message that you quote below is
my reply to you not your last message. :-) But anyway I presume you
Yes, thanks!
Post by Bill Page
...
Sigh. I suppose reconfigured here? The binutils configure scripts
do look for msgfmt. I'm surprised they don't step around a missing
one, or at least bomb. What does your binutils configure output say
in this regard?
I am not sure what you are asking. I showed out the partial output
from gcl-2.6.8pre/binutils/bfd/config.log below.
Post by Page, Bill
---------
Invocation command line was
$ ./configure --with-included-gettext
But apparently recursive makefile in bfd/po does not make
use of the included gettext. Maybe this is a binutils bug?
When I looked further in this log file it showed that inspite of
--with-included-gettext, the configure script also found the msgfmt
in my local bin directory. I didn't understand this so I tried to
reproduce the result but first I removed all the gettext and msgfmt
from by local bin, but left it in the path in order to use the
replacement for sed.
When I re-ran the gcl build it ran properly to completion without
any error. Hmmmm... don't know. Can't reproduce. So scrap this one.
Must have been my mistake.
OK great! But Gaby's suggestion of --disable-nls might also work --
to pressed for time to get this in unless it is really needed.
Post by Bill Page
...
Post by Page, Bill
But see later in the message - I apparently have a problem with
__srget.
There is a notorious platform specific _ name mangling issue here.
See the LEADING_UNDERSCORE variable.
...
Post by Page, Bill
Thank you. I look forward to a finally finalized 2.6.8. The
evoluton of 2.6.8pre is causing us a little consternaton in
the current Axiom source distribution... :-)
My apologies. So many moving parts. I have to get everything synched
on one image, however, if we want these apps in Etch. And there have
been so many gcc et. al. issues.
BTW, are we not updating
http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/
anymore? Is there a latest official tarball somewhere for Etch (eta
this December)? Having a simple webpage with the filenames in some
sort of alphabetical/cronological sort order lets me automatically
know when the Debian package needs updating.
One no one has been created any new tarballs lately. The latest version
in Axiom Gold is patch-50 but I don't think Tim created a tarball when
he release the patch. :-(
OK. As you might know, Debian is trying to release Etch in December.
I'm skeptical, but we need to be ready. I need to get all the gcl
packages in their current state back into testing as they were thrown
out due to a transient gcc on some platforms (it appears). There
might be time for another source update if everything goes smoothly.
Post by Bill Page
Post by Page, Bill
...
Something is strange about thid symbol "___srget" with the 3
underscore characters, I think??? The name "__srget" with 2
underscore characters is properly defined in /usr/include/stdio.h
I don't understand what is going on here.
OK, your linker is prepending an underscore, and apparently
LEADING_UNDERSCORE was improperly set. Could you investigate?
I tried to track this down. LEADING_UNDERSCORE is set to 1, which
seems to be correct when I use nm to look at the symbols in the
test file compiled by the gcl configure script. The raw symbol
"___srget" does have 3 underscores (two in the original name), and
cos appears as "_cos" etc. Everything works fine during the Axiom
build for quite a while (up to the start of the building interpsys)
until the
Error: Undefined symbol "___srget"
message appears. I would have presumed that this symbol would have
been needed long before this failure occured. I rather suspsect that
this error is a consequence of some deeper but silent problem, e.g.
failed compiler::link?
OK here is a simple test (asusming this symbol comes from getc() on
the mac:

foo.l:
(defun foo nil (with-open-file (s "/tmp/foo") (read-byte s)))

gcl
Post by Bill Page
(compile-file "foo.l")
(load "foo.o")
(bye)
nm foo.o |grep srget
Post by Bill Page
There may also be a C compiler switch for this. Is this gcc?
Yes it is
$ gcc --version
gcc (GCC) 3.1 20020420 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
What sort of switch? How/when should I set it?
Lets try the above first.
Post by Bill Page
Post by Page, Bill
Also prior to compiling depsys, bootsys was already successfully
created however it did have one oddity. The original Axiom load
commands like ')load postpar' run during building depsys fails
with an error message like "'postpar.8' does not exist" (Yes, that's
the digit 8 after the dot.). If I change the command to include the
.o like this: ')load postpar.o' everything seems fine and depsys
is built.
bootsys itself is actually built form a copy of gcl called 'lisp'
that is created using compiler::link. The 'lisp' image includes
several Axiom specific external routines. I.e.
echo '(compiler::link nil
"/home/users/b/bi/billpage/osx/axiom.build-improvements/build/
powerpc-ap
Post by Page, Bill
ple-darwin6.8/bin/lisp" ' \
' (format nil "(progn (let ((*load-path* (cons ~S
*load-path*))'\
' (si::*load-types* ~S))' \
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on t))' \
' (setq compiler::*default-system-p* t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
'
"/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/..
/./src/lib
Post by Page, Bill
/cfuns-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/../
./src/lib/
Post by Page, Bill
sockio-c.o' \
'
/home/users/b/bi/billpage/osx/axiom.build-improvements/lsp/../
./src/lib/
Post by Page, Bill
libspad.a")' \
| /home/users/b/bi/billpage/osx/bin/gcl
Can you post the output from this?
| /home/users/b/bi/billpage/osx/bin/gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c9000
mach_mapstart: 0x5f9000
heap_end: 0x5f9000
core_end: 0x5f9000
mach_brkpt: 0x5f9000
mach_maplimit: 0x201c9000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0xf000 rw rwx (no zone)
0x1d8000 0x421000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0x430000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x75e000
Lowest offset of all sections in __TEXT segment: 0xc30
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c8000
__text 0x1c30 0x1ad804
__picsymbol_stub 0x1af434 0x1998
__symbol_stub 0x1b0dcc 0
__cstring 0x1b0dcc 0x16110
__literal4 0x1c6edc 0x18
__literal8 0x1c6ef8 0x108
__const 0x1c7000 0x1f9c
__eh_frame 0x1c8f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c9000 0x430000
__data 0x1c9000 0xaee4
__la_symbol_ptr 0x1d3ee4 0x2d8
__nl_symbol_ptr 0x1d41bc 0x9e0
__dyld 0x1d4b9c 0x1c
__const 0x1d4bb8 0x2748
__bss 0x1d7300 0x9340
__common 0x1e0640 0x418970
3 LC_SEGMENT 0x38 __LINKEDIT 0x5f9000 0x165000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c8000 (sz: 0x1c8000)
Writing segment __DATA at 0x1c8000 - 0x1d7000 (sz: 0xf000)
section __data at 0x1c8000 - 0x1d2ee4 (sz: 0xaee4)
section __la_symbol_ptr at 0x1d2ee4 - 0x1d31bc (sz: 0x2d8)
section __nl_symbol_ptr at 0x1d31bc - 0x1d3b9c (sz: 0x9e0)
section __dyld at 0x1d3b9c - 0x1d3bb8 (sz: 0x1c)
section __const at 0x1d3bb8 - 0x1d6300 (sz: 0x2748)
section __bss at 0x1d6300 - 0x1df640 (sz: 0x9340)
section __common at 0x1df640 - 0x5f7fb0 (sz: 0x418970)
Writing segment __DATA at 0x5f8000 - 0x5f8000 (sz: 0)
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in your
compiler::link output below?
Post by Bill Page
Post by Page, Bill
If I intervene and make Axiom use the original 'saved_gcl' to build
'bootsys' instead of using 'lisp', then the 'postpar.8' problem does
not occur and gcl finds the .o files anyway, as expected.
This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result images also
-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys
Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.
A test image of gcl created by
$ gcl
(si:save-system "test-image")
(quit)
is actually *larger* than the original saved_gcl.
-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image
Are all these problems related?
Any thing you can suggest would be greatly appreciated.
I also suspect compiler::link failure. It is also odd that
save-system images are so much bigger. Here is the tiny difference on
ls -l /usr/lib/gcl-2.6.7/unixport/saved_gcl
-rwxr-xr-x 1 root root 9329131 Oct 18 13:43
/usr/lib/gcl-2.6.7/unixport/saved_gcl
/usr/lib/gcl-2.6.7/unixport/saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 18 2006 13:40:07
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE
BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Page, Bill
(si::save-system "/tmp/ff")
ls -l /tmp/ff
-rwxr-x--- 1 camm camm 9333267 Oct 18 16:25 /tmp/ff
compiler::link should be no smaller than saved_gcl. The raw files are
explicitly deleted as named and output by gcc -- the .tmp extension
appears non-std and might be expected to persist.
I'd make two images, one with
(si::save-system "foo")
and the other with
(compiler::link nil "bar")
And then in each, do a few tests, including looking at
si::*load-types*.
--------------
ppc-osx3:~/osx/axiom.build-improvements $ echo '(si::save-system "foo")' |
gcl > foo.log
ppc-osx3:~/osx/axiom.build-improvements $ echo '(compiler::link nil "bar")'
| gcl > bar.log
ppc-osx3:~/osx/axiom.build-improvements $ ls -l foo bar
-rwxr-xr-x 1 billpage 100 13029844 Oct 21 15:06 bar
-rwxr-xr-x 1 billpage 100 23708096 Oct 21 15:05 foo
ppc-osx3:~/osx/axiom.build-improvements $ cat foo.log
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x16f8 0x1aafc8
__picsymbol_stub 0x1ac6c0 0x18e4
__symbol_stub 0x1adfa4 0
__cstring 0x1adfa4 0x15f5c
__literal4 0x1c3f00 0x18
__literal8 0x1c3f18 0x108
__const 0x1c4020 0x1f9c
__eh_frame 0x1c5fbc 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d68
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0x517000
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f48 (sz: 0x416d68)
Writing segment __DATA at 0x5f4000 - 0xb0c000 (sz: 0x518000)
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0 (sz: 0x1641c0)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header
ppc-osx3:~/osx/axiom.build-improvements $ cat bar.log
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
What I don't understand is this output appearing twice. This is the
place it appears not to belong. Is this not output only from unexec?
Post by Bill Page
mach_mapstart: 0x5f5000
heap_end: 0x5f5000
core_end: 0x5f5000
mach_brkpt: 0x5f5000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0xf000 rw rwx (no zone)
0x1d6000 0x41f000 rw rwx (no zone)
0x5f5000 0x165000 r rwx (no zone)
0x75a000 0x40000 rw rwx (no zone)
0x79a000 0x40000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x165000 r rwx (no zone)
0x75a000 0x40000 rw rwx (no zone)
0x79a000 0x40000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x75a000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x38 __LINKEDIT 0x5f5000 0x165000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x1d5000 (sz: 0xf000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38 (sz: 0x41GCL
(GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/axiom.build-improvements/raw
_bar.tmp ..
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_autoload.lsp
NIL
#<"COMPILER" package>
#<"SLOOP" package>
#<"SERROR" package>
#<"ANSI-LOOP" package>
#<"DEFPACKAGE" package>
#<"TK" package>
#<"SYSTEM" package>
SYSTEM>
*COMMAND-ARGS*
SYSTEM>Initializing gcl_predlib.o
Initializing gcl_setf.o
Initializing gcl_arraylib.o
Initializing gcl_assert.o
Initializing gcl_defstruct.o
Initializing gcl_describe.o
Initializing gcl_iolib.o
Initializing gcl_listlib.o
Initializing gcl_mislib.o
Initializing gcl_numlib.o
Initializing gcl_packlib.o
Initializing gcl_seq.o
Initializing gcl_seqlib.o
Initializing gcl_trace.o
Initializing gcl_sloop.o
Initializing gcl_serror.o
Initializing gcl_destructuring_bind.o
Initializing gcl_loop.o
Initializing gcl_defpackage.o
Initializing gcl_make_defpackage.o
Initializing gcl_cmpinline.o
Initializing gcl_cmputil.o
Initializing gcl_debug.o
Initializing gcl_info.o
Initializing gcl_cmptype.o
Initializing gcl_cmpbind.o
Initializing gcl_cmpblock.o
Initializing gcl_cmpcall.o
Initializing gcl_cmpcatch.o
Initializing gcl_cmpenv.o
Initializing gcl_cmpeval.o
Initializing gcl_cmpflet.o
Initializing gcl_cmpfun.o
Initializing gcl_cmpif.o
Initializing gcl_cmplabel.o
Initializing gcl_cmplam.o
Initializing gcl_cmplet.o
Initializing gcl_cmploc.o
Initializing gcl_cmpmap.o
Initializing gcl_cmpmulti.o
Initializing gcl_cmpspecial.o
Initializing gcl_cmptag.o
Initializing gcl_cmptop.o
Initializing gcl_cmpvar.o
Initializing gcl_cmpvs.o
Initializing gcl_cmpwt.o
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys-proclaim.lis
p
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys-proclaim.lis
p
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/sys-proclaim.
lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/sys-proclaim.
lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/tk-package.ls
p
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/tk-package.ls
p
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpmain.l
sp
Warning: COMPILE-FILE is being redefined.
Warning: COMPILE is being redefined.
Warning: DISASSEMBLE is being redefined.
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpmain.l
sp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_lfun_list
.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_lfun_list
.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpopt.ls
p
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpopt.ls
p
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_auto_new.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_auto_new.lsp
T
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb09000
core_end: 0xb0a000
mach_brkpt: 0x57df000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x2032c000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0
4 LC_SEGMENT 0x38 __LINKEDIT 0x201c7000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38 (sz: 0x416d58)
Writing segment __DATA at 0x5f4000 - 0xb09000 (sz: 0x515000)
Writing segment __LINKEDIT at 0xb09000 - 0xc6d1d4 (sz: 0x1641d4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
3948 unused bytes follow Mach-O header
"bar"
ppc-osx3:~/osx/axiom.build-improvements $ ./foo
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
si::*load-types*
(".o" ".lsp" ".lisp")
(+ 1 1)
2
(quit)
ppc-osx3:~/osx/axiom.build-improvements $ ./bar
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
si::*load-types*
(".o" ".lsp" ".lisp")
(+ 1 1)
2
(quit)
ppc-osx3:~/osx/axiom.build-improvements $
-----------
Besides the difference in size in the images, I don't see any
other visible problems. Does the output from the save-system
and compiler::link help? I have no idea what it should look
like.
Might be of use seeing if both images can compile and load files,
especially the test file foo.l above.
Post by Bill Page
Lastly, you all in the axiom world might like to know that I'm about
to release an HOL88 Debian package build atop GCL. In addition to
providing an alternate theorem proving environment, one also has the
ML language built into the same image for potential use by axiom.
More on this later.
That sounds very interesting.
I think we need to move this part of the message to a more conspicuous
place. :-)
OK reply separately.

Take care,
Post by Bill Page
Thanks.
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-21 22:21:02 UTC
Permalink
Post by Camm Maguire
...
Lastly, you all in the axiom world might like to know that I'm about
to release an HOL88 Debian package build atop GCL. In addition to
providing an alternate theorem proving environment, one also has the
ML language built into the same image for potential use by axiom.
More on this later.
I would like to hear more about how to build Axiom with ML built
in to the same image!

Thanks.

Bill Page.
Camm Maguire
2006-10-23 21:02:58 UTC
Permalink
Greetings!
Post by Bill Page
Post by Camm Maguire
...
Lastly, you all in the axiom world might like to know that I'm about
to release an HOL88 Debian package build atop GCL. In addition to
providing an alternate theorem proving environment, one also has the
ML language built into the same image for potential use by axiom.
More on this later.
I would like to hear more about how to build Axiom with ML built
in to the same image!
Am happy to announce the submission today of a set of packages for
HOL88, built atop GCL, to Debian.

You can see the packages at:

http://people.debian.org/~camm

Until these are accepted by Debian, after which time one can retrieve
the source and binaries via apt-get, one can:

1) build from source with current gcl (2.6.8 or head) in path:
dpkg-source -x hol88*dsc
cd hol88-2.02.19940316
debian/rules build

2) install the binaries the usual way:
(as root) dpkg -i *.deb

3) unpack in a local directory:

for i in *.deb ; do dpkg --fsys-tarfile $i | tar xf - ; done

(here you will likely have to 'install `new_directory`;;' in the
unpackaged usr/lib/hol88-2.02.19940316/hol image)
(You can save a new image with 'lisp `(ml-save "new_image")`;;')

I am far from an expert on the evolution of ML, but my preliminary
understanding is that this ML was one of the main progenators of
today's family of ML's. Indeed, the authors of the HOL system seemed
to have much to do with the invention of the language itself. I
believe this dialect was referred to as 'Classic ML'. I do not know
how it relates to standard ML, but I bet it is quite close. In any
case, its original implementation was written in lisp, and
conventionally compiled with akcl, the ancestor to GCL. The build
still works, yielding not only an ML in lisp environment, but a
substantial theorem proving environment with a large library in its
own right.

Axiom has discussed in the past incorporating ACL2 as a means to
verify its algorithms. HOL88 should provide yet another such
opportunity in addition to providing ML facilities within axiom.

Please keep in mind that the packages, and the facility in general, are
still in an early stage of development. In particular, HOL88 loads
right into the user package, so is not well isolated.

Take care,
Post by Bill Page
Thanks.
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-23 15:00:06 UTC
Permalink
Camm,
Post by Camm Maguire
...
Post by Bill Page
I tried to track this down. LEADING_UNDERSCORE is set to 1, which
seems to be correct when I use nm to look at the symbols in the
test file compiled by the gcl configure script. The raw symbol
"___srget" does have 3 underscores (two in the original name), and
cos appears as "_cos" etc. Everything works fine during the Axiom
build for quite a while (up to the start of the building interpsys)
until the
Error: Undefined symbol "___srget"
message appears. I would have presumed that this symbol would have
been needed long before this failure occured. I rather suspsect that
this error is a consequence of some deeper but silent problem, e.g.
failed compiler::link?
OK here is a simple test (asusming this symbol comes from getc()
(defun foo nil (with-open-file (s "/tmp/foo") (read-byte s)))
gcl
Post by Bill Page
(compile-file "foo.l")
(load "foo.o")
(bye)
nm foo.o |grep srget
Here's the result:

--------

ppc-osx3:~/osx/new/gcl-2.6.8pre $ vi foo.l
ppc-osx3:~/osx/new/gcl-2.6.8pre $ gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
(compile-file "foo.l")
Compiling foo.l.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.lisp.
#p"foo.o"
Post by Camm Maguire
(load "foo.o")
Loading foo.o

Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Bill Page
(quit)
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm foo.o
U _Cnil_body
U _Dotnil_body
U _FEwrong_type_argument
U _FIXtemp
00000000 t _L1
U _Lclose
000004fc d _Lnk1
000004c8 t _LnkT1
000004f0 d _VVi
U ___srget
U _bds_top
U _call_or_link
U _do_init
U _frs_limit
U _frs_overflow
U _frs_top
U _ihs_top
U _in_signal_handler
000004ac T _init_code
U _lex_env
U _make_cons
U _make_fixnum1
U _nlj_active
U _nlj_fr
U _nlj_tag
U _read_byte1
U _sLlist
00000500 d _s_my_dot.0
U _setjmp
U _small_fixnum_table
U _unwind
U _vs_base
U _vs_limit
U _vs_overflow
U _vs_top
U dyld_stub_binding_helper
U restFP
U saveFP

-------

But I see the this symbol *is* known to the gcl image.

ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm unixport/saved_gcl | grep srget
U ___srget

What is wrong?
Post by Camm Maguire
...
Post by Bill Page
| /home/users/b/bi/billpage/osx/bin/gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Post by Bill Page
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c9000
mach_mapstart: 0x5f9000
heap_end: 0x5f9000
core_end: 0x5f9000
mach_brkpt: 0x5f9000
mach_maplimit: 0x201c9000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0xf000 rw rwx (no zone)
0x1d8000 0x421000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0x430000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x75e000
Lowest offset of all sections in __TEXT segment: 0xc30
--- List of Load Commands in Input File ---
no cmd cmdsize name address
size
Post by Bill Page
0 LC_SEGMENT 0x38 __PAGEZERO 0
0x1000
Post by Bill Page
1 LC_SEGMENT 0x258 __TEXT 0x1000
0x1c8000
Post by Bill Page
__text 0x1c30
0x1ad804
Post by Bill Page
__picsymbol_stub 0x1af434
0x1998
Post by Bill Page
__symbol_stub 0x1b0dcc
0
Post by Bill Page
__cstring 0x1b0dcc
0x16110
Post by Bill Page
__literal4 0x1c6edc
0x18
Post by Bill Page
__literal8 0x1c6ef8
0x108
Post by Bill Page
__const 0x1c7000
0x1f9c
Post by Bill Page
__eh_frame 0x1c8f9c
0x60
Post by Bill Page
2 LC_SEGMENT 0x214 __DATA 0x1c9000
0x430000
Post by Bill Page
__data 0x1c9000
0xaee4
Post by Bill Page
__la_symbol_ptr 0x1d3ee4
0x2d8
Post by Bill Page
__nl_symbol_ptr 0x1d41bc
0x9e0
Post by Bill Page
__dyld 0x1d4b9c
0x1c
Post by Bill Page
__const 0x1d4bb8
0x2748
Post by Bill Page
__bss 0x1d7300
0x9340
Post by Bill Page
__common 0x1e0640
0x418970
Post by Bill Page
3 LC_SEGMENT 0x38 __LINKEDIT 0x5f9000
0x165000
Post by Bill Page
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Post by Bill Page
Writing segment __TEXT at 0 - 0x1c8000
(sz: 0x1c8000)
Post by Bill Page
Writing segment __DATA at 0x1c8000 - 0x1d7000
(sz: 0xf000)
Post by Bill Page
section __data at 0x1c8000 - 0x1d2ee4
(sz: 0xaee4)
Post by Bill Page
section __la_symbol_ptr at 0x1d2ee4 - 0x1d31bc
(sz: 0x2d8)
Post by Bill Page
section __nl_symbol_ptr at 0x1d31bc - 0x1d3b9c
(sz: 0x9e0)
Post by Bill Page
section __dyld at 0x1d3b9c - 0x1d3bb8
(sz: 0x1c)
Post by Bill Page
section __const at 0x1d3bb8 - 0x1d6300
(sz: 0x2748)
Post by Bill Page
section __bss at 0x1d6300 - 0x1df640
(sz: 0x9340)
Post by Bill Page
section __common at 0x1df640 - 0x5f7fb0
(sz: 0x418970)
Post by Bill Page
Writing segment __DATA at 0x5f8000 - 0x5f8000
(sz: 0)
Post by Bill Page
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in your
compiler::link output below?
It stops there.
Post by Camm Maguire
Post by Bill Page
Post by Page, Bill
If I intervene and make Axiom use the original
'saved_gcl' to build
Post by Bill Page
Post by Page, Bill
'bootsys' instead of using 'lisp', then the 'postpar.8'
problem does
Post by Bill Page
Post by Page, Bill
not occur and gcl finds the .o files anyway, as expected.
This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result
images also
Post by Bill Page
Post by Page, Bill
-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys
Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.
A test image of gcl created by
$ gcl
(si:save-system "test-image")
(quit)
is actually *larger* than the original saved_gcl.
-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image
Are all these problems related?
Any thing you can suggest would be greatly appreciated.
I also suspect compiler::link failure. It is also odd that
save-system images are so much bigger. Here is the tiny
difference on
Post by Bill Page
ls -l /usr/lib/gcl-2.6.7/unixport/saved_gcl
-rwxr-xr-x 1 root root 9329131 Oct 18 13:43
/usr/lib/gcl-2.6.7/unixport/saved_gcl
/usr/lib/gcl-2.6.7/unixport/saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 18 2006 13:40:07
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE
BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Page, Bill
(si::save-system "/tmp/ff")
ls -l /tmp/ff
-rwxr-x--- 1 camm camm 9333267 Oct 18 16:25 /tmp/ff
compiler::link should be no smaller than saved_gcl. The
raw files are
Post by Bill Page
explicitly deleted as named and output by gcc -- the .tmp
extension
Post by Bill Page
appears non-std and might be expected to persist.
I'd make two images, one with
(si::save-system "foo")
and the other with
(compiler::link nil "bar")
And then in each, do a few tests, including looking at
si::*load-types*.
--------------
ppc-osx3:~/osx/axiom.build-improvements $ echo
'(si::save-system "foo")' |
Post by Bill Page
gcl > foo.log
ppc-osx3:~/osx/axiom.build-improvements $ echo
'(compiler::link nil "bar")'
Post by Bill Page
| gcl > bar.log
ppc-osx3:~/osx/axiom.build-improvements $ ls -l foo bar
-rwxr-xr-x 1 billpage 100 13029844 Oct 21 15:06 bar
-rwxr-xr-x 1 billpage 100 23708096 Oct 21 15:05 foo
ppc-osx3:~/osx/axiom.build-improvements $ cat foo.log
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Post by Bill Page
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address
size
Post by Bill Page
0 LC_SEGMENT 0x38 __PAGEZERO 0
0x1000
Post by Bill Page
1 LC_SEGMENT 0x258 __TEXT 0x1000
0x1c6000
Post by Bill Page
__text 0x16f8
0x1aafc8
Post by Bill Page
__picsymbol_stub 0x1ac6c0
0x18e4
Post by Bill Page
__symbol_stub 0x1adfa4
0
Post by Bill Page
__cstring 0x1adfa4
0x15f5c
Post by Bill Page
__literal4 0x1c3f00
0x18
Post by Bill Page
__literal8 0x1c3f18
0x108
Post by Bill Page
__const 0x1c4020
0x1f9c
Post by Bill Page
__eh_frame 0x1c5fbc
0x60
Post by Bill Page
2 LC_SEGMENT 0x214 __DATA 0x1c7000
0x42e000
Post by Bill Page
__data 0x1c7000
0xaec4
Post by Bill Page
__la_symbol_ptr 0x1d1ec4
0x2c4
Post by Bill Page
__nl_symbol_ptr 0x1d2188
0x9c8
Post by Bill Page
__dyld 0x1d2b50
0x1c
Post by Bill Page
__const 0x1d2b6c
0x2748
Post by Bill Page
__bss 0x1d52b8
0x8f28
Post by Bill Page
__common 0x1de1e0
0x416d68
Post by Bill Page
3 LC_SEGMENT 0x7c __DATA 0x5f5000
0x1fbd2000
Post by Bill Page
__data 0x5f5000
0x517000
Post by Bill Page
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000
0x165000
Post by Bill Page
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Post by Bill Page
Writing segment __TEXT at 0 - 0x1c6000
(sz: 0x1c6000)
Post by Bill Page
Writing segment __DATA at 0x1c6000 - 0x5f4000
(sz: 0x42e000)
Post by Bill Page
section __data at 0x1c6000 - 0x1d0ec4
(sz: 0xaec4)
Post by Bill Page
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188
(sz: 0x2c4)
Post by Bill Page
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50
(sz: 0x9c8)
Post by Bill Page
section __dyld at 0x1d1b50 - 0x1d1b6c
(sz: 0x1c)
Post by Bill Page
section __const at 0x1d1b6c - 0x1d42b4
(sz: 0x2748)
Post by Bill Page
section __bss at 0x1d42b8 - 0x1dd1e0
(sz: 0x8f28)
Post by Bill Page
section __common at 0x1dd1e0 - 0x5f3f48
(sz: 0x416d68)
Post by Bill Page
Writing segment __DATA at 0x5f4000 - 0xb0c000
(sz: 0x518000)
Post by Bill Page
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0
(sz: 0x1641c0)
Post by Bill Page
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header
ppc-osx3:~/osx/axiom.build-improvements $ cat bar.log
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Post by Bill Page
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
What I don't understand is this output appearing twice. This is the
place it appears not to belong. Is this not output only from unexec?
I don't know. How can I tell?
Post by Camm Maguire
...
Might be of use seeing if both images can compile and load files,
especially the test file foo.l above.
Same result as above:

---------

ppc-osx3:~/osx/axiom.build-improvements $ ./foo
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
(compile-file "foo.l")
Compiling foo.l.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.l.
#p"foo.o"
Post by Camm Maguire
(load "foo.o")
Loading foo.o

Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Bill Page
(quit)
ppc-osx3:~/osx/axiom.build-improvements $ ./bar
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
(compile-file "foo.l")
Compiling foo.l.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.l.
#p"foo.o"
Post by Camm Maguire
(load "foo.o")
Loading foo.o

Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Bill Page
(quit)
ppc-osx3:~/osx/axiom.build-improvements $

Regards,
Bill Page.
Camm Maguire
2006-10-23 19:53:01 UTC
Permalink
Greetings!
Post by Page, Bill
Camm,
Post by Camm Maguire
...
Post by Bill Page
I tried to track this down. LEADING_UNDERSCORE is set to 1, which
seems to be correct when I use nm to look at the symbols in the
test file compiled by the gcl configure script. The raw symbol
"___srget" does have 3 underscores (two in the original name), and
cos appears as "_cos" etc. Everything works fine during the Axiom
build for quite a while (up to the start of the building interpsys)
until the
Error: Undefined symbol "___srget"
message appears. I would have presumed that this symbol would have
been needed long before this failure occured. I rather suspsect that
this error is a consequence of some deeper but silent problem, e.g.
failed compiler::link?
OK here is a simple test (asusming this symbol comes from getc()
(defun foo nil (with-open-file (s "/tmp/foo") (read-byte s)))
gcl
Post by Bill Page
(compile-file "foo.l")
(load "foo.o")
(bye)
nm foo.o |grep srget
--------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ vi foo.l
ppc-osx3:~/osx/new/gcl-2.6.8pre $ gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
(compile-file "foo.l")
Compiling foo.l.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.lisp.
#p"foo.o"
Post by Camm Maguire
(load "foo.o")
Loading foo.o
Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Bill Page
(quit)
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm foo.o
U _Cnil_body
U _Dotnil_body
U _FEwrong_type_argument
U _FIXtemp
00000000 t _L1
U _Lclose
000004fc d _Lnk1
000004c8 t _LnkT1
000004f0 d _VVi
U ___srget
U _bds_top
U _call_or_link
U _do_init
U _frs_limit
U _frs_overflow
U _frs_top
U _ihs_top
U _in_signal_handler
000004ac T _init_code
U _lex_env
U _make_cons
U _make_fixnum1
U _nlj_active
U _nlj_fr
U _nlj_tag
U _read_byte1
U _sLlist
00000500 d _s_my_dot.0
U _setjmp
U _small_fixnum_table
U _unwind
U _vs_base
U _vs_limit
U _vs_overflow
U _vs_top
U dyld_stub_binding_helper
U restFP
U saveFP
-------
But I see the this symbol *is* known to the gcl image.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm unixport/saved_gcl | grep srget
U ___srget
What is wrong?
Here is says that saved_gcl *uses* the symbol, but does not provide
it. We need T ___srget.

Was our patch to o/makefile designed to remove ___srget from plt.h?
If so, this is the culprit. What was the reason if this is the case?
If not, we need to add code to plttest.c to get these symbols into
plt.h. If this makes any sense to you and you can tell me which is
the case, we can proceed from here.

The idea is that raw_gcl needs its own symbol for every symol that can
be written by the compiler/gcc into an object file to be loaded. If
symbols are in external libraries, e.g. cos() in libm, GCL compiles in
its own reference by taking the address in C

void *ref=cos;

This forces ldd to make a plt table, en effective trampoline, which
will be properly relocated at runtime by ld.so. Jumping to this
trampoline is sufficient to get us to where we need to go.

We also have an additional mechanism to parse the raw_map file to look
at the plt table explicitly if present. This is not very portable,
but the results are in si::*plt-table*.
Post by Page, Bill
Post by Camm Maguire
...
Post by Bill Page
| /home/users/b/bi/billpage/osx/bin/gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Post by Bill Page
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c9000
mach_mapstart: 0x5f9000
heap_end: 0x5f9000
core_end: 0x5f9000
mach_brkpt: 0x5f9000
mach_maplimit: 0x201c9000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0xf000 rw rwx (no zone)
0x1d8000 0x421000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c8000 r x rwx (no zone)
0x1c9000 0x430000 rw rwx (no zone)
0x5f9000 0x165000 r rwx (no zone)
0x75e000 0x40000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x75e000
Lowest offset of all sections in __TEXT segment: 0xc30
--- List of Load Commands in Input File ---
no cmd cmdsize name address
size
Post by Bill Page
0 LC_SEGMENT 0x38 __PAGEZERO 0
0x1000
Post by Bill Page
1 LC_SEGMENT 0x258 __TEXT 0x1000
0x1c8000
Post by Bill Page
__text 0x1c30
0x1ad804
Post by Bill Page
__picsymbol_stub 0x1af434
0x1998
Post by Bill Page
__symbol_stub 0x1b0dcc
0
Post by Bill Page
__cstring 0x1b0dcc
0x16110
Post by Bill Page
__literal4 0x1c6edc
0x18
Post by Bill Page
__literal8 0x1c6ef8
0x108
Post by Bill Page
__const 0x1c7000
0x1f9c
Post by Bill Page
__eh_frame 0x1c8f9c
0x60
Post by Bill Page
2 LC_SEGMENT 0x214 __DATA 0x1c9000
0x430000
Post by Bill Page
__data 0x1c9000
0xaee4
Post by Bill Page
__la_symbol_ptr 0x1d3ee4
0x2d8
Post by Bill Page
__nl_symbol_ptr 0x1d41bc
0x9e0
Post by Bill Page
__dyld 0x1d4b9c
0x1c
Post by Bill Page
__const 0x1d4bb8
0x2748
Post by Bill Page
__bss 0x1d7300
0x9340
Post by Bill Page
__common 0x1e0640
0x418970
Post by Bill Page
3 LC_SEGMENT 0x38 __LINKEDIT 0x5f9000
0x165000
Post by Bill Page
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Post by Bill Page
Writing segment __TEXT at 0 - 0x1c8000
(sz: 0x1c8000)
Post by Bill Page
Writing segment __DATA at 0x1c8000 - 0x1d7000
(sz: 0xf000)
Post by Bill Page
section __data at 0x1c8000 - 0x1d2ee4
(sz: 0xaee4)
Post by Bill Page
section __la_symbol_ptr at 0x1d2ee4 - 0x1d31bc
(sz: 0x2d8)
Post by Bill Page
section __nl_symbol_ptr at 0x1d31bc - 0x1d3b9c
(sz: 0x9e0)
Post by Bill Page
section __dyld at 0x1d3b9c - 0x1d3bb8
(sz: 0x1c)
Post by Bill Page
section __const at 0x1d3bb8 - 0x1d6300
(sz: 0x2748)
Post by Bill Page
section __bss at 0x1d6300 - 0x1df640
(sz: 0x9340)
Post by Bill Page
section __common at 0x1df640 - 0x5f7fb0
(sz: 0x418970)
Post by Bill Page
Writing segment __DATA at 0x5f8000 - 0x5f8000
(sz: 0)
Post by Bill Page
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in your
compiler::link output below?
It stops there.
OK, this is definitely strange. Could you please

(trace system open delete-file)

before the compiler::link and send me the output.
Post by Page, Bill
Post by Camm Maguire
Post by Bill Page
Post by Page, Bill
If I intervene and make Axiom use the original
'saved_gcl' to build
Post by Bill Page
Post by Page, Bill
'bootsys' instead of using 'lisp', then the 'postpar.8'
problem does
Post by Bill Page
Post by Page, Bill
not occur and gcl finds the .o files anyway, as expected.
This makes me suspicious that something subtle may be wrong with
the output of 'compiler:link'. The size of the result
images also
Post by Bill Page
Post by Page, Bill
-rwxr-xr-x 1 billpage 100 18362444 Oct 17 19:08 saved_gcl
...
-rwxr-xr-x 1 billpage 100 13072984 Oct 18 04:01 lisp
-rwxr-xr-x 1 billpage 100 19159640 Oct 18 04:01 bootsys
-rwxr-xr-x 1 billpage 100 7719512 Oct 18 04:01 raw_lisp.tmp
-rw-r--r-- 1 billpage 100 0 Oct 18 04:01 raw_lisp_map
-rwxr-xr-x 1 billpage 100 49588824 Oct 18 03:10 depsys
Remember that 'lisp' is create by 'compiler::link' from
saved_gcl plus some externals. Why is it smaller? Also the
"raw" files were left here don't look "normal" to me.
A test image of gcl created by
$ gcl
(si:save-system "test-image")
(quit)
is actually *larger* than the original saved_gcl.
-rwxr-xr-x 1 billpage 100 23699532 Oct 18 11:07 test-image
Are all these problems related?
Any thing you can suggest would be greatly appreciated.
I also suspect compiler::link failure. It is also odd that
save-system images are so much bigger. Here is the tiny
difference on
Post by Bill Page
ls -l /usr/lib/gcl-2.6.7/unixport/saved_gcl
-rwxr-xr-x 1 root root 9329131 Oct 18 13:43
/usr/lib/gcl-2.6.7/unixport/saved_gcl
/usr/lib/gcl-2.6.7/unixport/saved_gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 18 2006 13:40:07
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE
BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Page, Bill
(si::save-system "/tmp/ff")
ls -l /tmp/ff
-rwxr-x--- 1 camm camm 9333267 Oct 18 16:25 /tmp/ff
compiler::link should be no smaller than saved_gcl. The
raw files are
Post by Bill Page
explicitly deleted as named and output by gcc -- the .tmp
extension
Post by Bill Page
appears non-std and might be expected to persist.
I'd make two images, one with
(si::save-system "foo")
and the other with
(compiler::link nil "bar")
And then in each, do a few tests, including looking at
si::*load-types*.
--------------
ppc-osx3:~/osx/axiom.build-improvements $ echo
'(si::save-system "foo")' |
Post by Bill Page
gcl > foo.log
ppc-osx3:~/osx/axiom.build-improvements $ echo
'(compiler::link nil "bar")'
Post by Bill Page
| gcl > bar.log
ppc-osx3:~/osx/axiom.build-improvements $ ls -l foo bar
-rwxr-xr-x 1 billpage 100 13029844 Oct 21 15:06 bar
-rwxr-xr-x 1 billpage 100 23708096 Oct 21 15:05 foo
ppc-osx3:~/osx/axiom.build-improvements $ cat foo.log
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Post by Bill Page
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address
size
Post by Bill Page
0 LC_SEGMENT 0x38 __PAGEZERO 0
0x1000
Post by Bill Page
1 LC_SEGMENT 0x258 __TEXT 0x1000
0x1c6000
Post by Bill Page
__text 0x16f8
0x1aafc8
Post by Bill Page
__picsymbol_stub 0x1ac6c0
0x18e4
Post by Bill Page
__symbol_stub 0x1adfa4
0
Post by Bill Page
__cstring 0x1adfa4
0x15f5c
Post by Bill Page
__literal4 0x1c3f00
0x18
Post by Bill Page
__literal8 0x1c3f18
0x108
Post by Bill Page
__const 0x1c4020
0x1f9c
Post by Bill Page
__eh_frame 0x1c5fbc
0x60
Post by Bill Page
2 LC_SEGMENT 0x214 __DATA 0x1c7000
0x42e000
Post by Bill Page
__data 0x1c7000
0xaec4
Post by Bill Page
__la_symbol_ptr 0x1d1ec4
0x2c4
Post by Bill Page
__nl_symbol_ptr 0x1d2188
0x9c8
Post by Bill Page
__dyld 0x1d2b50
0x1c
Post by Bill Page
__const 0x1d2b6c
0x2748
Post by Bill Page
__bss 0x1d52b8
0x8f28
Post by Bill Page
__common 0x1de1e0
0x416d68
Post by Bill Page
3 LC_SEGMENT 0x7c __DATA 0x5f5000
0x1fbd2000
Post by Bill Page
__data 0x5f5000
0x517000
Post by Bill Page
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000
0x165000
Post by Bill Page
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Post by Bill Page
Writing segment __TEXT at 0 - 0x1c6000
(sz: 0x1c6000)
Post by Bill Page
Writing segment __DATA at 0x1c6000 - 0x5f4000
(sz: 0x42e000)
Post by Bill Page
section __data at 0x1c6000 - 0x1d0ec4
(sz: 0xaec4)
Post by Bill Page
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188
(sz: 0x2c4)
Post by Bill Page
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50
(sz: 0x9c8)
Post by Bill Page
section __dyld at 0x1d1b50 - 0x1d1b6c
(sz: 0x1c)
Post by Bill Page
section __const at 0x1d1b6c - 0x1d42b4
(sz: 0x2748)
Post by Bill Page
section __bss at 0x1d42b8 - 0x1dd1e0
(sz: 0x8f28)
Post by Bill Page
section __common at 0x1dd1e0 - 0x5f3f48
(sz: 0x416d68)
Post by Bill Page
Writing segment __DATA at 0x5f4000 - 0xb0c000
(sz: 0x518000)
Post by Bill Page
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0
(sz: 0x1641c0)
Post by Bill Page
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header
ppc-osx3:~/osx/axiom.build-improvements $ cat bar.log
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Post by Bill Page
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
DBEGIN: 0x1c7000
What I don't understand is this output appearing twice. This is the
place it appears not to belong. Is this not output only from unexec?
I don't know. How can I tell?
Post by Camm Maguire
...
Might be of use seeing if both images can compile and load files,
especially the test file foo.l above.
---------
ppc-osx3:~/osx/axiom.build-improvements $ ./foo
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
(compile-file "foo.l")
Compiling foo.l.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.l.
#p"foo.o"
Post by Camm Maguire
(load "foo.o")
Loading foo.o
Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Bill Page
(quit)
ppc-osx3:~/osx/axiom.build-improvements $ ./bar
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
(compile-file "foo.l")
Compiling foo.l.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling foo.l.
#p"foo.o"
Post by Camm Maguire
(load "foo.o")
Loading foo.o
Error: Undefined symbol "___srget"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
Post by Camm Maguire
Post by Bill Page
(quit)
ppc-osx3:~/osx/axiom.build-improvements $
Regards,
Bill Page.
Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-24 01:52:26 UTC
Permalink
Post by Camm Maguire
Post by Bill Page
...
But I see the this symbol *is* known to the gcl image.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm unixport/saved_gcl | grep srget
U ___srget
What is wrong?
Here is says that saved_gcl *uses* the symbol, but does not provide
it. We need T ___srget.
Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
Post by Camm Maguire
Was our patch to o/makefile designed to remove ___srget from plt.h?
If so, this is the culprit. What was the reason if this is the case?
No, only saveFP and restFP are removed because the linker complains
that the symbols are not used in the context of a function. It is
not clear to me why this is not also a problem on other platforms
nor exactly what these symbols are for. Although this helps:

http://www.astro.gla.ac.uk/users/norman/note/2004/restFP

"In particular, the Apple GCC produces object code which includes
references to the restFP and saveFP symbols, which refer to assembler
routines which manipulate the floating-point state of the processor."

...

"The restFP and saveFP functions are defined in Apple's libgcc, and
so the fix is simply to include this library in your link line. The
best way of doing this is to include the option
-lcc_dynamic
in your link line."

Maybe we need this?
Post by Camm Maguire
If not, we need to add code to plttest.c to get these symbols into
plt.h. If this makes any sense to you and you can tell me which
is the case, we can proceed from here.
I have a vague understanding of the purpose of plttest.c and plt.h
from the comments in the source about what this is supposed to do.

Here is the contents of plt.h:

ppc-osx3:~/osx/new/gcl-2.6.8pre $ cat o/plt.h
MY_PLT(__srget),
MY_PLT(__swbuf),
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(log),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(tan),
MY_PLT(tanh)

--------

You will note that "__srget" (two underscores) is present.
Post by Camm Maguire
The idea is that raw_gcl needs its own symbol for every symol that
can be written by the compiler/gcc into an object file to be loaded.
If symbols are in external libraries, e.g. cos() in libm, GCL compiles
in its own reference by taking the address in C
void *ref=cos;
This forces ldd to make a plt table, en effective trampoline, which
will be properly relocated at runtime by ld.so. Jumping to this
trampoline is sufficient to get us to where we need to go.
Thanks for the explanation.

Note that __srget is not defined in an external library but rather
in the /usr/include/stdio.h:

ppc-osx3:~/osx/new/gcl-2.6.8pre $ grep srget /usr/include/stdio.h
int __srget __P((FILE *));
#define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
ppc-osx3:~/osx/new/gcl-2.6.8pre $

------

Is that significant? Does that affect how gcl should look for this
symbol?
Post by Camm Maguire
We also have an additional mechanism to parse the raw_map file to
look at the plt table explicitly if present. This is not very
portable, but the results are in si::*plt-table*.
I get:

ppc-osx3:~/osx/new/gcl-2.6.8pre $ gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
si::*plt-table*
NIL
----------
Post by Camm Maguire
...
Post by Bill Page
Post by Bill Page
Post by Bill Page
Writing segment __DATA at 0x5f8000 - 0x5f8000
(sz: 0)
Post by Bill Page
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in
your compiler::link output below?
It stops there.
OK, this is definitely strange. Could you please
(trace system open delete-file)
before the compiler::link and send me the output.
Did you mean before the save-system command?

First here is the output from compiler::link

-------

ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open delete-file)
(compiler::link nil "bar") (quit)' | gcl | more

GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
1> (OPEN #p"./user-init.c" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./user-init.c">)
1> (SYSTEM "gcc -no-cpp-precomp -c -Wall -DVOL=volatile -fsigned-char
-pipe -I
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../h -O3
-fomit-frame-poin
ter -c \"./user-init.c\" -o \"./user-init.o\" -w")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.c")
<1 (DELETE-FILE T)
1> (OPEN "./raw_bar_map" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./raw_bar_map">)
1> (SYSTEM "gcc -no-cpp-precomp -o ./raw_bar ./user-init.o
-L/home/users/b/b
i/billpage/osx/lib/gcl-2.6.8/unixport/ -lgcl -lm -lc -lgclp ")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.o")
<1 (DELETE-FILE T)
1> (OPEN #p"init_bar.lsp" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "init_bar.lsp">)
1> (OPEN
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/init_gcl.lsp")
<1 (OPEN #<input stream
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/
init_gcl.lsp">)
1> (SYSTEM "./raw_bar
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/ <
init_bar.lsp")
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gc
l-2.6.8pre/raw_bar.tmp ..
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_export.l
sp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_autoload
.lsp
NIL
#<"COMPILER" package>
#<"SLOOP" package>
#<"SERROR" package>
#<"ANSI-LOOP" package>
#<"DEFPACKAGE" package>
#<"TK" package>
#<"SYSTEM" package>

SYSTEM>
*COMMAND-ARGS*

SYSTEM>Initializing gcl_predlib.o
Initializing gcl_setf.o
Initializing gcl_arraylib.o
Initializing gcl_assert.o
Initializing gcl_defstruct.o
Initializing gcl_describe.o
Initializing gcl_iolib.o
Initializing gcl_listlib.o
Initializing gcl_mislib.o
Initializing gcl_numlib.o
Initializing gcl_packlib.o
Initializing gcl_seq.o
Initializing gcl_seqlib.o
Initializing gcl_trace.o
Initializing gcl_sloop.o
Initializing gcl_serror.o
Initializing gcl_destructuring_bind.o
Initializing gcl_loop.o
Initializing gcl_defpackage.o
Initializing gcl_make_defpackage.o
Initializing gcl_cmpinline.o
Initializing gcl_cmputil.o
Initializing gcl_debug.o
Initializing gcl_info.o
Initializing gcl_cmptype.o
Initializing gcl_cmpbind.o
Initializing gcl_cmpblock.o
Initializing gcl_cmpcall.o
Initializing gcl_cmpcatch.o
Initializing gcl_cmpenv.o
Initializing gcl_cmpeval.o
Initializing gcl_cmpflet.o
Initializing gcl_cmpfun.o
Initializing gcl_cmpif.o
Initializing gcl_cmplabel.o
Initializing gcl_cmplam.o
Initializing gcl_cmplet.o
Initializing gcl_cmploc.o
Initializing gcl_cmpmap.o
Initializing gcl_cmpmulti.o
Initializing gcl_cmpspecial.o
Initializing gcl_cmptag.o
Initializing gcl_cmptop.o
Initializing gcl_cmpvar.o
Initializing gcl_cmpvs.o
Initializing gcl_cmpwt.o

Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys-proclaim
.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys
-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/sys-procl
aim.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
sys-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/tk-packag
e.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/
tk-package.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpma
in.lsp
Warning: COMPILE-FILE is being redefined.
Warning: COMPILE is being redefined.
Warning: DISASSEMBLE is being redefined.
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
gcl_cmpmain.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_auto_new
.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl
_auto_new.lsp

T
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb09000
core_end: 0xb0a000
mach_brkpt: 0x57df000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x2032c000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0
4 LC_SEGMENT 0x38 __LINKEDIT 0x201c7000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38 (sz: 0x416d58)
Writing segment __DATA at 0x5f4000 - 0xb09000 (sz: 0x515000)
Writing segment __LINKEDIT at 0xb09000 - 0xc6d1d4 (sz: 0x1641d4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
3948 unused bytes follow Mach-O header
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./raw_bar")
<1 (DELETE-FILE T)
1> (DELETE-FILE #p"init_bar.lsp")
<1 (DELETE-FILE T)
"bar"
---------

Maybe the anomally that you were worried about is not displayed
above? I am not sure what you are looking for.

Here is the same output from save-system:

---------

ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open delete-file)
(si::save-system "foo") (quit)' | gcl | more

GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x16f8 0x1aafc8
__picsymbol_stub 0x1ac6c0 0x18e4
__symbol_stub 0x1adfa4 0
__cstring 0x1adfa4 0x15f5c
__literal4 0x1c3f00 0x18
__literal8 0x1c3f18 0x108
__const 0x1c4020 0x1f9c
__eh_frame 0x1c5fbc 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d68
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0x517000
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f48 (sz: 0x416d68)
Writing segment __DATA at 0x5f4000 - 0xb0c000 (sz: 0x518000)
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0 (sz: 0x1641c0)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header

--------

Note: no initializing in the above output from save-system.
Post by Camm Maguire
...
Regards,
Bill Page.
Camm Maguire
2006-10-24 15:55:47 UTC
Permalink
Greetings!
Post by Bill Page
Post by Camm Maguire
Post by Bill Page
...
But I see the this symbol *is* known to the gcl image.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm unixport/saved_gcl | grep srget
U ___srget
What is wrong?
Here is says that saved_gcl *uses* the symbol, but does not provide
it. We need T ___srget.
Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
Yes, in light of this and previous messages. We need a gdb session on
raw_pre_gcl. Please let me know if you would like me to walk you
through one, or whether you can provide me with remote ssh access to
the box or equivalent.
Post by Bill Page
Post by Camm Maguire
Was our patch to o/makefile designed to remove ___srget from plt.h?
If so, this is the culprit. What was the reason if this is the case?
No, only saveFP and restFP are removed because the linker complains
that the symbols are not used in the context of a function. It is
not clear to me why this is not also a problem on other platforms
http://www.astro.gla.ac.uk/users/norman/note/2004/restFP
"In particular, the Apple GCC produces object code which includes
references to the restFP and saveFP symbols, which refer to assembler
routines which manipulate the floating-point state of the processor."
...
"The restFP and saveFP functions are defined in Apple's libgcc, and
so the fix is simply to include this library in your link line. The
best way of doing this is to include the option
-lcc_dynamic
in your link line."
Maybe we need this?
If we can generate a Undefined symbol error on these symbols when
loading .o files, yes. I'm not sure at the moment why these symbols
are not output into our compiled .o, but we'd certainly know about it
by now. I guess if it ain't broke....
Post by Bill Page
Post by Camm Maguire
If not, we need to add code to plttest.c to get these symbols into
plt.h. If this makes any sense to you and you can tell me which
is the case, we can proceed from here.
I have a vague understanding of the purpose of plttest.c and plt.h
from the comments in the source about what this is supposed to do.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ cat o/plt.h
MY_PLT(__srget),
MY_PLT(__swbuf),
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(log),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(tan),
MY_PLT(tanh)
--------
You will note that "__srget" (two underscores) is present.
Post by Camm Maguire
The idea is that raw_gcl needs its own symbol for every symol that
can be written by the compiler/gcc into an object file to be loaded.
If symbols are in external libraries, e.g. cos() in libm, GCL compiles
in its own reference by taking the address in C
void *ref=cos;
This forces ldd to make a plt table, en effective trampoline, which
will be properly relocated at runtime by ld.so. Jumping to this
trampoline is sufficient to get us to where we need to go.
Thanks for the explanation.
Note that __srget is not defined in an external library but rather
ppc-osx3:~/osx/new/gcl-2.6.8pre $ grep srget /usr/include/stdio.h
int __srget __P((FILE *));
#define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
ppc-osx3:~/osx/new/gcl-2.6.8pre $
------
Is that significant? Does that affect how gcl should look for this
symbol?
As you observed earlier, I believe it is defined in the libc 'dylib',
which is the mac version of a shared library. The header reference
above is a prototype.

Come to think of it, there may be a problem like the following:

On Linux systems, libc symbols are postpended with a @@ and version
number. Here is our code to deal with this (sfasli.c): (my comments
in ****)

for (u=0;u<v;u++) {
char *c=NULL;
struct bfd_link_hash_entry *h;

if (!*q[u]->name)
continue;

if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags & BSF_WEAK))
continue;

*** the above might skip ___srget ***

if ((c=(char *)strstr(q[u]->name,"@@"))) {
*c=0;
if (!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRUE,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
h->type=bfd_link_hash_new;
} else if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,MY_BFD_FALSE,MY_BFD_TRUE)) &&
!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRUE,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);

*** There might be some other mangling than the @ for ___srget ***

if (h->type!=bfd_link_hash_defined) {
if (!q[u]->section)
FEerror("Symbol ~S is missing section",1,make_simple_string(q[u]->name));
if (!my_plt(q[u]->name,&pa)) {
/* printf("my_plt %s %p\n",q[u]->name,(void *)pa); */
if (q[u]->value && q[u]->value!=pa)
FEerror("plt address mismatch", 0);
else
q[u]->value=pa;
}
if (q[u]->value) {
h->type=bfd_link_hash_defined;
h->u.def.value=q[u]->value+q[u]->section->vma;
h->u.def.section=q[u]->section;
}
}

if (c) {
*c='@';
c=NULL;
}
}

This might be instructive with srget in place of cos:

objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
0812f590 l F .text 0000015b number_cos
00000000 F *UND* 00000026 cos@@GLIBC_2.0
0804fb40 F *UND* 00000074 acosh@@GLIBC_2.0
08050440 F *UND* 00000081 cosh@@GLIBC_2.0
0812f6f0 g F .text 00000047 Lcos
Post by Bill Page
Post by Camm Maguire
We also have an additional mechanism to parse the raw_map file to
look at the plt table explicitly if present. This is not very
portable, but the results are in si::*plt-table*.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
si::*plt-table*
NIL
----------
Post by Camm Maguire
...
Post by Bill Page
Post by Bill Page
Post by Bill Page
Writing segment __DATA at 0x5f8000 - 0x5f8000
(sz: 0)
Post by Bill Page
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in
your compiler::link output below?
It stops there.
OK, this is definitely strange. Could you please
(trace system open delete-file)
before the compiler::link and send me the output.
Did you mean before the save-system command?
First here is the output from compiler::link
-------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open delete-file)
(compiler::link nil "bar") (quit)' | gcl | more
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
1> (OPEN #p"./user-init.c" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./user-init.c">)
1> (SYSTEM "gcc -no-cpp-precomp -c -Wall -DVOL=volatile -fsigned-char
-pipe -I
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../h -O3
-fomit-frame-poin
ter -c \"./user-init.c\" -o \"./user-init.o\" -w")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.c")
<1 (DELETE-FILE T)
1> (OPEN "./raw_bar_map" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./raw_bar_map">)
1> (SYSTEM "gcc -no-cpp-precomp -o ./raw_bar ./user-init.o
-L/home/users/b/b
i/billpage/osx/lib/gcl-2.6.8/unixport/ -lgcl -lm -lc -lgclp ")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.o")
<1 (DELETE-FILE T)
1> (OPEN #p"init_bar.lsp" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "init_bar.lsp">)
1> (OPEN
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/init_gcl.lsp")
<1 (OPEN #<input stream
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/
init_gcl.lsp">)
1> (SYSTEM "./raw_bar
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/ <
init_bar.lsp")
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gc
l-2.6.8pre/raw_bar.tmp ..
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_export.l
sp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_autoload
.lsp
NIL
#<"COMPILER" package>
#<"SLOOP" package>
#<"SERROR" package>
#<"ANSI-LOOP" package>
#<"DEFPACKAGE" package>
#<"TK" package>
#<"SYSTEM" package>
SYSTEM>
*COMMAND-ARGS*
SYSTEM>Initializing gcl_predlib.o
Initializing gcl_setf.o
Initializing gcl_arraylib.o
Initializing gcl_assert.o
Initializing gcl_defstruct.o
Initializing gcl_describe.o
Initializing gcl_iolib.o
Initializing gcl_listlib.o
Initializing gcl_mislib.o
Initializing gcl_numlib.o
Initializing gcl_packlib.o
Initializing gcl_seq.o
Initializing gcl_seqlib.o
Initializing gcl_trace.o
Initializing gcl_sloop.o
Initializing gcl_serror.o
Initializing gcl_destructuring_bind.o
Initializing gcl_loop.o
Initializing gcl_defpackage.o
Initializing gcl_make_defpackage.o
Initializing gcl_cmpinline.o
Initializing gcl_cmputil.o
Initializing gcl_debug.o
Initializing gcl_info.o
Initializing gcl_cmptype.o
Initializing gcl_cmpbind.o
Initializing gcl_cmpblock.o
Initializing gcl_cmpcall.o
Initializing gcl_cmpcatch.o
Initializing gcl_cmpenv.o
Initializing gcl_cmpeval.o
Initializing gcl_cmpflet.o
Initializing gcl_cmpfun.o
Initializing gcl_cmpif.o
Initializing gcl_cmplabel.o
Initializing gcl_cmplam.o
Initializing gcl_cmplet.o
Initializing gcl_cmploc.o
Initializing gcl_cmpmap.o
Initializing gcl_cmpmulti.o
Initializing gcl_cmpspecial.o
Initializing gcl_cmptag.o
Initializing gcl_cmptop.o
Initializing gcl_cmpvar.o
Initializing gcl_cmpvs.o
Initializing gcl_cmpwt.o
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys-proclaim
.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys
-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/sys-procl
aim.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
sys-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/tk-packag
e.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/
tk-package.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/gcl_cmpma
in.lsp
Warning: COMPILE-FILE is being redefined.
Warning: COMPILE is being redefined.
Warning: DISASSEMBLE is being redefined.
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
gcl_cmpmain.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl_auto_new
.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl
_auto_new.lsp
T
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb09000
core_end: 0xb0a000
mach_brkpt: 0x57df000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x2032c000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0
4 LC_SEGMENT 0x38 __LINKEDIT 0x201c7000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38 (sz: 0x416d58)
Writing segment __DATA at 0x5f4000 - 0xb09000 (sz: 0x515000)
Writing segment __LINKEDIT at 0xb09000 - 0xc6d1d4 (sz: 0x1641d4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
3948 unused bytes follow Mach-O header
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./raw_bar")
<1 (DELETE-FILE T)
1> (DELETE-FILE #p"init_bar.lsp")
<1 (DELETE-FILE T)
"bar"
---------
Maybe the anomally that you were worried about is not displayed
above? I am not sure what you are looking for.
This looks fine. The Writing segment output occurs once, after the
"Initializing ...". Does the output differ if you do not trace? Your
previous email showed a duplication of the Writing segment and no
Initializing, AFAICR.
Post by Bill Page
---------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open delete-file)
(si::save-system "foo") (quit)' | gcl | more
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x16f8 0x1aafc8
__picsymbol_stub 0x1ac6c0 0x18e4
__symbol_stub 0x1adfa4 0
__cstring 0x1adfa4 0x15f5c
__literal4 0x1c3f00 0x18
__literal8 0x1c3f18 0x108
__const 0x1c4020 0x1f9c
__eh_frame 0x1c5fbc 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d68
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0x517000
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x1c6000 (sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000 (sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4 (sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188 (sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50 (sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c (sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4 (sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0 (sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f48 (sz: 0x416d68)
Writing segment __DATA at 0x5f4000 - 0xb0c000 (sz: 0x518000)
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0 (sz: 0x1641c0)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header
--------
Note: no initializing in the above output from save-system.
Post by Camm Maguire
...
This too is fine. And I guess the sizes are the same.

OK, at least I can reproduce this on my mac -- the link output is
garbled without the trace, and I see the size difference. Will
investigate and report more.

Take care,
Post by Bill Page
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-24 02:16:47 UTC
Permalink
Camm,
Post by Bill Page
...
Thanks for the explanation.
Note that __srget is not defined in an external library but rather
ppc-osx3:~/osx/new/gcl-2.6.8pre $ grep srget /usr/include/stdio.h
int __srget __P((FILE *));
#define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
ppc-osx3:~/osx/new/gcl-2.6.8pre $
------
Is that significant? Does that affect how gcl should look for this
symbol?
...
Oops, please exclude the above comment. I must be tired, but I
realize that's nonesense. Sorry.

Regards,
Bill Page.
Bill Page
2006-10-24 02:45:35 UTC
Permalink
Camm,

What's a dylib on OSX? I found "T ___srget" in 'libc.dylib':

ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm /usr/lib/libc.dylib | grep 'T ___srget'
9000f2a0 T ___srget

------

Also in /usr/lib/libm.dylib
9000f2a0 T ___srget

I tried to understand:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLi
braries/Articles/DynamicLibraryUsageGuidelines.html

but the references to dynamic loading at run time scared me. ;)

Should all of this be figured out by gcl compiler::link?

Regards,
Bill Page.
Camm Maguire
2006-10-24 04:10:54 UTC
Permalink
Greetings!

I think the issue is whether there is an srget in plt.h. We want some
entry therein to generate a U ___srget in plt.o and thereby a T
___srget in raw_pre_gcl. Then we want this entry to be generated by
code in plttest.c passed thruogh the awk and grep in o/makefile.

Can you post plt.h, nm plttest.o and nm plt.o please?

take care,
Post by Bill Page
Camm,
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm /usr/lib/libc.dylib | grep 'T ___srget'
9000f2a0 T ___srget
------
Also in /usr/lib/libm.dylib
9000f2a0 T ___srget
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLi
braries/Articles/DynamicLibraryUsageGuidelines.html
but the references to dynamic loading at run time scared me. ;)
Should all of this be figured out by gcl compiler::link?
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-24 13:10:36 UTC
Permalink
Camm,

I am sorry to have distracted you with my quesition about dylib... ;)
Post by Camm Maguire
I think the issue is whether there is an srget in plt.h. We want some
entry therein to generate a U ___srget in plt.o and thereby a T
___srget in raw_pre_gcl. Then we want this entry to be generated by
code in plttest.c passed thruogh the awk and grep in o/makefile.
Can you post plt.h, nm plttest.o and nm plt.o please?
Please see my previous email displaying plt.h which shows that
__srget is generated by plttest.c and is present in the header file.
Post by Camm Maguire
ppc-osx3:~/osx/new/gcl-2.6.8pre $ cat o/plt.h
MY_PLT(__srget),
MY_PLT(__swbuf),
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(log),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(tan),
MY_PLT(tanh)
--------
Here are also the ouputs of nm. Note presence of ___srget in
both object files:

ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm o/plt.o
U _Cnil_body
U _Dotnil_body
U _FEerror
U _FEwrong_type_argument
U _FIXtemp
U ___srget
U ___swbuf
U _acos
U _acosh
00000670 t _arsearch
000005f0 t _arsort
U _asin
U _asinh
U _atan
U _atanh
U _bsearch
00000004 C _car_or_cdr
00000004 C _casefun
U _cos
U _cosh
U _exp
U _fSmake_vector1_1
U _fclose
U _fgets
U _fopen
U _kcl_self
00000004 C _kf
U _log
U _make_cons
U _make_fixnum1
U _make_simple_string
U _memchr
U _memcmp
000006e8 d _mplt
000004f8 T _my_plt
00000000 T _parse_plt
000005c4 t _pltcomp
U _qsort
U _sLlist
00000004 C _sSAplt_tableA
00000770 d _s_my_dot.0
0000077c d _s_my_dot.1
U _setjmp
U _sin
U _sinh
U _small_fixnum_table
U _snprintf
U _sscanf
U _stat
U _strcmp
U _strcpy
U _strlen
U _strncmp
U _tan
U _tanh
00000004 C _tf
U _unlink
U dyld_stub_binding_helper
ppc-osx3:~/osx/new/gcl-2.6.8pre $

ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm o/plttest.o
U ___srget
U ___swbuf
U _acos
U _acosh
U _asin
U _asinh
U _atan
U _atanh
U _cos
U _cosh
U _exp
U _log
00000000 T _main
U _setjmp
U _sin
U _sinh
U _tan
U _tanh
U dyld_stub_binding_helper
U restFP
U saveFP
ppc-osx3:~/osx/new/gcl-2.6.8pre $

Regards,
Bill Page.
Post by Camm Maguire
-----Original Message-----
.org
[mailto:axiom-developer-bounces+bill.page1=synthesis.anikast.c
Sent: October 23, 2006 9:52 PM
To: 'Camm Maguire'
Subject: [Axiom-developer] RE: gcl-2.6.8pre on MAC OSX 10.2
Post by Camm Maguire
Post by Bill Page
...
But I see the this symbol *is* known to the gcl image.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm unixport/saved_gcl |
grep srget
Post by Camm Maguire
Post by Bill Page
U ___srget
What is wrong?
Here is says that saved_gcl *uses* the symbol, but does not provide
it. We need T ___srget.
Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
Post by Camm Maguire
Was our patch to o/makefile designed to remove ___srget from plt.h?
If so, this is the culprit. What was the reason if this is
the case?
No, only saveFP and restFP are removed because the linker complains
that the symbols are not used in the context of a function. It is
not clear to me why this is not also a problem on other platforms
http://www.astro.gla.ac.uk/users/norman/note/2004/restFP
"In particular, the Apple GCC produces object code which includes
references to the restFP and saveFP symbols, which refer to assembler
routines which manipulate the floating-point state of the processor."
...
"The restFP and saveFP functions are defined in Apple's libgcc, and
so the fix is simply to include this library in your link line. The
best way of doing this is to include the option
-lcc_dynamic
in your link line."
Maybe we need this?
Post by Camm Maguire
If not, we need to add code to plttest.c to get these symbols into
plt.h. If this makes any sense to you and you can tell me which
is the case, we can proceed from here.
I have a vague understanding of the purpose of plttest.c and plt.h
from the comments in the source about what this is supposed to do.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ cat o/plt.h
MY_PLT(__srget),
MY_PLT(__swbuf),
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(log),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(tan),
MY_PLT(tanh)
--------
You will note that "__srget" (two underscores) is present.
Post by Camm Maguire
The idea is that raw_gcl needs its own symbol for every symol that
can be written by the compiler/gcc into an object file to be loaded.
If symbols are in external libraries, e.g. cos() in libm,
GCL compiles
Post by Camm Maguire
in its own reference by taking the address in C
void *ref=cos;
This forces ldd to make a plt table, en effective trampoline, which
will be properly relocated at runtime by ld.so. Jumping to this
trampoline is sufficient to get us to where we need to go.
Thanks for the explanation.
Note that __srget is not defined in an external library but rather
ppc-osx3:~/osx/new/gcl-2.6.8pre $ grep srget /usr/include/stdio.h
int __srget __P((FILE *));
#define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
ppc-osx3:~/osx/new/gcl-2.6.8pre $
------
Is that significant? Does that affect how gcl should look for this
symbol?
Post by Camm Maguire
We also have an additional mechanism to parse the raw_map file to
look at the plt table explicitly if present. This is not very
portable, but the results are in si::*plt-table*.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
si::*plt-table*
NIL
----------
Post by Camm Maguire
...
Post by Bill Page
Post by Bill Page
Post by Bill Page
Writing segment __DATA at 0x5f8000 - 0x5f8000
(sz: 0)
Post by Bill Page
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in
your compiler::link output below?
It stops there.
OK, this is definitely strange. Could you please
(trace system open delete-file)
before the compiler::link and send me the output.
Did you mean before the save-system command?
First here is the output from compiler::link
-------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open
delete-file)
(compiler::link nil "bar") (quit)' | gcl | more
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
1> (OPEN #p"./user-init.c" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./user-init.c">)
1> (SYSTEM "gcc -no-cpp-precomp -c -Wall -DVOL=volatile
-fsigned-char
-pipe -I
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../h -O3
-fomit-frame-poin
ter -c \"./user-init.c\" -o \"./user-init.o\" -w")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.c")
<1 (DELETE-FILE T)
1> (OPEN "./raw_bar_map" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./raw_bar_map">)
1> (SYSTEM "gcc -no-cpp-precomp -o ./raw_bar ./user-init.o
-L/home/users/b/b
i/billpage/osx/lib/gcl-2.6.8/unixport/ -lgcl -lm -lc -lgclp ")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.o")
<1 (DELETE-FILE T)
1> (OPEN #p"init_bar.lsp" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "init_bar.lsp">)
1> (OPEN
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/init_gcl.lsp")
<1 (OPEN #<input stream
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/
init_gcl.lsp">)
1> (SYSTEM "./raw_bar
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/ <
init_bar.lsp")
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gc
l-2.6.8pre/raw_bar.tmp ..
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gc
l_export.l
sp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gc
l_autoload
.lsp
NIL
#<"COMPILER" package>
#<"SLOOP" package>
#<"SERROR" package>
#<"ANSI-LOOP" package>
#<"DEFPACKAGE" package>
#<"TK" package>
#<"SYSTEM" package>
SYSTEM>
*COMMAND-ARGS*
SYSTEM>Initializing gcl_predlib.o
Initializing gcl_setf.o
Initializing gcl_arraylib.o
Initializing gcl_assert.o
Initializing gcl_defstruct.o
Initializing gcl_describe.o
Initializing gcl_iolib.o
Initializing gcl_listlib.o
Initializing gcl_mislib.o
Initializing gcl_numlib.o
Initializing gcl_packlib.o
Initializing gcl_seq.o
Initializing gcl_seqlib.o
Initializing gcl_trace.o
Initializing gcl_sloop.o
Initializing gcl_serror.o
Initializing gcl_destructuring_bind.o
Initializing gcl_loop.o
Initializing gcl_defpackage.o
Initializing gcl_make_defpackage.o
Initializing gcl_cmpinline.o
Initializing gcl_cmputil.o
Initializing gcl_debug.o
Initializing gcl_info.o
Initializing gcl_cmptype.o
Initializing gcl_cmpbind.o
Initializing gcl_cmpblock.o
Initializing gcl_cmpcall.o
Initializing gcl_cmpcatch.o
Initializing gcl_cmpenv.o
Initializing gcl_cmpeval.o
Initializing gcl_cmpflet.o
Initializing gcl_cmpfun.o
Initializing gcl_cmpif.o
Initializing gcl_cmplabel.o
Initializing gcl_cmplam.o
Initializing gcl_cmplet.o
Initializing gcl_cmploc.o
Initializing gcl_cmpmap.o
Initializing gcl_cmpmulti.o
Initializing gcl_cmpspecial.o
Initializing gcl_cmptag.o
Initializing gcl_cmptop.o
Initializing gcl_cmpvar.o
Initializing gcl_cmpvs.o
Initializing gcl_cmpwt.o
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sy
s-proclaim
.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys
-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew
/sys-procl
aim.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
sys-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk
/tk-packag
e.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/
tk-package.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew
/gcl_cmpma
in.lsp
Warning: COMPILE-FILE is being redefined.
Warning: COMPILE is being redefined.
Warning: DISASSEMBLE is being redefined.
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
gcl_cmpmain.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gc
l_auto_new
.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl
_auto_new.lsp
T
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb09000
core_end: 0xb0a000
mach_brkpt: 0x57df000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x2032c000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0
4 LC_SEGMENT 0x38 __LINKEDIT 0x201c7000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Writing segment __TEXT at 0 - 0x1c6000
(sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000
(sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4
(sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188
(sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50
(sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c
(sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4
(sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0
(sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38
(sz: 0x416d58)
Writing segment __DATA at 0x5f4000 - 0xb09000
(sz: 0x515000)
Writing segment __LINKEDIT at 0xb09000 - 0xc6d1d4
(sz: 0x1641d4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
3948 unused bytes follow Mach-O header
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./raw_bar")
<1 (DELETE-FILE T)
1> (DELETE-FILE #p"init_bar.lsp")
<1 (DELETE-FILE T)
"bar"
---------
Maybe the anomally that you were worried about is not displayed
above? I am not sure what you are looking for.
---------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open
delete-file)
(si::save-system "foo") (quit)' | gcl | more
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x16f8 0x1aafc8
__picsymbol_stub 0x1ac6c0 0x18e4
__symbol_stub 0x1adfa4 0
__cstring 0x1adfa4 0x15f5c
__literal4 0x1c3f00 0x18
__literal8 0x1c3f18 0x108
__const 0x1c4020 0x1f9c
__eh_frame 0x1c5fbc 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d68
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0x517000
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Writing segment __TEXT at 0 - 0x1c6000
(sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000
(sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4
(sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188
(sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50
(sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c
(sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4
(sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0
(sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f48
(sz: 0x416d68)
Writing segment __DATA at 0x5f4000 - 0xb0c000
(sz: 0x518000)
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0
(sz: 0x1641c0)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header
--------
Note: no initializing in the above output from save-system.
Post by Camm Maguire
...
Regards,
Bill Page.
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer
Camm Maguire
2006-10-24 14:37:30 UTC
Permalink
Greetings!
Post by Bill Page
Camm,
I am sorry to have distracted you with my quesition about dylib... ;)
Not at all! I'm trying to figure this out too.

The real problem is that the mac to which I have access does not show
this issue:

plt.h:
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(fdopen),
MY_PLT(feof),
MY_PLT(getc),
MY_PLT(getpid),
MY_PLT(log),
MY_PLT(memset),
MY_PLT(putc),
MY_PLT(read),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(sqrt),
MY_PLT(tan),
MY_PLT(tanh),
MY_PLT(write)

nm plttest.o
U _acos
U _acosh
U _asin
U _asinh
U _atan
U _atanh
U _cos
U _cosh
U _exp
U _fdopen
U _feof
U _getc
U _getpid
U _log
00000000 T _main
U _memset
U _putc
U _read
U _setjmp
U _sin
U _sinh
U _sqrt
U _tan
U _tanh
U _write
U dyld_stub_binding_helper

uname -a
Darwin mason.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc


How many different types of macosx are there? How can I get access to
an equivalent machine to yours?

The next step is to compile with --enable-debug, and then run
raw_pre_gcl in gdb with a single argument of unixport/. Break at
build_symbol_table_bfd, set a break inside the loop conditionalized
with a strstr on srget, and see why this symbol is not being added.
Its probably faster for me to do it myself unless the above makes
sense to you.

Similar needs doing for compiler::link.

I had thought macosx support was done given my experience on the above
machine. Can anyone please make the macosx os structure simple to me?
I know that animal names are somehow involved :-)

Take care,
Post by Bill Page
Post by Camm Maguire
I think the issue is whether there is an srget in plt.h. We want some
entry therein to generate a U ___srget in plt.o and thereby a T
___srget in raw_pre_gcl. Then we want this entry to be generated by
code in plttest.c passed thruogh the awk and grep in o/makefile.
Can you post plt.h, nm plttest.o and nm plt.o please?
Please see my previous email displaying plt.h which shows that
__srget is generated by plttest.c and is present in the header file.
Post by Camm Maguire
ppc-osx3:~/osx/new/gcl-2.6.8pre $ cat o/plt.h
MY_PLT(__srget),
MY_PLT(__swbuf),
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(log),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(tan),
MY_PLT(tanh)
--------
Here are also the ouputs of nm. Note presence of ___srget in
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm o/plt.o
U _Cnil_body
U _Dotnil_body
U _FEerror
U _FEwrong_type_argument
U _FIXtemp
U ___srget
U ___swbuf
U _acos
U _acosh
00000670 t _arsearch
000005f0 t _arsort
U _asin
U _asinh
U _atan
U _atanh
U _bsearch
00000004 C _car_or_cdr
00000004 C _casefun
U _cos
U _cosh
U _exp
U _fSmake_vector1_1
U _fclose
U _fgets
U _fopen
U _kcl_self
00000004 C _kf
U _log
U _make_cons
U _make_fixnum1
U _make_simple_string
U _memchr
U _memcmp
000006e8 d _mplt
000004f8 T _my_plt
00000000 T _parse_plt
000005c4 t _pltcomp
U _qsort
U _sLlist
00000004 C _sSAplt_tableA
00000770 d _s_my_dot.0
0000077c d _s_my_dot.1
U _setjmp
U _sin
U _sinh
U _small_fixnum_table
U _snprintf
U _sscanf
U _stat
U _strcmp
U _strcpy
U _strlen
U _strncmp
U _tan
U _tanh
00000004 C _tf
U _unlink
U dyld_stub_binding_helper
ppc-osx3:~/osx/new/gcl-2.6.8pre $
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm o/plttest.o
U ___srget
U ___swbuf
U _acos
U _acosh
U _asin
U _asinh
U _atan
U _atanh
U _cos
U _cosh
U _exp
U _log
00000000 T _main
U _setjmp
U _sin
U _sinh
U _tan
U _tanh
U dyld_stub_binding_helper
U restFP
U saveFP
ppc-osx3:~/osx/new/gcl-2.6.8pre $
Regards,
Bill Page.
Post by Camm Maguire
-----Original Message-----
.org
[mailto:axiom-developer-bounces+bill.page1=synthesis.anikast.c
Sent: October 23, 2006 9:52 PM
To: 'Camm Maguire'
Subject: [Axiom-developer] RE: gcl-2.6.8pre on MAC OSX 10.2
Post by Camm Maguire
Post by Bill Page
...
But I see the this symbol *is* known to the gcl image.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ nm unixport/saved_gcl |
grep srget
Post by Camm Maguire
Post by Bill Page
U ___srget
What is wrong?
Here is says that saved_gcl *uses* the symbol, but does not provide
it. We need T ___srget.
Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
Post by Camm Maguire
Was our patch to o/makefile designed to remove ___srget from plt.h?
If so, this is the culprit. What was the reason if this is
the case?
No, only saveFP and restFP are removed because the linker complains
that the symbols are not used in the context of a function. It is
not clear to me why this is not also a problem on other platforms
http://www.astro.gla.ac.uk/users/norman/note/2004/restFP
"In particular, the Apple GCC produces object code which includes
references to the restFP and saveFP symbols, which refer to assembler
routines which manipulate the floating-point state of the processor."
...
"The restFP and saveFP functions are defined in Apple's libgcc, and
so the fix is simply to include this library in your link line. The
best way of doing this is to include the option
-lcc_dynamic
in your link line."
Maybe we need this?
Post by Camm Maguire
If not, we need to add code to plttest.c to get these symbols into
plt.h. If this makes any sense to you and you can tell me which
is the case, we can proceed from here.
I have a vague understanding of the purpose of plttest.c and plt.h
from the comments in the source about what this is supposed to do.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ cat o/plt.h
MY_PLT(__srget),
MY_PLT(__swbuf),
MY_PLT(acos),
MY_PLT(acosh),
MY_PLT(asin),
MY_PLT(asinh),
MY_PLT(atan),
MY_PLT(atanh),
MY_PLT(cos),
MY_PLT(cosh),
MY_PLT(exp),
MY_PLT(log),
MY_PLT(setjmp),
MY_PLT(sin),
MY_PLT(sinh),
MY_PLT(tan),
MY_PLT(tanh)
--------
You will note that "__srget" (two underscores) is present.
Post by Camm Maguire
The idea is that raw_gcl needs its own symbol for every symol that
can be written by the compiler/gcc into an object file to be loaded.
If symbols are in external libraries, e.g. cos() in libm,
GCL compiles
Post by Camm Maguire
in its own reference by taking the address in C
void *ref=cos;
This forces ldd to make a plt table, en effective trampoline, which
will be properly relocated at runtime by ld.so. Jumping to this
trampoline is sufficient to get us to where we need to go.
Thanks for the explanation.
Note that __srget is not defined in an external library but rather
ppc-osx3:~/osx/new/gcl-2.6.8pre $ grep srget /usr/include/stdio.h
int __srget __P((FILE *));
#define __sgetc(p) (--(p)->_r < 0 ? __srget(p) : (int)(*(p)->_p++))
ppc-osx3:~/osx/new/gcl-2.6.8pre $
------
Is that significant? Does that affect how gcl should look for this
symbol?
Post by Camm Maguire
We also have an additional mechanism to parse the raw_map file to
look at the plt table explicitly if present. This is not very
portable, but the results are in si::*plt-table*.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ gcl
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Post by Camm Maguire
si::*plt-table*
NIL
----------
Post by Camm Maguire
...
Post by Bill Page
Post by Bill Page
Post by Bill Page
Writing segment __DATA at 0x5f8000 - 0x5f8000
(sz: 0)
Post by Bill Page
WGCL (GNU Common Lisp) April 1994 131072 pages
Does this stop here? Or do you see "Initializing ...." as in
your compiler::link output below?
It stops there.
OK, this is definitely strange. Could you please
(trace system open delete-file)
before the compiler::link and send me the output.
Did you mean before the save-system command?
First here is the output from compiler::link
-------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open
delete-file)
(compiler::link nil "bar") (quit)' | gcl | more
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
1> (OPEN #p"./user-init.c" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./user-init.c">)
1> (SYSTEM "gcc -no-cpp-precomp -c -Wall -DVOL=volatile
-fsigned-char
-pipe -I
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../h -O3
-fomit-frame-poin
ter -c \"./user-init.c\" -o \"./user-init.o\" -w")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.c")
<1 (DELETE-FILE T)
1> (OPEN "./raw_bar_map" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "./raw_bar_map">)
1> (SYSTEM "gcc -no-cpp-precomp -o ./raw_bar ./user-init.o
-L/home/users/b/b
i/billpage/osx/lib/gcl-2.6.8/unixport/ -lgcl -lm -lc -lgclp ")
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./user-init.o")
<1 (DELETE-FILE T)
1> (OPEN #p"init_bar.lsp" :DIRECTION :OUTPUT)
<1 (OPEN #<output stream "init_bar.lsp">)
1> (OPEN
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/init_gcl.lsp")
<1 (OPEN #<input stream
"/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/
init_gcl.lsp">)
1> (SYSTEM "./raw_bar
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/ <
init_bar.lsp")
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gc
l-2.6.8pre/raw_bar.tmp ..
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gc
l_export.l
sp
Initializing gcl_defmacro.o
Initializing gcl_evalmacros.o
Initializing gcl_top.o
Initializing gcl_module.o
loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gc
l_autoload
.lsp
NIL
#<"COMPILER" package>
#<"SLOOP" package>
#<"SERROR" package>
#<"ANSI-LOOP" package>
#<"DEFPACKAGE" package>
#<"TK" package>
#<"SYSTEM" package>
SYSTEM>
*COMMAND-ARGS*
SYSTEM>Initializing gcl_predlib.o
Initializing gcl_setf.o
Initializing gcl_arraylib.o
Initializing gcl_assert.o
Initializing gcl_defstruct.o
Initializing gcl_describe.o
Initializing gcl_iolib.o
Initializing gcl_listlib.o
Initializing gcl_mislib.o
Initializing gcl_numlib.o
Initializing gcl_packlib.o
Initializing gcl_seq.o
Initializing gcl_seqlib.o
Initializing gcl_trace.o
Initializing gcl_sloop.o
Initializing gcl_serror.o
Initializing gcl_destructuring_bind.o
Initializing gcl_loop.o
Initializing gcl_defpackage.o
Initializing gcl_make_defpackage.o
Initializing gcl_cmpinline.o
Initializing gcl_cmputil.o
Initializing gcl_debug.o
Initializing gcl_info.o
Initializing gcl_cmptype.o
Initializing gcl_cmpbind.o
Initializing gcl_cmpblock.o
Initializing gcl_cmpcall.o
Initializing gcl_cmpcatch.o
Initializing gcl_cmpenv.o
Initializing gcl_cmpeval.o
Initializing gcl_cmpflet.o
Initializing gcl_cmpfun.o
Initializing gcl_cmpif.o
Initializing gcl_cmplabel.o
Initializing gcl_cmplam.o
Initializing gcl_cmplet.o
Initializing gcl_cmploc.o
Initializing gcl_cmpmap.o
Initializing gcl_cmpmulti.o
Initializing gcl_cmpspecial.o
Initializing gcl_cmptag.o
Initializing gcl_cmptop.o
Initializing gcl_cmpvar.o
Initializing gcl_cmpvs.o
Initializing gcl_cmpwt.o
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sy
s-proclaim
.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/sys
-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew
/sys-procl
aim.lisp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
sys-proclaim.lisp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk
/tk-packag
e.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../gcl-tk/
tk-package.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew
/gcl_cmpma
in.lsp
Warning: COMPILE-FILE is being redefined.
Warning: COMPILE is being redefined.
Warning: DISASSEMBLE is being redefined.
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../cmpnew/
gcl_cmpmain.lsp
Loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gc
l_auto_new
.lsp
Finished loading
/home/users/b/bi/billpage/osx/lib/gcl-2.6.8/unixport/../lsp/gcl
_auto_new.lsp
T
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb09000
core_end: 0xb0a000
mach_brkpt: 0x57df000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x2032c000
Lowest offset of all sections in __TEXT segment: 0x1658
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x2658 0x1ab044
__picsymbol_stub 0x1ad69c 0x18e4
__symbol_stub 0x1aef80 0
__cstring 0x1aef80 0x15f5c
__literal4 0x1c4edc 0x18
__literal8 0x1c4ef8 0x108
__const 0x1c5000 0x1f9c
__eh_frame 0x1c6f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d58
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0
4 LC_SEGMENT 0x38 __LINKEDIT 0x201c7000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Writing segment __TEXT at 0 - 0x1c6000
(sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000
(sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4
(sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188
(sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50
(sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c
(sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4
(sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0
(sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f38
(sz: 0x416d58)
Writing segment __DATA at 0x5f4000 - 0xb09000
(sz: 0x515000)
Writing segment __LINKEDIT at 0xb09000 - 0xc6d1d4
(sz: 0x1641d4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
3948 unused bytes follow Mach-O header
<1 (SYSTEM 0 0)
1> (DELETE-FILE #p"./raw_bar")
<1 (DELETE-FILE T)
1> (DELETE-FILE #p"init_bar.lsp")
<1 (DELETE-FILE T)
"bar"
---------
Maybe the anomally that you were worried about is not displayed
above? I am not sure what you are looking for.
---------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ echo '(trace system open
delete-file)
(si::save-system "foo") (quit)' | gcl | more
GCL (GNU Common Lisp) 2.6.8 CLtL1 Oct 18 2006 15:24:28
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a
compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
Warning: SYSTEM is being redefined.
Warning: OPEN is being redefined.
Warning: DELETE-FILE is being redefined.
(SYSTEM OPEN DELETE-FILE)
Post by Camm Maguire
DBEGIN: 0x1c7000
mach_mapstart: 0x5f5000
heap_end: 0xb0c000
core_end: 0xb0d000
mach_brkpt: 0xe737000
mach_maplimit: 0x201c7000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x517000 rwx rwx (no zone)
0xb0c000 0x1f6bb000 rwx rwx (no zone)
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1c6000 r x rwx (no zone)
0x1c7000 0x42e000 rw rwx (no zone)
0x5f5000 0x1fbd2000 rwx rwx (no zone)
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 11
SizeOfCmds = 1744
Flags = 0x00000085
Highest address of load commands in input file: 0x5fad0000
Lowest offset of all sections in __TEXT segment: 0x6f8
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x1c6000
__text 0x16f8 0x1aafc8
__picsymbol_stub 0x1ac6c0 0x18e4
__symbol_stub 0x1adfa4 0
__cstring 0x1adfa4 0x15f5c
__literal4 0x1c3f00 0x18
__literal8 0x1c3f18 0x108
__const 0x1c4020 0x1f9c
__eh_frame 0x1c5fbc 0x60
2 LC_SEGMENT 0x214 __DATA 0x1c7000 0x42e000
__data 0x1c7000 0xaec4
__la_symbol_ptr 0x1d1ec4 0x2c4
__nl_symbol_ptr 0x1d2188 0x9c8
__dyld 0x1d2b50 0x1c
__const 0x1d2b6c 0x2748
__bss 0x1d52b8 0x8f28
__common 0x1de1e0 0x416d68
3 LC_SEGMENT 0x7c __DATA 0x5f5000 0x1fbd2000
__data 0x5f5000 0x517000
4 LC_SEGMENT 0x38 __LINKEDIT 0x5f96b000 0x165000
5 LC_LOAD_DYLINKER 0x1c
6 LC_LOAD_DYLIB 0x34
7 LC_SYMTAB 0x18
8 LC_DYSYMTAB 0x50
9 LC_TWOLEVEL_HINTS 0x10
10 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0
(sz: 0)
Writing segment __TEXT at 0 - 0x1c6000
(sz: 0x1c6000)
Writing segment __DATA at 0x1c6000 - 0x5f4000
(sz: 0x42e000)
section __data at 0x1c6000 - 0x1d0ec4
(sz: 0xaec4)
section __la_symbol_ptr at 0x1d0ec4 - 0x1d1188
(sz: 0x2c4)
section __nl_symbol_ptr at 0x1d1188 - 0x1d1b50
(sz: 0x9c8)
section __dyld at 0x1d1b50 - 0x1d1b6c
(sz: 0x1c)
section __const at 0x1d1b6c - 0x1d42b4
(sz: 0x2748)
section __bss at 0x1d42b8 - 0x1dd1e0
(sz: 0x8f28)
section __common at 0x1dd1e0 - 0x5f3f48
(sz: 0x416d68)
Writing segment __DATA at 0x5f4000 - 0xb0c000
(sz: 0x518000)
Writing segment __LINKEDIT at 0x1538000 - 0x169c1c0
(sz: 0x1641c0)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 0/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
12 unused bytes follow Mach-O header
--------
Note: no initializing in the above output from save-system.
Post by Camm Maguire
...
Regards,
Bill Page.
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-24 17:55:26 UTC
Permalink
Camm,
Post by Camm Maguire
Post by Bill Page
Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
Yes, in light of this and previous messages. We need a gdb session
on raw_pre_gcl. Please let me know if you would like me to walk
you through one, or whether you can provide me with remote ssh
access to the box or equivalent.
I am using the SourceForge compile farm machine 'ppc-osx3'. All
registered SourceForge developers have access to these machines.
You should have not problem to access it. Once you can log in,
I can scp my working directories to your account.
Post by Camm Maguire
...
(my comments in ****)
for (u=0;u<v;u++) {
char *c=NULL;
struct bfd_link_hash_entry *h;
if (!*q[u]->name)
continue;
if (strncmp(q[u]->section->name,"*UND*",5) &&
!(q[u]->flags & BSF_WEAK))
continue;
*** the above might skip ___srget ***
*c=0;
if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRU
E,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
h->type=bfd_link_hash_new;
} else if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FAL
SE,MY_BFD_FALSE,MY_BFD_TRUE)) &&
Post by Camm Maguire
!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRUE
,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
if (h->type!=bfd_link_hash_defined) {
if (!q[u]->section)
FEerror("Symbol ~S is missing
section",1,make_simple_string(q[u]->name));
if (!my_plt(q[u]->name,&pa)) {
/* printf("my_plt %s %p\n",q[u]->name,(void *)pa); */
if (q[u]->value && q[u]->value!=pa)
FEerror("plt address mismatch", 0);
else
q[u]->value=pa;
}
if (q[u]->value) {
h->type=bfd_link_hash_defined;
h->u.def.value=q[u]->value+q[u]->section->vma;
h->u.def.section=q[u]->section;
}
}
if (c) {
c=NULL;
}
}
objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
0812f590 l F .text 0000015b number_cos
0812f6f0 g F .text 00000047 Lcos
There is no objdump on this OSX 10.2 system. :-(

Shall I try to install GNU binutils? The version bundled with GCL
or a newer one?

Regards,
Bill Page.
Camm Maguire
2006-10-25 15:09:55 UTC
Permalink
Greetings!
Post by Bill Page
Camm,
Post by Camm Maguire
Post by Bill Page
Aha. No "__srget" symbol defined in the gcl image? Isn't it strange?
Yes, in light of this and previous messages. We need a gdb session
on raw_pre_gcl. Please let me know if you would like me to walk
you through one, or whether you can provide me with remote ssh
access to the box or equivalent.
I am using the SourceForge compile farm machine 'ppc-osx3'. All
registered SourceForge developers have access to these machines.
You should have not problem to access it. Once you can log in,
I can scp my working directories to your account.
OK, will try to reactivate my sourceforge status. Something changed
over the summer. In the meantime, here is what needs doing:

./configure --enable-debug && make
cd unixport
make raw_pre_gcl
gdb raw_pre_gcl
(gdb) b sfasli.c:65
(gdb) r ./
(gdb) cond 1 strstr(q[u]->name,"srget")
(gdb) c
(gdb) p q[u]->name
(gdb) p q[u]->section->name
(gdb) p q[u]->flags


Thanks!
Post by Bill Page
Post by Camm Maguire
...
(my comments in ****)
for (u=0;u<v;u++) {
char *c=NULL;
struct bfd_link_hash_entry *h;
if (!*q[u]->name)
continue;
if (strncmp(q[u]->section->name,"*UND*",5) &&
!(q[u]->flags & BSF_WEAK))
continue;
*** the above might skip ___srget ***
*c=0;
if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRU
E,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
h->type=bfd_link_hash_new;
} else if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FAL
SE,MY_BFD_FALSE,MY_BFD_TRUE)) &&
Post by Camm Maguire
!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRUE
,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
if (h->type!=bfd_link_hash_defined) {
if (!q[u]->section)
FEerror("Symbol ~S is missing
section",1,make_simple_string(q[u]->name));
if (!my_plt(q[u]->name,&pa)) {
/* printf("my_plt %s %p\n",q[u]->name,(void *)pa); */
if (q[u]->value && q[u]->value!=pa)
FEerror("plt address mismatch", 0);
else
q[u]->value=pa;
}
if (q[u]->value) {
h->type=bfd_link_hash_defined;
h->u.def.value=q[u]->value+q[u]->section->vma;
h->u.def.section=q[u]->section;
}
}
if (c) {
c=NULL;
}
}
objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
0812f590 l F .text 0000015b number_cos
0812f6f0 g F .text 00000047 Lcos
There is no objdump on this OSX 10.2 system. :-(
Shall I try to install GNU binutils? The version bundled with GCL
or a newer one?
The one in the GCL sources should be fine.

Take care,
Post by Bill Page
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-10-25 23:19:40 UTC
Permalink
Camm,
Post by Camm Maguire
...
OK, will try to reactivate my sourceforge status. Something
changed over the summer.
Yes, there were some problems with access to the compile farm.
That seems to be fixed now.
Post by Camm Maguire
./configure --enable-debug && make
cd unixport
make raw_pre_gcl
gdb raw_pre_gcl
(gdb) b sfasli.c:65
(gdb) r ./
(gdb) cond 1 strstr(q[u]->name,"srget")
(gdb) c
(gdb) p q[u]->name
(gdb) p q[u]->section->name
(gdb) p q[u]->flags
Thanks!
Here you go:

---------

ppc-osx3:~/osx/new/gcl-2.6.8pre $ ./configure
--prefix=/home/users/b/bi/billpage/osx --enable-locbfd
--disable-statsysbfd --enable-debug
...

ppc-osx3:~/osx/new/gcl-2.6.8pre $ make
...
makeinfo --html gcl-si.texi
makeinfo --html gcl-tk.texi

ppc-osx3:~/osx/new/gcl-2.6.8pre $ cd unixport

ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $ make raw_pre_gcl
ls: ../xgcl-2/*.o: No such file or directory
ls: ../mod/*.o: No such file or directory
ls: ../pcl/*.o: No such file or directory
ls: ../clcs/*.o: No such file or directory
ls: ../clcs/clcs_*.lisp: No such file or directory
touch raw_pre_gcl_map
gcc -no-cpp-precomp -o raw_pre_gcl \
-L. -lpre_gcl `echo -lm | sed -e 's/-lncurses/ /'` -lc -lgclp

ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $ gdb raw_pre_gcl
GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec 7 02:14:27 GMT
2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .. done
(gdb) b sfasli.c:65
Breakpoint 1 at 0xb1b54: file sfasli.c, line 65.
(gdb) r ./
Starting program:
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixpor
t/raw_pre_gcl ./
[Switching to process 27643 thread 0xb03]
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
DBEGIN: 0x122000
mach_mapstart: 0x548000
heap_end: 0x548000
core_end: 0x548000
mach_brkpt: 0x548000
mach_maplimit: 0x20122000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1000 r x rwx (no zone)
0x2000 0xaf000 r x rwx (no zone)
0xb1000 0x1000 r x rwx (no zone)
0xb2000 0x70000 r x rwx (no zone)
0x122000 0x6000 rw rwx (no zone)
0x128000 0x420000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x40000 rw rwx DefaultMallocZone
0x865000 0x20000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x121000 r x rwx (no zone)
0x122000 0x426000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x60000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x825000
Lowest offset of all sections in __TEXT segment: 0xb18
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x121000
__text 0x1b18 0x10a410
__picsymbol_stub 0x10bf28 0x18e4
__symbol_stub 0x10d80c 0
__cstring 0x10d80c 0x12714
__literal4 0x11ff20 0x18
__literal8 0x11ff38 0xc8
__const 0x120000 0x1f9c
__eh_frame 0x121f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x122000 0x426000
__data 0x122000 0x25b0
__la_symbol_ptr 0x1245b0 0x2c4
__nl_symbol_ptr 0x124874 0x8fc
__dyld 0x125170 0x1c
__const 0x12518c 0x2748
__bss 0x1278d8 0x8f28
__common 0x130800 0x416d68
3 LC_SEGMENT 0x38 __LINKEDIT 0x548000 0x2dd000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz:
0)
Writing segment __TEXT at 0 - 0x121000 (sz:
0x121000)
Writing segment __DATA at 0x121000 - 0x127000 (sz:
0x6000)
section __data at 0x121000 - 0x1235b0 (sz:
0x25b0)
section __la_symbol_ptr at 0x1235b0 - 0x123874 (sz:
0x2c4)
section __nl_symbol_ptr at 0x123874 - 0x124170 (sz:
0x8fc)
section __dyld at 0x124170 - 0x12418c (sz:
0x1c)
section __const at 0x12418c - 0x1268d4 (sz:
0x2748)
section __bss at 0x1268d8 - 0x12f800 (sz:
0x8f28)
section __common at 0x12f800 - 0x546568 (sz:
0x416d68)
Writing segment __DATA at 0x547000 - 0x547000 (sz:
0)
Writing segment __LINKEDIT at 0x547000 - 0x823df4 (sz:
0x2dcdf4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 17/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
1068 unused bytes follow Mach-O header

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe19090 in __dyld__dyld_start ()

(gdb) cond 1 (int) strstr(q[u]->name,"srget")

(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixpor
t/raw_pre_gcl.tmp ..

Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags
& BSF_WEAK))

(gdb) p q[u]->name
$1 = 0x5742d1 "___srget"

(gdb) p q[u]->section->name
$2 = 0x114e74 "*UND*"

(gdb) p q[u]->flags
$3 = 2

(gdb) c
Continuing.
loading ./../lsp/gcl_export.lsp
loading ./../lsp/gcl_defmacro.lsp
loading ./../lsp/gcl_evalmacros.lsp
loading ./../lsp/gcl_top.lsp
loading ./../lsp/gcl_module.lsp
loading ./../lsp/gcl_autoload.lsp
Post by Camm Maguire
(quit)
Program exited normally.
(gdb) quit
ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $

--------

Note I had to add (int) to:

cond 1 (int) strstr(q[u]->name,"srget")

to avoid an error message about unknow return type.
Post by Camm Maguire
Post by Camm Maguire
Post by Camm Maguire
...
(my comments in ****)
for (u=0;u<v;u++) {
char *c=NULL;
struct bfd_link_hash_entry *h;
if (!*q[u]->name)
continue;
if (strncmp(q[u]->section->name,"*UND*",5) &&
!(q[u]->flags & BSF_WEAK))
continue;
Is value of flags=2 ok? What is BSF_WEAK?

h/bfd.h:#define BSF_WEAK 0x80
Post by Camm Maguire
Post by Camm Maguire
Post by Camm Maguire
*** the above might skip ___srget ***
It looks like it's gonna skip to me. Is that good or bad?
Post by Camm Maguire
Post by Camm Maguire
Post by Camm Maguire
*c=0;
if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRU
E,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
h->type=bfd_link_hash_new;
} else if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FAL
SE,MY_BFD_FALSE,MY_BFD_TRUE)) &&
Post by Camm Maguire
!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRUE
,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
if (h->type!=bfd_link_hash_defined) {
if (!q[u]->section)
FEerror("Symbol ~S is missing
section",1,make_simple_string(q[u]->name));
if (!my_plt(q[u]->name,&pa)) {
/* printf("my_plt %s %p\n",q[u]->name,(void *)pa); */
if (q[u]->value && q[u]->value!=pa)
FEerror("plt address mismatch", 0);
else
q[u]->value=pa;
}
if (q[u]->value) {
h->type=bfd_link_hash_defined;
h->u.def.value=q[u]->value+q[u]->section->vma;
h->u.def.section=q[u]->section;
}
}
if (c) {
c=NULL;
}
}
objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
0812f590 l F .text 0000015b number_cos
0812f6f0 g F .text 00000047 Lcos
There is no objdump on this OSX 10.2 system. :-(
Shall I try to install GNU binutils? The version bundled with GCL
or a newer one?
The one in the GCL sources should be fine.
See next email.

Regards,
Bill Page.
Camm Maguire
2006-10-26 20:40:38 UTC
Permalink
Greetings, and thanks!
Post by Page, Bill
Camm,
Post by Camm Maguire
...
OK, will try to reactivate my sourceforge status. Something
changed over the summer.
Yes, there were some problems with access to the compile farm.
That seems to be fixed now.
Post by Camm Maguire
./configure --enable-debug && make
cd unixport
make raw_pre_gcl
gdb raw_pre_gcl
(gdb) b sfasli.c:65
(gdb) r ./
(gdb) cond 1 strstr(q[u]->name,"srget")
(gdb) c
(gdb) p q[u]->name
(gdb) p q[u]->section->name
(gdb) p q[u]->flags
Thanks!
---------
ppc-osx3:~/osx/new/gcl-2.6.8pre $ ./configure
--prefix=/home/users/b/bi/billpage/osx --enable-locbfd
--disable-statsysbfd --enable-debug
...
ppc-osx3:~/osx/new/gcl-2.6.8pre $ make
...
makeinfo --html gcl-si.texi
makeinfo --html gcl-tk.texi
ppc-osx3:~/osx/new/gcl-2.6.8pre $ cd unixport
ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $ make raw_pre_gcl
ls: ../xgcl-2/*.o: No such file or directory
ls: ../mod/*.o: No such file or directory
ls: ../pcl/*.o: No such file or directory
ls: ../clcs/*.o: No such file or directory
ls: ../clcs/clcs_*.lisp: No such file or directory
touch raw_pre_gcl_map
gcc -no-cpp-precomp -o raw_pre_gcl \
-L. -lpre_gcl `echo -lm | sed -e 's/-lncurses/ /'` -lc -lgclp
ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $ gdb raw_pre_gcl
GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec 7 02:14:27 GMT
2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .. done
(gdb) b sfasli.c:65
Breakpoint 1 at 0xb1b54: file sfasli.c, line 65.
(gdb) r ./
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixpor
t/raw_pre_gcl ./
[Switching to process 27643 thread 0xb03]
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
DBEGIN: 0x122000
mach_mapstart: 0x548000
heap_end: 0x548000
core_end: 0x548000
mach_brkpt: 0x548000
mach_maplimit: 0x20122000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1000 r x rwx (no zone)
0x2000 0xaf000 r x rwx (no zone)
0xb1000 0x1000 r x rwx (no zone)
0xb2000 0x70000 r x rwx (no zone)
0x122000 0x6000 rw rwx (no zone)
0x128000 0x420000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x40000 rw rwx DefaultMallocZone
0x865000 0x20000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x121000 r x rwx (no zone)
0x122000 0x426000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x60000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x825000
Lowest offset of all sections in __TEXT segment: 0xb18
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x121000
__text 0x1b18 0x10a410
__picsymbol_stub 0x10bf28 0x18e4
__symbol_stub 0x10d80c 0
__cstring 0x10d80c 0x12714
__literal4 0x11ff20 0x18
__literal8 0x11ff38 0xc8
__const 0x120000 0x1f9c
__eh_frame 0x121f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x122000 0x426000
__data 0x122000 0x25b0
__la_symbol_ptr 0x1245b0 0x2c4
__nl_symbol_ptr 0x124874 0x8fc
__dyld 0x125170 0x1c
__const 0x12518c 0x2748
__bss 0x1278d8 0x8f28
__common 0x130800 0x416d68
3 LC_SEGMENT 0x38 __LINKEDIT 0x548000 0x2dd000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
0)
0x121000)
0x6000)
0x25b0)
0x2c4)
0x8fc)
0x1c)
0x2748)
0x8f28)
0x416d68)
0)
0x2dcdf4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 17/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
1068 unused bytes follow Mach-O header
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe19090 in __dyld__dyld_start ()
(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixpor
t/raw_pre_gcl.tmp ..
Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags
& BSF_WEAK))
(gdb) p q[u]->name
$1 = 0x5742d1 "___srget"
(gdb) p q[u]->section->name
$2 = 0x114e74 "*UND*"
(gdb) p q[u]->flags
$3 = 2
(gdb) c
Continuing.
loading ./../lsp/gcl_export.lsp
loading ./../lsp/gcl_defmacro.lsp
loading ./../lsp/gcl_evalmacros.lsp
loading ./../lsp/gcl_top.lsp
loading ./../lsp/gcl_module.lsp
loading ./../lsp/gcl_autoload.lsp
Post by Camm Maguire
(quit)
Program exited normally.
(gdb) quit
ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $
--------
cond 1 (int) strstr(q[u]->name,"srget")
to avoid an error message about unknow return type.
Post by Camm Maguire
Post by Camm Maguire
Post by Camm Maguire
...
(my comments in ****)
for (u=0;u<v;u++) {
char *c=NULL;
struct bfd_link_hash_entry *h;
if (!*q[u]->name)
continue;
if (strncmp(q[u]->section->name,"*UND*",5) &&
!(q[u]->flags & BSF_WEAK))
continue;
Is value of flags=2 ok? What is BSF_WEAK?
h/bfd.h:#define BSF_WEAK 0x80
Post by Camm Maguire
Post by Camm Maguire
Post by Camm Maguire
*** the above might skip ___srget ***
It looks like it's gonna skip to me. Is that good or bad?
Actually, it looks like it will not skip due to the section->name.

Please verify this by stepping through with n and this point. In
fact, if you can step from this point to the bottom of this for loop
iteration, and then

(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,MY_BFD_FALSE,MY_BFD_TRUE)

that would be most helpful.
This is OK, as there is no other junk that needs special processing.
Post by Page, Bill
Post by Camm Maguire
Post by Camm Maguire
Post by Camm Maguire
*c=0;
if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRU
E,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
h->type=bfd_link_hash_new;
} else if
(!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FAL
SE,MY_BFD_FALSE,MY_BFD_TRUE)) &&
Post by Camm Maguire
!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_TRUE
,MY_BFD_TRUE,MY_BFD_TRUE)))
FEerror("Cannot make new hash entry",0);
if (h->type!=bfd_link_hash_defined) {
if (!q[u]->section)
FEerror("Symbol ~S is missing
section",1,make_simple_string(q[u]->name));
if (!my_plt(q[u]->name,&pa)) {
/* printf("my_plt %s %p\n",q[u]->name,(void *)pa); */
if (q[u]->value && q[u]->value!=pa)
FEerror("plt address mismatch", 0);
else
q[u]->value=pa;
}
if (q[u]->value) {
h->type=bfd_link_hash_defined;
h->u.def.value=q[u]->value+q[u]->section->vma;
h->u.def.section=q[u]->section;
}
}
if (c) {
c=NULL;
}
}
objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
0812f590 l F .text 0000015b number_cos
0812f6f0 g F .text 00000047 Lcos
There is no objdump on this OSX 10.2 system. :-(
Shall I try to install GNU binutils? The version bundled with GCL
or a newer one?
The one in the GCL sources should be fine.
See next email.
Thanks again!

Take care,
Post by Page, Bill
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire
2006-10-26 23:01:16 UTC
Permalink
Greetings! Just wondering if this is the last axiom issue with
2.6.8pre outstanding. If not, what are the others? If more testing
time is needed to answer this, how much more?

Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
root
2006-10-27 03:45:24 UTC
Permalink
Camm,

I just tried a build of GCL on Fedora Core 5.
rm raw_pre_gcl init_pre_gcl.lisp
make[4]: Leaving directory '/root/silver3/lsp/gcl-2.6.8pre/unixport'
(cd lsp; touch *.lsp ; make all)
make[4]: Entering directory '/root/silver3/lsp/gcl-2.6.8pre/lsp'

Unrecoverable error: Segmentation violation..
../xbin/if-exists: line 13: 9412 Aborted $3
gcc: gcl_arraylib.c: No such file or directory
gcc: no input files
cat: gcl_arraylib.data: No such file or directory



gcc --version
gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)



The version of gcl is the one called gcl-2.6.8pre in the axiom/zips
directory. I'm now going to retry the build using gcl-2.6.8pre2
which is a slightly later version. If that fails I'll check out
the HEAD and try that.

Tim
Camm Maguire
2006-10-27 14:05:06 UTC
Permalink
Greetings!
Post by root
Camm,
I just tried a build of GCL on Fedora Core 5.
rm raw_pre_gcl init_pre_gcl.lisp
make[4]: Leaving directory '/root/silver3/lsp/gcl-2.6.8pre/unixport'
(cd lsp; touch *.lsp ; make all)
make[4]: Entering directory '/root/silver3/lsp/gcl-2.6.8pre/lsp'
Unrecoverable error: Segmentation violation..
../xbin/if-exists: line 13: 9412 Aborted $3
gcc: gcl_arraylib.c: No such file or directory
gcc: no input files
cat: gcl_arraylib.data: No such file or directory
My money at this juncture is on the randomized sbrk, which has already
broken the GCL build twice on Fedora. Sigh.

Please check the configure output for randomized sbrk. And then
please

./configure --enable-debug && make
cd unixport
make raw_pre_gcl
gdb raw_pre_gcl
(gdb) r ./

and please then post the location of the segfault.
Post by root
gcc --version
gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
The version of gcl is the one called gcl-2.6.8pre in the axiom/zips
directory. I'm now going to retry the build using gcl-2.6.8pre2
which is a slightly later version. If that fails I'll check out
the HEAD and try that.
Just to clarify, there are two active gcl branches at the moment,
2.6.8pre, and 'head'. The latter is the experimental 2.7.0 and is not
yet ready for production. The former is a bugfix only point release
agains tthe stable 2.6.7. So please be sure to add -r
Version_2_6_8pre to your cvs checkouts.

Take care,
Post by root
Tim
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
root
2006-10-27 03:59:25 UTC
Permalink
Camm,

gcl-2.6.8pre2 fails exactly the same way on Fedora Core 5.
rm raw_pre_gcl init_pre_gcl.lisp
make[4]: Leaving directory '/root/silver3/lsp/gcl-2.6.8pre/unixport'
(cd lsp; touch *.lsp ; make all)
make[4]: Entering directory '/root/silver3/lsp/gcl-2.6.8pre/lsp'

Unrecoverable error: Segmentation violation..
../xbin/if-exists: line 13: 9412 Aborted $3
gcc: gcl_arraylib.c: No such file or directory
gcc: no input files
cat: gcl_arraylib.data: No such file or directory



gcc --version
gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)




Tim
Page, Bill
2006-10-26 00:42:43 UTC
Permalink
Camm,

See output of objdump as suggested below.
Post by Page, Bill
...
Post by Camm Maguire
objdump -x /usr/lib/gcl-2.6.7/unixport/saved_gcl |grep cos
0812f590 l F .text 0000015b number_cos
0812f6f0 g F .text 00000047 Lcos
...
See next email.
ppc-osx3:~/osx/new/gcl-2.6.8pre $ objdump -x unixport/saved_gcl | grep
cos

00000000 d *UND* unexmacosx.c
0000db14 d *UND* unexmacosx.c
00000000 d *UND*
passwd:T(1,94)=s40pw_name:(1,1),0,32;pw_passwd:(1,1),32,32;pw_uid:(1,95)
=(1,96)=(1,65),64,32;pw_gid:(1,97)=(1,96),96,32;pw_change:(1,98)=(1,41),
128,32;pw_class:(1,1),160,32;pw_gecos:(1,1),192,32;pw_dir:(1,1),224,32;p
w_shell:(1,1),256,32;pw_expire:(1,98),288,32;;
00278f5c *UND* _number_cos
00278f5c d *UND* number_cos:f(1,2)
00279930 d *UND* Lcos:F(1,53)
00279930 g *UND* _Lcos
00000000 g *UND* _acos
00000000 g *UND* _acosh
00000000 g *UND* _cos
00000000 g *UND* _cosh

ppc-osx3:~/osx/new/gcl-2.6.8pre $ objdump -x unixport/saved_gcl | grep
srget
00000000 g *UND* ___srget
ppc-osx3:~/osx/new/gcl-2.6.8pre $
Page, Bill
2006-10-27 01:27:24 UTC
Permalink
Camm,

I give you the gdb output you requested in the next email.
But now that you mention it...
Post by Camm Maguire
Greetings! Just wondering if this is the last axiom issue with
2.6.8pre outstanding. If not, what are the others? If more
testing time is needed to answer this, how much more?
I *am* currently fighting with another problem with the
gcl-2.6.8pre build. When building gcl on an x86-64 Ubuntu
system, the following segment of the ./configure script fails
to create a valid value for EMACS_SITE_LISP. I see from the
email lists that this hack has caused some trouble in the past.

------

echo $ac_n "checking emacs site lisp directory""... $ac_c" 1>&6
echo "configure:6251: checking emacs site lisp directory" >&5
if [ "$EMACS_SITE_LISP" = "unknown" ] ; then
if [ "$EMACS" != "" ] ; then
EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l
conftest.el 2>&1 | grep -v ^Warning: | sed -e /Loading/d | sed -e
/load/d `
else
EMACS_SITE_LISP=""
fi
fi
echo "$ac_t""$EMACS_SITE_LISP" 1>&6

--------

On the particular system where is is a problem, I get the following
output from emacs:

$ /usr/bin/emacs -q -batch
/home/page/sage-1.4.1.2-x86_64-Linux/local/lib/libpng-l conftest.el
/usr/bin/emacs:
/home/page/sage-1.4.1.2-x86_64-Linux/local/lib/libpng12.so.0: no version
information available (required by /usr/bin/emacs)
Loading 00debian-vars...
No /etc/mailname. Reverting to default...
Loading 50autoconf (source)...
Package autoconf removed but not purged. Skipping setup.
Loading 50cscope (source)...
Loading 50ocaml-nox (source)...
Loading 50octave (source)...
Loading 50psvn (source)...
Loading 50python-mode (source)...
Loading 50vc-svn (source)...

--------

It seems to me there ought to be a better way. I think
the conftest.el:

cat >> conftest.el <<EOF
(let ((ans ".") (tem load-path) cur)
(while (setq cur (car tem))
(setq tem (cdr tem))
(cond ((and (string-match "site-lisp/?$" cur) (file-directory-p cur))
(setq ans cur)
(if (string-match "-0-9.+$" cur) nil
(setq tem nil)))))
(message ans))
EOF

-------

should be re-written to emit a unique marker for the information
for which we are looking. E.g. something like this:

cat >> conftest.el <<EOF
(let ((ans ".") (tem load-path) cur)
(while (setq cur (car tem))
(setq tem (cdr tem))
(cond ((and (string-match "site-lisp/?$" cur) (file-directory-p cur))
(setq ans cur)
(if (string-match "-0-9.+$" cur) nil
(setq tem nil)))))
(message (concat "<filename>" ans "<filename>"))
EOF

--------

(Maybe you have to fix my lisp.)

But then in .configure we can write something simple and reliable:

EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 |
\
awk -F '<filename>' '/<filename>(.*)<filename>/ {print $2}'`

Regards,
Bill Page.
Page, Bill
2006-10-27 01:52:37 UTC
Permalink
Camm,
Post by Camm Maguire
Greetings! Just wondering if this is the last axiom issue with
2.6.8pre outstanding. If not, what are the others? If more testing
time is needed to answer this, how much more?
Here is the debugging output you asked for in your previous email.
Post by Camm Maguire
...
Please verify this by stepping through with n and this point. In
fact, if you can step from this point to the bottom of this for loop
iteration, and then
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,M
Y_BFD_FALSE,MY_BFD_TRUE)
Post by Camm Maguire
that would be most helpful.
--------

(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixpor
t/raw_pre_gcl.tmp ..

Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags
& BSF_WEAK))
(gdb) p q[u]->name
$1 = 0x5742d1 "___srget"
(gdb) p q[u]->section->name
$2 = 0x114e74 "*UND*"
(gdb) p q[u]->flags
$3 = 2
(gdb) n
68 if ((c=(char *)strstr(q[u]->name,"@@"))) {
(gdb) n
73 } else if
(gdb) n
78 if (h->type!=bfd_link_hash_defined) {
(gdb) n
79 if (!q[u]->section)
(gdb) n
81 if (!my_plt(q[u]->name,&pa)) {
(gdb) n
88 if (q[u]->value) {
(gdb) n
95 if (c) {
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,MY_BFD_FALS
E,MY_BFD_TRUE)
No symbol "MY_BFD_FALSE" in current context.
(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,MY_BFD_TRUE)
No symbol "MY_BFD_TRUE" in current context.
(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,1)
$4 = {
root = {
next = 0x0,
string = 0x76db28 "___srget",
hash = 163640344
},
type = bfd_link_hash_undefined,
u = {
undef = {
next = 0x76db34,
abfd = 0x54a2f0,
weak = 0x0
},
def = {
next = 0x76db34,
section = 0x54a2f0,
value = 0
},
i = {
next = 0x76db34,
link = 0x54a2f0,
warning = 0x0
},
c = {
next = 0x76db34,
p = 0x54a2f0,
size = 0
}
}
}
(gdb) n
58 for (u=0;u<v;u++) {
(gdb)

------------

I guess it didn't know MY_BFD_FALSE and MY_BFD_TRUE but I
took a wild guess at what these symbols might be. Is this
output useful to you?

Regards,
Bill Page.
Camm Maguire
2006-10-27 15:04:56 UTC
Permalink
Greetings!
Post by Page, Bill
Camm,
Post by Camm Maguire
Greetings! Just wondering if this is the last axiom issue with
2.6.8pre outstanding. If not, what are the others? If more testing
time is needed to answer this, how much more?
Here is the debugging output you asked for in your previous email.
Post by Camm Maguire
...
Please verify this by stepping through with n and this point. In
fact, if you can step from this point to the bottom of this for loop
iteration, and then
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,M
Y_BFD_FALSE,MY_BFD_TRUE)
Post by Camm Maguire
that would be most helpful.
--------
(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixpor
t/raw_pre_gcl.tmp ..
Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags
& BSF_WEAK))
(gdb) p q[u]->name
$1 = 0x5742d1 "___srget"
(gdb) p q[u]->section->name
$2 = 0x114e74 "*UND*"
(gdb) p q[u]->flags
$3 = 2
(gdb) n
(gdb) n
73 } else if
(gdb) n
78 if (h->type!=bfd_link_hash_defined) {
(gdb) n
79 if (!q[u]->section)
(gdb) n
81 if (!my_plt(q[u]->name,&pa)) {
(gdb) n
88 if (q[u]->value) {
(gdb) n
95 if (c) {
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,MY_BFD_FALS
E,MY_BFD_TRUE)
No symbol "MY_BFD_FALSE" in current context.
(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,MY_BFD_TRUE)
No symbol "MY_BFD_TRUE" in current context.
(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,1)
$4 = {
root = {
next = 0x0,
string = 0x76db28 "___srget",
hash = 163640344
},
type = bfd_link_hash_undefined,
u = {
undef = {
next = 0x76db34,
abfd = 0x54a2f0,
weak = 0x0
},
def = {
next = 0x76db34,
section = 0x54a2f0,
value = 0
},
i = {
next = 0x76db34,
link = 0x54a2f0,
warning = 0x0
},
c = {
next = 0x76db34,
p = 0x54a2f0,
size = 0
}
}
}
Perfect! Here is the problem -- the symbol has no value, to the code
never defines its address
Post by Page, Bill
88 if (q[u]->value) {
type = bfd_link_hash_undefined,
It would be helpful if you could break at line 89, and make sure that
other symbols are defined through their symbol value. Preferably,
others in plt.h.

But before this, please step into my_plt with

(gdb) s

and step through the code.

This is also of interest therein:

(gdb) p mplt

and, before executing line 180:

(gdb) b pltcomp

then at each break into pltcomp, try to see why the named symbol is
not found.

BTW, is this macosx intel? If not, has anyone tried this?

Take care,
Post by Page, Bill
(gdb) n
58 for (u=0;u<v;u++) {
(gdb)
------------
I guess it didn't know MY_BFD_FALSE and MY_BFD_TRUE but I
took a wild guess at what these symbols might be. Is this
output useful to you?
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-10-27 02:08:46 UTC
Permalink
Post by Page, Bill
I *am* currently fighting with another problem with the
gcl-2.6.8pre build. When building gcl on an x86-64 Ubuntu
system, the following segment of the ./configure script fails
to create a valid value for EMACS_SITE_LISP. I see from the
email lists that this hack has caused some trouble in the past.
...
It seems to me there ought to be a better way.
...
Here is an actual patch that implements the new test. It works
on my current targe system, but I haven't tested it any further.

---------

***@sage:~/sage-1.4.1.2-x86_64-Linux$ diff -au
~/axiom.build/lsp/gcl-2.6.8pre/configure
spkg/build/axiom4sage-0.1/lsp/gcl-2.6.8pre/configure
--- /home/page/axiom.build/lsp/gcl-2.6.8pre/configure 2006-09-17
14:56:50.000000000 -0700
+++ spkg/build/axiom4sage-0.1/lsp/gcl-2.6.8pre/configure
2006-10-26 19:18:59.000000000 -0700
@@ -6243,14 +6243,14 @@
(setq ans cur)
(if (string-match "-0-9.+$" cur) nil
(setq tem nil)))))
- (message ans))
+ (message (concat "<filename>" ans "<filename>)))
EOF

echo $ac_n "checking emacs site lisp directory""... $ac_c" 1>&6
echo "configure:6251: checking emacs site lisp directory" >&5
if [ "$EMACS_SITE_LISP" = "unknown" ] ; then
if [ "$EMACS" != "" ] ; then
- EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l
conftest.el 2>&1 | grep -v ^Warning: | sed -e /Loading/d | sed -e
/load/d `
+ EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l
conftest.el 2>&1 | awk -F '<filename>' '/<filename>(.*)<filename>/
{print $2}' `
else
EMACS_SITE_LISP=""
fi
@@ -6267,13 +6267,13 @@
(setq file (expand-file-name "/default.el" (car tem))))
(setq tem nil) (setq ans file)))
(setq tem (cdr tem)))
- (message ans))
+ (message (concat "<filename>" ans "<filename>")))
EOF

echo $ac_n "checking emacs default.el""... $ac_c" 1>&6
echo "configure:6275: checking emacs default.el" >&5
if [ "$EMACS" != "" ] ; then
- EMACS_DEFAULT_EL=`$EMACS -q -batch --no-site-file -l conftest.el
2>&1 | sed -e /Loading/d | sed -e /load/d `
+ EMACS_DEFAULT_EL=`$EMACS -q -batch --no-site-file -l conftest.el
2>&1 | awk -F '<filename>' '/<filename>(.*)<filename>/ {print $2}' `
else
EMACS_DEFAULT_EL=""
fi
***@sage:~/sage-1.4.1.2-x86_64-Linux$

----------

Regards,
Bill Page.
Gabriel Dos Reis
2006-10-27 02:19:29 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Thursday, October 26, 2006 9:27 PM I wrote:
| >
| > I *am* currently fighting with another problem with the
| > gcl-2.6.8pre build. When building gcl on an x86-64 Ubuntu
| > system, the following segment of the ./configure script fails
| > to create a valid value for EMACS_SITE_LISP. I see from the
| > email lists that this hack has caused some trouble in the past.
| > ...
| > It seems to me there ought to be a better way.
| > ...
|
| Here is an actual patch that implements the new test. It works
| on my current targe system, but I haven't tested it any further.
|
| ---------
|
| ***@sage:~/sage-1.4.1.2-x86_64-Linux$ diff -au
| ~/axiom.build/lsp/gcl-2.6.8pre/configure
| spkg/build/axiom4sage-0.1/lsp/gcl-2.6.8pre/configure

I think you want to patch configure.in, not configure.

-- Gaby
Page, Bill
2006-10-27 02:36:05 UTC
Permalink
Post by Gabriel Dos Reis
...
|
| ~/axiom.build/lsp/gcl-2.6.8pre/configure
| spkg/build/axiom4sage-0.1/lsp/gcl-2.6.8pre/configure
I think you want to patch configure.in, not configure.
Yes, of course. However I do not have autoconf on the target
system where I am now working. So a patch to configure.in is
left as an "exercise for the reader" :-)

On the other hand I do have makeinfo ...

Regards,
Bill Page.
Gabriel Dos Reis
2006-10-27 02:54:43 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Thursday, October 26, 2006 10:19 PM Gaby wrote:
|
| > ...
| > Bill Page wrote:
| > |
| > | ***@sage:~/sage-1.4.1.2-x86_64-Linux$ diff -au
| > | ~/axiom.build/lsp/gcl-2.6.8pre/configure
| > | spkg/build/axiom4sage-0.1/lsp/gcl-2.6.8pre/configure
| >
| > I think you want to patch configure.in, not configure.
| >
|
| Yes, of course. However I do not have autoconf on the target
| system where I am now working. So a patch to configure.in is
| left as an "exercise for the reader" :-)
|
| On the other hand I do have makeinfo ...

It looks like we're working on antipodal machines :-) :-)

-- Gaby
Camm Maguire
2006-10-30 18:29:12 UTC
Permalink
Greetings! My understanding:

1) Bill's helpful emacs site lisp patch to configure.in
2) finish tracing down the plt issue on macosx
3) figure out the error in fc6.

This is complete, right? 1) is waiting on me. I think the latest
email on 2 and 3 went out from me to Bill and Tim resp. with requested
gdb commands therein. I only write this as I'm noticing a lot more
traffic on axiom-developer on the web than I am getting locally.
Please do me the favor of cc'ing me directly until we can work out our
mailer problems.

Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Bill Page
2006-10-31 03:27:08 UTC
Permalink
Camm,

Here is the gdb output for the MAC OSX plt issue.

I think the result is fairly definitive. See this section below:

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123ad4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p2->n
$8 = 0x11574c "__srget"
(gdb) p p1->n
$9 = 0x5742d1 "___srget"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
my_plt (s=0x5742d1 "___srget", v=0xbffff668) at plt.c:185
185 return -1;
(gdb) n
187 }

--------

It seems as if pltcomp is not respecting the leading underscore
for the comparison.

Can you suggest fix?

Regards,
Bill Page.

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2006.10.30 21:24:00
=~=~=~=~=~=~=~=~=~=~=~=
ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $ gdb raw_pre_gcl
GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec 7 02:14:27 GMT 2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .. done
(gdb) b sfasli.c:65
Breakpoint 1 at 0xb1b54: file sfasli.c, line 65.
(gdb) r ./
Starting program:
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixport/ra
w_pre_gcl ./
[Switching to process 17648 thread 0xb03]
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
DBEGIN: 0x122000
mach_mapstart: 0x548000
heap_end: 0x548000
core_end: 0x548000
mach_brkpt: 0x548000
mach_maplimit: 0x20122000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1000 r x rwx (no zone)
0x2000 0xaf000 r x rwx (no zone)
0xb1000 0x1000 r x rwx (no zone)
0xb2000 0x70000 r x rwx (no zone)
0x122000 0x6000 rw rwx (no zone)
0x128000 0x420000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x40000 rw rwx DefaultMallocZone
0x865000 0x20000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x121000 r x rwx (no zone)
0x122000 0x426000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x60000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x825000
Lowest offset of all sections in __TEXT segment: 0xb18
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x121000
__text 0x1b18 0x10a410
__picsymbol_stub 0x10bf28 0x18e4
__symbol_stub 0x10d80c 0
__cstring 0x10d80c 0x12714
__literal4 0x11ff20 0x18
__literal8 0x11ff38 0xc8
__const 0x120000 0x1f9c
__eh_frame 0x121f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x122000 0x426000
__data 0x122000 0x25b0
__la_symbol_ptr 0x1245b0 0x2c4
__nl_symbol_ptr 0x124874 0x8fc
__dyld 0x125170 0x1c
__const 0x12518c 0x2748
__bss 0x1278d8 0x8f28
__common 0x130800 0x416d68
3 LC_SEGMENT 0x38 __LINKEDIT 0x548000 0x2dd000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x121000 (sz: 0x121000)
Writing segment __DATA at 0x121000 - 0x127000 (sz: 0x6000)
section __data at 0x121000 - 0x1235b0 (sz: 0x25b0)
section __la_symbol_ptr at 0x1235b0 - 0x123874 (sz: 0x2c4)
section __nl_symbol_ptr at 0x123874 - 0x124170 (sz: 0x8fc)
section __dyld at 0x124170 - 0x12418c (sz: 0x1c)
section __const at 0x12418c - 0x1268d4 (sz: 0x2748)
section __bss at 0x1268d8 - 0x12f800 (sz: 0x8f28)
section __common at 0x12f800 - 0x546568 (sz: 0x416d68)
Writing segment __DATA at 0x547000 - 0x547000 (sz: 0)
Writing segment __LINKEDIT at 0x547000 - 0x823df4 (sz: 0x2dcdf4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 17/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
1068 unused bytes follow Mach-O header

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe19090 in __dyld__dyld_start ()
(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixport/ra
w_pre_gcl.tmp ..

Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags &
BSF_WEAK))
(gdb) n
68 if ((c=(char *)strstr(q[u]->name,"@@"))) {
(gdb) n
73 } else if
(gdb) n
78 if (h->type!=bfd_link_hash_defined) {
(gdb) n
79 if (!q[u]->section)
(gdb) n
81 if (!my_plt(q[u]->name,&pa)) {
(gdb) s
my_plt (s=0x5742d1 "___srget", v=0xbffff668) at plt.c:167
167 Plt *p=mplt,*pe=p+sizeof(mplt)/sizeof(*mplt),tp;
(gdb) n
170 if (sSAplt_tableA->s.s_dbind &&
(gdb) p mplt
$1 = {{
n = 0x11574c "__srget",
ad = 2415981216
}, {
n = 0x115754 "__swbuf",
ad = 2416038784
}, {
n = 0x11575c "acos",
ad = 2416205440
}, {
n = 0x115764 "acosh",
ad = 2416569920
}, {
n = 0x11576c "asin",
ad = 2416570304
}, {
n = 0x115774 "asinh",
ad = 2416569588
}, {
n = 0x11577c "atan",
ad = 2416568404
}, {
n = 0x115784 "atanh",
ad = 2416569296
}, {
n = 0x11578c "cos",
ad = 2416185248
}, {
n = 0x115790 "cosh",
ad = 2416590880
}, {
n = 0x115798 "exp",
ad = 2416186144
}, {
n = 0x11579c "log",
ad = 2416181504
}, {
n = 0x1157a0 "setjmp",
ad = 2416214272
}, {
n = 0x1157a8 "sin",
ad = 2416179488
}, {
n = 0x1157ac "sinh",
ad = 2416590620
}, {
n = 0x1157b4 "tan",
ad = 2416183744
}, {
n = 0x1157b8 "tanh",
ad = 2416591016
}}
(gdb) n
179 tp.n=s;
(gdb) b pltcomp
Breakpoint 2 at 0xbe75c: file plt.c, line 25.
(gdb) n
180 if ((p=bsearch(&tp,p,pe-p,sizeof(*p),pltcomp))) {
(gdb) n

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123b14) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p1->n
$2 = 0x5742d1 "___srget"
(gdb) p p2->n
$3 = 0x11578c "cos"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123af4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p1->n
$5 = 0x5742d1 "___srget"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123ae4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) p p2->n
$6 = 0x11576c "asin"
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123adc) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p2->n
$7 = 0x115754 "__swbuf"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123ad4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p2->n
$8 = 0x11574c "__srget"
(gdb) p p1->n
$9 = 0x5742d1 "___srget"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
my_plt (s=0x5742d1 "___srget", v=0xbffff668) at plt.c:185
185 return -1;
(gdb) n
187 }
(gdb) n
build_symbol_table_bfd () at sfasli.c:88
88 if (q[u]->value) {
(gdb) b sfasli.c:89
Breakpoint 3 at 0xb1e28: file sfasli.c, line 89.
(gdb) c
Continuing.

Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123b14) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) cl
Deleted breakpoint 2
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) p q[u]->name
$10 = 0x575f53 "_acos"
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) p q[u]->name
$11 = 0x575f59 "_acosh"
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$12 = 0x575f60 "_asin"
(gdb) p q[u]->name
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$13 = 0x575f66 "_asinh"
(gdb) p q[u]->name
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$14 = 0x575f6d "_atan"
(gdb) p q[u]->name
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$15 = 0x575f73 "_atanh"
(gdb) p q[u]->name
(gdb) c
Continuing.

Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$16 = 0x575f83 "_cos"
(gdb)

-----------
Post by Camm Maguire
-----Original Message-----
Sent: October 27, 2006 11:05 AM
Subject: Re: gcl-2.6.8pre on MAC OSX 10.2
Greetings!
Post by Page, Bill
Camm,
Post by Camm Maguire
Greetings! Just wondering if this is the last axiom issue with
2.6.8pre outstanding. If not, what are the others? If
more testing
Post by Page, Bill
Post by Camm Maguire
time is needed to answer this, how much more?
Here is the debugging output you asked for in your previous email.
Post by Camm Maguire
...
Please verify this by stepping through with n and this point. In
fact, if you can step from this point to the bottom of
this for loop
Post by Page, Bill
Post by Camm Maguire
iteration, and then
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,M
Y_BFD_FALSE,MY_BFD_TRUE)
Post by Camm Maguire
that would be most helpful.
--------
(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8p
re/unixpor
Post by Page, Bill
t/raw_pre_gcl.tmp ..
Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) &&
!(q[u]->flags
Post by Page, Bill
& BSF_WEAK))
(gdb) p q[u]->name
$1 = 0x5742d1 "___srget"
(gdb) p q[u]->section->name
$2 = 0x114e74 "*UND*"
(gdb) p q[u]->flags
$3 = 2
(gdb) n
(gdb) n
73 } else if
(gdb) n
78 if (h->type!=bfd_link_hash_defined) {
(gdb) n
79 if (!q[u]->section)
(gdb) n
81 if (!my_plt(q[u]->name,&pa)) {
(gdb) n
88 if (q[u]->value) {
(gdb) n
95 if (c) {
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,M
Y_BFD_FALS
Post by Page, Bill
E,MY_BFD_TRUE)
No symbol "MY_BFD_FALSE" in current context.
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,MY_BFD_TRUE)
Post by Page, Bill
No symbol "MY_BFD_TRUE" in current context.
(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,1)
$4 = {
root = {
next = 0x0,
string = 0x76db28 "___srget",
hash = 163640344
},
type = bfd_link_hash_undefined,
u = {
undef = {
next = 0x76db34,
abfd = 0x54a2f0,
weak = 0x0
},
def = {
next = 0x76db34,
section = 0x54a2f0,
value = 0
},
i = {
next = 0x76db34,
link = 0x54a2f0,
warning = 0x0
},
c = {
next = 0x76db34,
p = 0x54a2f0,
size = 0
}
}
}
Perfect! Here is the problem -- the symbol has no value, to the code
never defines its address
Post by Page, Bill
88 if (q[u]->value) {
type = bfd_link_hash_undefined,
It would be helpful if you could break at line 89, and make sure that
other symbols are defined through their symbol value. Preferably,
others in plt.h.
But before this, please step into my_plt with
(gdb) s
and step through the code.
(gdb) p mplt
(gdb) b pltcomp
then at each break into pltcomp, try to see why the named symbol is
not found.
BTW, is this macosx intel? If not, has anyone tried this?
Take care,
Post by Page, Bill
(gdb) n
58 for (u=0;u<v;u++) {
(gdb)
------------
I guess it didn't know MY_BFD_FALSE and MY_BFD_TRUE but I
took a wild guess at what these symbols might be. Is this
output useful to you?
Regards,
Bill Page.
--
Camm Maguire
==============================================================
============
"The earth is but one country, and mankind its citizens." --
Baha'u'llah
Camm Maguire
2006-10-31 13:43:07 UTC
Permalink
Greetings, and thanks! OK, please try it now, I think it should be
fixed. Please let me know if problems persist.

Take care,
Post by Bill Page
Camm,
Here is the gdb output for the MAC OSX plt issue.
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123ad4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p2->n
$8 = 0x11574c "__srget"
(gdb) p p1->n
$9 = 0x5742d1 "___srget"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
my_plt (s=0x5742d1 "___srget", v=0xbffff668) at plt.c:185
185 return -1;
(gdb) n
187 }
--------
It seems as if pltcomp is not respecting the leading underscore
for the comparison.
Can you suggest fix?
Regards,
Bill Page.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2006.10.30 21:24:00
=~=~=~=~=~=~=~=~=~=~=~=
ppc-osx3:~/osx/new/gcl-2.6.8pre/unixport $ gdb raw_pre_gcl
GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec 7 02:14:27 GMT 2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .. done
(gdb) b sfasli.c:65
Breakpoint 1 at 0xb1b54: file sfasli.c, line 65.
(gdb) r ./
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixport/ra
w_pre_gcl ./
[Switching to process 17648 thread 0xb03]
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
DBEGIN: 0x122000
mach_mapstart: 0x548000
heap_end: 0x548000
core_end: 0x548000
mach_brkpt: 0x548000
mach_maplimit: 0x20122000
--- List of All Regions ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x1000 r x rwx (no zone)
0x2000 0xaf000 r x rwx (no zone)
0xb1000 0x1000 r x rwx (no zone)
0xb2000 0x70000 r x rwx (no zone)
0x122000 0x6000 rw rwx (no zone)
0x128000 0x420000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x40000 rw rwx DefaultMallocZone
0x865000 0x20000 rw rwx DefaultMallocZone
--- List of Regions to be Dumped ---
address size prot maxp zone_name
0 0x1000 none none (no zone)
0x1000 0x121000 r x rwx (no zone)
0x122000 0x426000 rw rwx (no zone)
0x548000 0x2dd000 r rwx (no zone)
0x825000 0x60000 rw rwx DefaultMallocZone
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 0
FileType = 0x2
NCmds = 10
SizeOfCmds = 1620
Flags = 0x00000085
Highest address of load commands in input file: 0x825000
Lowest offset of all sections in __TEXT segment: 0xb18
--- List of Load Commands in Input File ---
no cmd cmdsize name address size
0 LC_SEGMENT 0x38 __PAGEZERO 0 0x1000
1 LC_SEGMENT 0x258 __TEXT 0x1000 0x121000
__text 0x1b18 0x10a410
__picsymbol_stub 0x10bf28 0x18e4
__symbol_stub 0x10d80c 0
__cstring 0x10d80c 0x12714
__literal4 0x11ff20 0x18
__literal8 0x11ff38 0xc8
__const 0x120000 0x1f9c
__eh_frame 0x121f9c 0x60
2 LC_SEGMENT 0x214 __DATA 0x122000 0x426000
__data 0x122000 0x25b0
__la_symbol_ptr 0x1245b0 0x2c4
__nl_symbol_ptr 0x124874 0x8fc
__dyld 0x125170 0x1c
__const 0x12518c 0x2748
__bss 0x1278d8 0x8f28
__common 0x130800 0x416d68
3 LC_SEGMENT 0x38 __LINKEDIT 0x548000 0x2dd000
4 LC_LOAD_DYLINKER 0x1c
5 LC_LOAD_DYLIB 0x34
6 LC_SYMTAB 0x18
7 LC_DYSYMTAB 0x50
8 LC_TWOLEVEL_HINTS 0x10
9 LC_UNIXTHREAD 0xb0
--- Load Commands written to Output File ---
Writing segment __PAGEZERO at 0 - 0 (sz: 0)
Writing segment __TEXT at 0 - 0x121000 (sz: 0x121000)
Writing segment __DATA at 0x121000 - 0x127000 (sz: 0x6000)
section __data at 0x121000 - 0x1235b0 (sz: 0x25b0)
section __la_symbol_ptr at 0x1235b0 - 0x123874 (sz: 0x2c4)
section __nl_symbol_ptr at 0x123874 - 0x124170 (sz: 0x8fc)
section __dyld at 0x124170 - 0x12418c (sz: 0x1c)
section __const at 0x12418c - 0x1268d4 (sz: 0x2748)
section __bss at 0x1268d8 - 0x12f800 (sz: 0x8f28)
section __common at 0x12f800 - 0x546568 (sz: 0x416d68)
Writing segment __DATA at 0x547000 - 0x547000 (sz: 0)
Writing segment __LINKEDIT at 0x547000 - 0x823df4 (sz: 0x2dcdf4)
Writing LC_LOAD_DYLINKER command
Writing LC_LOAD_DYLIB command
Writing LC_SYMTAB command
Fixed up 17/17 external relocation entries in data segment.
Writing LC_DYSYMTAB command
Writing LC_TWOLEVEL_HINTS command
Writing LC_UNIXTHREAD command
1068 unused bytes follow Mach-O header
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe19090 in __dyld__dyld_start ()
(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/unixport/ra
w_pre_gcl.tmp ..
Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) && !(q[u]->flags &
BSF_WEAK))
(gdb) n
(gdb) n
73 } else if
(gdb) n
78 if (h->type!=bfd_link_hash_defined) {
(gdb) n
79 if (!q[u]->section)
(gdb) n
81 if (!my_plt(q[u]->name,&pa)) {
(gdb) s
my_plt (s=0x5742d1 "___srget", v=0xbffff668) at plt.c:167
167 Plt *p=mplt,*pe=p+sizeof(mplt)/sizeof(*mplt),tp;
(gdb) n
170 if (sSAplt_tableA->s.s_dbind &&
(gdb) p mplt
$1 = {{
n = 0x11574c "__srget",
ad = 2415981216
}, {
n = 0x115754 "__swbuf",
ad = 2416038784
}, {
n = 0x11575c "acos",
ad = 2416205440
}, {
n = 0x115764 "acosh",
ad = 2416569920
}, {
n = 0x11576c "asin",
ad = 2416570304
}, {
n = 0x115774 "asinh",
ad = 2416569588
}, {
n = 0x11577c "atan",
ad = 2416568404
}, {
n = 0x115784 "atanh",
ad = 2416569296
}, {
n = 0x11578c "cos",
ad = 2416185248
}, {
n = 0x115790 "cosh",
ad = 2416590880
}, {
n = 0x115798 "exp",
ad = 2416186144
}, {
n = 0x11579c "log",
ad = 2416181504
}, {
n = 0x1157a0 "setjmp",
ad = 2416214272
}, {
n = 0x1157a8 "sin",
ad = 2416179488
}, {
n = 0x1157ac "sinh",
ad = 2416590620
}, {
n = 0x1157b4 "tan",
ad = 2416183744
}, {
n = 0x1157b8 "tanh",
ad = 2416591016
}}
(gdb) n
179 tp.n=s;
(gdb) b pltcomp
Breakpoint 2 at 0xbe75c: file plt.c, line 25.
(gdb) n
180 if ((p=bsearch(&tp,p,pe-p,sizeof(*p),pltcomp))) {
(gdb) n
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123b14) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p1->n
$2 = 0x5742d1 "___srget"
(gdb) p p2->n
$3 = 0x11578c "cos"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123af4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p1->n
$5 = 0x5742d1 "___srget"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123ae4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) p p2->n
$6 = 0x11576c "asin"
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123adc) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p2->n
$7 = 0x115754 "__swbuf"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123ad4) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) n
27 return strcmp(stn(p1->n),stn(p2->n));
(gdb) p p2->n
$8 = 0x11574c "__srget"
(gdb) p p1->n
$9 = 0x5742d1 "___srget"
(gdb) n
29 }
(gdb) n
0x9000f8c8 in bsearch ()
(gdb) n
Single stepping until exit from function bsearch,
which has no line number information.
my_plt (s=0x5742d1 "___srget", v=0xbffff668) at plt.c:185
185 return -1;
(gdb) n
187 }
(gdb) n
build_symbol_table_bfd () at sfasli.c:88
88 if (q[u]->value) {
(gdb) b sfasli.c:89
Breakpoint 3 at 0xb1e28: file sfasli.c, line 89.
(gdb) c
Continuing.
Breakpoint 2, pltcomp (v1=0xbffaade0, v2=0x123b14) at plt.c:25
25 const Plt *p1=v1,*p2=v2;
(gdb) cl
Deleted breakpoint 2
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) p q[u]->name
$10 = 0x575f53 "_acos"
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) p q[u]->name
$11 = 0x575f59 "_acosh"
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$12 = 0x575f60 "_asin"
(gdb) p q[u]->name
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$13 = 0x575f66 "_asinh"
(gdb) p q[u]->name
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$14 = 0x575f6d "_atan"
(gdb) p q[u]->name
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$15 = 0x575f73 "_atanh"
(gdb) p q[u]->name
(gdb) c
Continuing.
Breakpoint 3, build_symbol_table_bfd () at sfasli.c:89
89 h->type=bfd_link_hash_defined;
(gdb) cp q[u]->name
$16 = 0x575f83 "_cos"
(gdb)
-----------
Post by Camm Maguire
-----Original Message-----
Sent: October 27, 2006 11:05 AM
Subject: Re: gcl-2.6.8pre on MAC OSX 10.2
Greetings!
Post by Page, Bill
Camm,
Post by Camm Maguire
Greetings! Just wondering if this is the last axiom issue with
2.6.8pre outstanding. If not, what are the others? If
more testing
Post by Page, Bill
Post by Camm Maguire
time is needed to answer this, how much more?
Here is the debugging output you asked for in your previous email.
Post by Camm Maguire
...
Please verify this by stepping through with n and this point. In
fact, if you can step from this point to the bottom of
this for loop
Post by Page, Bill
Post by Camm Maguire
iteration, and then
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,M
Y_BFD_FALSE,MY_BFD_TRUE)
Post by Camm Maguire
that would be most helpful.
--------
(gdb) cond 1 (int) strstr(q[u]->name,"srget")
(gdb) c
Continuing.
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for
/private/automount/home/users/b/bi/billpage/osx/new/gcl-2.6.8p
re/unixpor
Post by Page, Bill
t/raw_pre_gcl.tmp ..
Breakpoint 1, build_symbol_table_bfd () at sfasli.c:65
65 if (strncmp(q[u]->section->name,"*UND*",5) &&
!(q[u]->flags
Post by Page, Bill
& BSF_WEAK))
(gdb) p q[u]->name
$1 = 0x5742d1 "___srget"
(gdb) p q[u]->section->name
$2 = 0x114e74 "*UND*"
(gdb) p q[u]->flags
$3 = 2
(gdb) n
(gdb) n
73 } else if
(gdb) n
78 if (h->type!=bfd_link_hash_defined) {
(gdb) n
79 if (!q[u]->section)
(gdb) n
81 if (!my_plt(q[u]->name,&pa)) {
(gdb) n
88 if (q[u]->value) {
(gdb) n
95 if (c) {
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,MY_BFD_FALSE,M
Y_BFD_FALS
Post by Page, Bill
E,MY_BFD_TRUE)
No symbol "MY_BFD_FALSE" in current context.
(gdb) p
*bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,MY_BFD_TRUE)
Post by Page, Bill
No symbol "MY_BFD_TRUE" in current context.
(gdb) p *bfd_link_hash_lookup(link_info.hash,q[u]->name,0,0,1)
$4 = {
root = {
next = 0x0,
string = 0x76db28 "___srget",
hash = 163640344
},
type = bfd_link_hash_undefined,
u = {
undef = {
next = 0x76db34,
abfd = 0x54a2f0,
weak = 0x0
},
def = {
next = 0x76db34,
section = 0x54a2f0,
value = 0
},
i = {
next = 0x76db34,
link = 0x54a2f0,
warning = 0x0
},
c = {
next = 0x76db34,
p = 0x54a2f0,
size = 0
}
}
}
Perfect! Here is the problem -- the symbol has no value, to the code
never defines its address
Post by Page, Bill
88 if (q[u]->value) {
type = bfd_link_hash_undefined,
It would be helpful if you could break at line 89, and make sure that
other symbols are defined through their symbol value. Preferably,
others in plt.h.
But before this, please step into my_plt with
(gdb) s
and step through the code.
(gdb) p mplt
(gdb) b pltcomp
then at each break into pltcomp, try to see why the named symbol is
not found.
BTW, is this macosx intel? If not, has anyone tried this?
Take care,
Post by Page, Bill
(gdb) n
58 for (u=0;u<v;u++) {
(gdb)
------------
I guess it didn't know MY_BFD_FALSE and MY_BFD_TRUE but I
took a wild guess at what these symbols might be. Is this
output useful to you?
Regards,
Bill Page.
--
Camm Maguire
==============================================================
============
"The earth is but one country, and mankind its citizens." --
Baha'u'llah
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-11-01 12:36:11 UTC
Permalink
Camm,
Post by Camm Maguire
Greetings, and thanks! OK, please try it now, I think it should be
fixed. Please let me know if problems persist.
I have rebuilt gcl and restarted the build of Axiom from scratch.

Ooops! Looks like the problem has shifted to another symbol. :-(

...
Compiling
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
le-darwin6.8/interp/g-util.lsp.
...skipping...
Error: Undefined symbol "_sqrt"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at BUILD-INTERPSYS. Type :H for Help.
BOOT>>make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build
/powerpc-apple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
ppc-osx3:~/osx/axiom.build-improvements $

--------

Regards,
Bill Page.
Camm Maguire
2006-11-01 14:46:57 UTC
Permalink
Greetings, and thanks so much!
Post by Page, Bill
Camm,
Post by Camm Maguire
Greetings, and thanks! OK, please try it now, I think it should be
fixed. Please let me know if problems persist.
I have rebuilt gcl and restarted the build of Axiom from scratch.
Ooops! Looks like the problem has shifted to another symbol. :-(
...
Compiling
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
le-darwin6.8/interp/g-util.lsp.
...skipping...
Error: Undefined symbol "_sqrt"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at BUILD-INTERPSYS. Type :H for Help.
BOOT>>make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build
/powerpc-apple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
ppc-osx3:~/osx/axiom.build-improvements $
Sigh. As usual, I cannot reproduce on the mac to which I have
access. I'm assuming you see the same issue with

(defun foo (x) (declare (long-float x)) (the long-float (sqrt x)))
(compile 'foo)

Am also assuming that the read-byte test I posted earlier now passes.

In any case, would you please mind stepping through gdb again to the
same place? It should be obvious what is going on. The idea is that
the MY_PLT list in plt.h should have one _ stripped, and that the
string passed to my_plt should do the strip in the stn() C macro right
before the (second) call to bsearch.

I'll be leaving town tomorrow afternoon until Sunday, but would be
happy to fix this quickly today if possible.

Take care,
Post by Page, Bill
--------
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-11-01 15:27:11 UTC
Permalink
Camm,
Post by Page, Bill
Post by Page, Bill
Ooops! Looks like the problem has shifted to another symbol. :-(
...
Compiling
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
Post by Page, Bill
le-darwin6.8/interp/g-util.lsp.
...skipping...
Error: Undefined symbol "_sqrt"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at BUILD-INTERPSYS. Type :H for Help.
BOOT>>make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build
/powerpc-apple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
ppc-osx3:~/osx/axiom.build-improvements $
Sigh. As usual, I cannot reproduce on the mac to which I have
access. I'm assuming you see the same issue with
(defun foo (x) (declare (long-float x)) (the long-float (sqrt x)))
(compile 'foo)
Am also assuming that the read-byte test I posted earlier now
passes.
Yes. It seems that problem might be that 'sqrt' does not
appear in plt.h. So I added a call to sqrt(d); in plttest.c
and I am running it again.

Make sense?
Post by Page, Bill
In any case, would you please mind stepping through gdb again to the
same place? It should be obvious what is going on. The idea is that
the MY_PLT list in plt.h should have one _ stripped, and that the
string passed to my_plt should do the strip in the stn() C macro right
before the (second) call to bsearch.
I'll be leaving town tomorrow afternoon until Sunday, but would be
happy to fix this quickly today if possible.
I will let you know.

Thanks.

Regards,
Bill Page.
Camm Maguire
2006-11-01 17:37:50 UTC
Permalink
Greetings!
Post by Page, Bill
Camm,
Post by Page, Bill
Post by Page, Bill
Ooops! Looks like the problem has shifted to another symbol. :-(
...
Compiling
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
Post by Page, Bill
le-darwin6.8/interp/g-util.lsp.
...skipping...
Error: Undefined symbol "_sqrt"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at BUILD-INTERPSYS. Type :H for Help.
BOOT>>make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build
/powerpc-apple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
ppc-osx3:~/osx/axiom.build-improvements $
Sigh. As usual, I cannot reproduce on the mac to which I have
access. I'm assuming you see the same issue with
(defun foo (x) (declare (long-float x)) (the long-float (sqrt x)))
(compile 'foo)
Am also assuming that the read-byte test I posted earlier now
passes.
Yes. It seems that problem might be that 'sqrt' does not
appear in plt.h. So I added a call to sqrt(d); in plttest.c
and I am running it again.
Make sense?
Yes, indeed, and this is now committed. Thanks!

As the comments in plt.c indicate, we still need a mechanism whereby
improvements to gcl_cmpopt.lsp (which result in writing more C symbols
into compiled files) seemlessly updates plttest.c. Right now, we just
have to remember to make the change in both places, which in this case
failed :-(.

cvs head has a more thorough plttest which resists C optimizers'
attempts to eliminate dead code. I see no reason for a backport at
the moment.

Take care,
Post by Page, Bill
Post by Page, Bill
In any case, would you please mind stepping through gdb again to the
same place? It should be obvious what is going on. The idea is that
the MY_PLT list in plt.h should have one _ stripped, and that the
string passed to my_plt should do the strip in the stn() C macro right
before the (second) call to bsearch.
I'll be leaving town tomorrow afternoon until Sunday, but would be
happy to fix this quickly today if possible.
I will let you know.
Thanks.
Regards,
Bill Page.
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-11-01 17:47:30 UTC
Permalink
Camm,
...
It seems that problem might be that 'sqrt' does not appear in
plt.h. So I added a call to sqrt(d); in plttest.c and I am
running it again.
...
Ok, with your earlier change plus adding 'sqrt(d);' to plttest.c
that did it! At least I think so. The Axiom build is still
proceeding but it is well into the algebra compiles now and it
seldom fails in gcl if it gets this far... This machine is
pretty slow, so it'll probably two or three hours to complete.

Here's the patch:

ppc-osx3:~/osx $ diff -au old/gcl*/o/plttest.c new/gcl*/o/plttest.c
--- old/gcl-2.6.8pre/o/plttest.c Thu Dec 15 10:14:18 2005
+++ new/gcl-2.6.8pre/o/plttest.c Wed Nov 1 07:22:26 2006
@@ -40,7 +40,7 @@

exp(d);
log(d);
-
+ sqrt(d);
return 0;

}
ppc-osx3:~/osx $

--------

The only other problem I encountered is a problem with the
Axiom source, I think. All occurrence of

echo ')load ${OUT}/xxxx' >> ...

in the src/*/Makefile.pamphlet files had to be replaced with

echo ')load ${OUT}/xxxx.${OUTEXT}' >> ...

Without the extension the build fails looking for a file
names xxxx.8

I don't know where the .8 comes from, but I think it must
have something to do with how Axiom handles the default
extension. Although I am surprised that I have only seen
this here on this PowerPC OSX 10.2 platform and not on any
other builds... ???

I'll send a patch for Axiom after I get a change to repeat
the Axiom build with a newer version of build-improvements.

Thanks for all your help!

Regards,
Bill Page.

PS. Does anyone want me to try an gcl-based Maxima build
on this OSX machine?
Martin Rubey
2006-11-01 18:02:53 UTC
Permalink
Post by Page, Bill
Camm,
...
It seems that problem might be that 'sqrt' does not appear in
plt.h. So I added a call to sqrt(d); in plttest.c and I am
running it again.
...
Ok, with your earlier change plus adding 'sqrt(d);' to plttest.c
that did it! At least I think so. The Axiom build is still
proceeding but it is well into the algebra compiles now and it
seldom fails in gcl if it gets this far... This machine is
pretty slow, so it'll probably two or three hours to complete.
WOW, that's cool! Axiom on the Mac!





Martin
Humberto Ortiz Zuazaga
2006-11-01 18:23:04 UTC
Permalink
Post by Martin Rubey
WOW, that's cool! Axiom on the Mac!
I have PowerPC and Intel Macs running OS X 10.4.8 with fink, and I'd
like to try building axiom on them as well.

Are these changes in the build-improvements branch?
--
Humberto Ortiz-Zuazaga
Programmer-Archaeologist
UPR Bioinformatics Resource Center
http://www.hpcf.upr.edu/~humberto/
Camm Maguire
2006-11-01 23:29:55 UTC
Permalink
Greetings!
Post by Page, Bill
Camm,
...
It seems that problem might be that 'sqrt' does not appear in
plt.h. So I added a call to sqrt(d); in plttest.c and I am
running it again.
...
Ok, with your earlier change plus adding 'sqrt(d);' to plttest.c
that did it! At least I think so. The Axiom build is still
proceeding but it is well into the algebra compiles now and it
seldom fails in gcl if it gets this far... This machine is
pretty slow, so it'll probably two or three hours to complete.
ppc-osx3:~/osx $ diff -au old/gcl*/o/plttest.c new/gcl*/o/plttest.c
--- old/gcl-2.6.8pre/o/plttest.c Thu Dec 15 10:14:18 2005
+++ new/gcl-2.6.8pre/o/plttest.c Wed Nov 1 07:22:26 2006
@@ -40,7 +40,7 @@
exp(d);
log(d);
-
+ sqrt(d);
return 0;
}
ppc-osx3:~/osx $
--------
The only other problem I encountered is a problem with the
Axiom source, I think. All occurrence of
echo ')load ${OUT}/xxxx' >> ...
in the src/*/Makefile.pamphlet files had to be replaced with
echo ')load ${OUT}/xxxx.${OUTEXT}' >> ...
Without the extension the build fails looking for a file
names xxxx.8
OK, as you've gotten a successful build, there is really very little
chance of memory corruption. And I'm surmising that the larger
save-system image has to do with the native unexmacosx code we have
courtesy of Aurelien. In fact, I have never really studied this code,
so he is currently the only person in the world likely to have such
knowledge at the moment!

This .8 is still odd. Might be interesting to add )lisp
si::*load-types* somewhere to examine the defaults.
Post by Page, Bill
I don't know where the .8 comes from, but I think it must
have something to do with how Axiom handles the default
extension. Although I am surprised that I have only seen
this here on this PowerPC OSX 10.2 platform and not on any
other builds... ???
I'll send a patch for Axiom after I get a change to repeat
the Axiom build with a newer version of build-improvements.
Thanks for all your help!
Regards,
Bill Page.
PS. Does anyone want me to try an gcl-based Maxima build
on this OSX machine?
I've built macosx maxima in the past, but youre mileage may vary :-).

I am concluding that with the possible exception of fc6, gcl 2.6.8 is
ready vis a vis axiom. It would be most helpful if someone could
confirm the Fedora status for me.

Take care,
--
Camm Maguire ***@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Page, Bill
2006-11-01 19:00:10 UTC
Permalink
Post by Humberto Ortiz Zuazaga
Post by Martin Rubey
WOW, that's cool! Axiom on the Mac!
I have PowerPC and Intel Macs running OS X 10.4.8 with fink, and
I'd like to try building axiom on them as well.
Great!
Post by Humberto Ortiz Zuazaga
Are these changes in the build-improvements branch?
No, not everything is in build-improvements yet - give us a few
more hours. :-)

In the mean time I would be very interested if you could start
by just trying to buiuld the gcl lisp compiler. This is a pre-
requiste for the Axiom build. You can get the version we will be
using in build-improvements directly from the gcl CVS archive via
the command line:

$ cvs -d :pserver:***@cvs.sv.gnu.org:/sources/gcl -z9 export \
-Dtoday -d gcl-2.6.8pre -r Version_2_6_8pre gcl

and then do

$ cd gcl-2.6.8pre
$ ./configure --prefix=/usr/local
$ make

Ask if you need mor details. Let us know how it works.

Thanks.

Regards,
Bill Page.
Humberto Ortiz-Zuazaga
2006-11-02 01:18:22 UTC
Permalink
Post by Gabriel Dos Reis
Post by Humberto Ortiz Zuazaga
Post by Martin Rubey
WOW, that's cool! Axiom on the Mac!
I have PowerPC and Intel Macs running OS X 10.4.8 with fink, and
I'd like to try building axiom on them as well.
Great!
Post by Humberto Ortiz Zuazaga
Are these changes in the build-improvements branch?
No, not everything is in build-improvements yet - give us a few
more hours. :-)
In the mean time I would be very interested if you could start
by just trying to buiuld the gcl lisp compiler. This is a pre-
requiste for the Axiom build. You can get the version we will be
using in build-improvements directly from the gcl CVS archive via
-Dtoday -d gcl-2.6.8pre -r Version_2_6_8pre gcl
and then do
$ cd gcl-2.6.8pre
$ ./configure --prefix=/usr/local
$ make
Ask if you need mor details. Let us know how it works.
On PowerPC, make fails:

gcc -o raw_pre_gcl \
-L. -lpre_gcl `echo -lSM -lICE -L/usr/X11R6/lib -lXmu -lXt -lXext
-lXaw -lX11 -lm -lreadline -lncurses | sed -e 's/-lncurses/ /'`
-lintl -lc -lgclp
/usr/bin/ld: can't locate file for: -lintl
collect2: ld returned 1 exit status

Fink installed a version of libintl from gettext-dev 0.10.40, so I've
added a "-L/sw/lib" and am retrying the build now.

On Intel, configure of gmp fails, as it can't figure out the machine
type. I have gmp 4.2.1 installed with fink, but I don't think I can
build gcl with that version of gmp.
--
Humberto Ortiz-Zuazaga
Programmer-Archaeologist
University of Puerto Rico
http://www.hpcf.upr.edu/~humberto/
Page, Bill
2006-11-01 23:04:51 UTC
Permalink
Post by Martin Rubey
...
WOW, that's cool! Axiom on the Mac!
Well, the build of AXIOMsys completed successfully. You can
download a console-only version of Axiom for native MAC OSX 10
on PowerPC here:

http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061101.tgz

As usual, untar it into a convenient place like /usr/local

$ cd /usr/local
$ tar xzf ~/AXIOMsys-ppc-20061101.tgz

and then setup the AXIOM and PATH variables like this:

$ export AXIOM=/usr/local/powerpc-apple-darwin6.8
$ export PATH=$AXIOM/bin:$PATH

and start Axiom like this:

$ AXIOMsys

(1) -> integrate(1/sqrt(1-x^2),x)

exit Axiom with this command:

(99) -> )quit
yes

--------

The MAC server on which this was compiled did not have an X-windows
environment so it was not possible to compile and test Axiom Graphics
and the Hyperdoc browser. Also native MAC OSX10 apparently does not
have support for the pts virtual terminal interface so it is not
possible yet to compile clef (the replacement for readline).

Because of these problems, it is not possible to use the existing
Axiom source distribution without some changes to accommodate
the limited hardware environment. But if you are familiar with
development on a MAC and would like to give this a try, please
let you know and I can make the current preliminary sources
available.

I look forward to some comments from MAC users! :-)

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-01 23:49:05 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:


[...]

| The MAC server on which this was compiled did not have an X-windows
| environment so it was not possible to compile and test Axiom Graphics
| and the Hyperdoc browser. Also native MAC OSX10 apparently does not
| have support for the pts virtual terminal interface so it is not
| possible yet to compile clef (the replacement for readline).

I never quite understood why readline needs to be replaced. Do you know?

-- Gaby
root
2006-11-02 00:18:22 UTC
Permalink
Post by Gabriel Dos Reis
| The MAC server on which this was compiled did not have an X-windows
| environment so it was not possible to compile and test Axiom Graphics
| and the Hyperdoc browser. Also native MAC OSX10 apparently does not
| have support for the pts virtual terminal interface so it is not
| possible yet to compile clef (the replacement for readline).
I never quite understood why readline needs to be replaced. Do you know?
clef knows more than readline. given an input file it can do smart
command line completion of things like domain names.

t
Page, Bill
2006-11-02 00:05:52 UTC
Permalink
| ... Also native MAC OSX10 apparently does not
| have support for the pts virtual terminal interface so it is
| not possible yet to compile clef (the replacement for readline).
I never quite understood why readline needs to be replaced.
Do you know?
I think the foremost reason is that clef (aka. "edible") was part
of Axiom long before readline existed.

Second, clef does have some Axiom command completions that are not
built-in to readline but I think readline is also configurable,
and could provide such functionality, right?

Third, to the best of my knowledge readline is the only part of
GCL that is licenses as GPL. If readline is disabled, then GCL might
be considered compatible with Axiom's BSD-style non-copyleft license.
(I am not sure if this is important to anyone interesting in Axiom
any more.)

Personally, I would prefer to get rid of clef and adapt readline
because it would simply the Axiom process tree structure. On the
other hand, readline can be a pain sometimes when you are trying
to drive a program through a pipe and/or pty interface... so it
is desirable also to be able to disable readline also.

Regards,
Bill Page.
Gabriel Dos Reis
2006-11-02 00:18:29 UTC
Permalink
"Page, Bill" <***@drdc-rddc.gc.ca> writes:

| On Wednesday, November 01, 2006 6:49 PM Gabriel Dos Reis wrote:
|
| > | ... Also native MAC OSX10 apparently does not
| > | have support for the pts virtual terminal interface so it is
| > | not possible yet to compile clef (the replacement for readline).
| >
| > I never quite understood why readline needs to be replaced.
| > Do you know?
| >
|
| I think the foremost reason is that clef (aka. "edible") was part
| of Axiom long before readline existed.

OK; but we should not continue to have clef just for that reason.

| Second, clef does have some Axiom command completions that are not
| built-in to readline but I think readline is also configurable,
| and could provide such functionality, right?

Yes.

| Third, to the best of my knowledge readline is the only part of
| GCL that is licenses as GPL. If readline is disabled, then GCL might
| be considered compatible with Axiom's BSD-style non-copyleft license.
| (I am not sure if this is important to anyone interesting in Axiom
| any more.)

I don't know; that is probably true; I have to read GCL's configuration
options. But, building Axiom as we currently do, I have

[18:20]% strings =AXIOMsys | grep rl_
rl_line_buffer
rl_instream
rl_attempted_completion_function
rl_readline_name
rl_completion_matches
rl_completion
rl_completion_words_new
rl_ungetc_em_char
rl_putc_em_line
rl_line_buffer
rl_getc_em
rl_instream
rl_ungetc_em
rl_attempted_completion_function
rl_readline_name
rl_putc_em
rl_completion_matches
rl_getc_em(FILE *);
rl_completion_matches

| Personally, I would prefer to get rid of clef and adapt readline
| because it would simply the Axiom process tree structure. On the
| other hand, readline can be a pain sometimes when you are trying
| to drive a program through a pipe and/or pty interface... so it
| is desirable also to be able to disable readline also.

We have to investigate that case.

-- Gaby
Waldek Hebisch
2006-11-02 00:17:00 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| The MAC server on which this was compiled did not have an X-windows
| environment so it was not possible to compile and test Axiom Graphics
| and the Hyperdoc browser. Also native MAC OSX10 apparently does not
| have support for the pts virtual terminal interface so it is not
| possible yet to compile clef (the replacement for readline).
I never quite understood why readline needs to be replaced. Do you know?
The point is that Axiom can take input from multiple sources. For
example you can fire a few copies of 'spadclient' and you can
interact with each copy separately. In particular, hypertex can
send spad expresions for Axiom to evaluate. Currently, input is
sent via sockets and line buferred, so in this mode readline
included in Axiom is not used.

Strictly speaking, clef could be dropped: one could link
readline into spadclient. However, this will remove one
use of pty. The second pty is used by 'sman' to intercept
normal Axiom input and output. AFAICS this pty may be
eliminated with moderate effort.

BTW: I do not belive that MACOSX does not support pty's.
It may do it in slightly different way, but quite a lot
of unix programs (beggining with Xterm) would brake
without pty's.
--
Waldek Hebisch
***@math.uni.wroc.pl
Page, Bill
2006-11-02 00:24:19 UTC
Permalink
Post by Waldek Hebisch
...
BTW: I do not belive that MACOSX does not support pty's.
It may do it in slightly different way, but quite a lot
of unix programs (beggining with Xterm) would brake
without pty's.
I would be glad to hear more information about this.
I found several references on the web stating clearly that
the pty interface was not available on the MAC. With respect
to Xterm on MAC is did also see some references to special
purpose code in Xterm to provide some kind of emulation of
pty for the MAC. Maybe it would be possible use/adapt that
code... but that is beyond my level of experience and
available time.

It would be greate if someone could share their knowledge
and experience with this issue.

Regards,
Bill Page.
Page, Bill
2006-11-02 00:29:27 UTC
Permalink
...
Thank you for the binary! (I am on OS X 10.4.8)
$ AXIOMsys
dyld: Library not loaded: /home/users/b/bi/billpage/osx/lib/libintl.
8.dylib
Referenced from: /Users/raym/Desktop/powerpc-apple-darwin6.8/bin/
AXIOMsys
Reason: image not found
Trace/BPT trap
So some remaining path problems I fear...
Hmmm... Yes I do have a path set to point at a library that is
compiled as part of gettext:

$ echo $LIBRARY_PATH
/home/users/b/bi/billpage/osx/lib:/usr/lib:

I set this originally because I had some problems compiling
GCL with built-in gettext support. But perhaps this is not
necessary. I will try a build of GCL and Axiom without this
set.

If you do have libintl somewhere on you system, perhaps you
can try setting

export LIBRARY_PATH=/usr/lib/where-ever-it-is

I am surprised to see the AXIOMsys binary include a full
path name to this external library! Must be something pretty
weird about these .dylib files. ;)
Ready to give it a new try or, better, to compile the
gcl/axiom source code if it's available somewhere.
(tomorrow since it's late here...).
Ok, tommorrow.

Thanks for checking in to this!

Regards,
Bill Page.
Waldek Hebisch
2006-11-02 00:44:58 UTC
Permalink
Post by Page, Bill
Post by Waldek Hebisch
...
BTW: I do not belive that MACOSX does not support pty's.
It may do it in slightly different way, but quite a lot
of unix programs (beggining with Xterm) would brake
without pty's.
I would be glad to hear more information about this.
I found several references on the web stating clearly that
the pty interface was not available on the MAC. With respect
to Xterm on MAC is did also see some references to special
purpose code in Xterm to provide some kind of emulation of
pty for the MAC. Maybe it would be possible use/adapt that
code... but that is beyond my level of experience and
available time.
It would be greate if someone could share their knowledge
and experience with this issue.
I am affraid I can not really offer Mac experience. However
the first Goole hit for: MACOSX pty is:

Mac OS X pty Permission Security Issue

Now, something which does not exits should have no security
problems, so I would belive that Mac OS X has pty. OTOH
this security problem is solved by Unix 98 pty's (in other
words Linux /dev/ptmx and /dev/pts), so we can infer that
Mac OS X has only legacy pty (so you should use BSD
branch).

BTW: I you are logged into a Mac OS X machine you can try
to look is '/dev' directory contains things like '/dev/ptyq0'
and '/dev/ttyq0' (this is a traditional name for legacy
pty's).
--
Waldek Hebisch
***@math.uni.wroc.pl
C Y
2006-11-02 00:56:10 UTC
Permalink
Post by Page, Bill
Personally, I would prefer to get rid of clef and adapt readline
because it would simply the Axiom process tree structure. On the
other hand, readline can be a pain sometimes when you are trying
to drive a program through a pipe and/or pty interface... so it
is desirable also to be able to disable readline also.
Perhaps linedit would be of interest?

http://common-lisp.net/project/linedit/

I doubt it's a drop-in replacement but in theory it would be a good fit
with a lot of lisps instead of just GCL, which might be useful for
things like porting down the road. And its license should pose no
problem.

Cheers,
CY



____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups
(http://groups.yahoo.com)
Page, Bill
2006-11-02 01:21:39 UTC
Permalink
Post by Waldek Hebisch
I am affraid I can not really offer Mac experience. However
Mac OS X pty Permission Security Issue
Now, something which does not exits should have no security
problems, so I would belive that Mac OS X has pty.
Yes you are right. The reference I read earlier was that OSX 10.3
does not have support for posix grantpt... Maybe things have
change in OSX a lot since 10.3.
Post by Waldek Hebisch
OTOH this security problem is solved by Unix 98 pty's (in
other words Linux /dev/ptmx and /dev/pts), so we can infer
that Mac OS X has only legacy pty (so you should use BSD
branch).
What do you mean by "BSD branch"?
Post by Waldek Hebisch
BTW: I you are logged into a Mac OS X machine you can try
to look is '/dev' directory contains things like '/dev/ptyq0'
and '/dev/ttyq0' (this is a traditional name for legacy
pty's).
Yes, I see for example:

ppc-osx3:~/osx $ ls /dev/ptyq*
/dev/ptyq0 /dev/ptyq3 /dev/ptyq6 /dev/ptyq9 /dev/ptyqc /dev/ptyqf
/dev/ptyq1 /dev/ptyq4 /dev/ptyq7 /dev/ptyqa /dev/ptyqd
/dev/ptyq2 /dev/ptyq5 /dev/ptyq8 /dev/ptyqb /dev/ptyqe
ppc-osx3:~/osx $

But when I try to build clef I get:

ppc-osx3:~/osx/axiom.build-improvements/src/clef $ make
gcc ./edible.o
-L/home/users/b/bi/billpage/osx/axiom.build-improvements/src/clef/../../
./src/lib -L/usr/lib -lspad -lc -o
/home/users/b/bi/billpage/osx/axiom.build-improvements/target/powerpc-ap
ple-darwin6.8/bin/clef
ld: warning table of contents of library:
/home/users/b/bi/billpage/osx/axiom.build-improvements/src/clef/../.././
src/lib/libspad.a not sorted slower link editing will result (use the
ranlib(1) -s option)
ld: Undefined symbols:
_grantpt
_ptsname
_unlockpt

-----------

These are all pty external routines.

Maybe it is just that I don't understand that MAC library setup.
Loading...