[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Fwd: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxi
|
From: |
Camm Maguire |
|
Subject: |
Re: [Gcl-devel] Fwd: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5.9.[12] and so on. |
|
Date: |
04 Nov 2005 19:33:57 -0500 |
|
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Well, this is about one of the most magnificent GCL messages I've read
in recent memory! Thank you so much! This is exactly the kind of
thoroughness and diligence these sort of problems demand, IMHO, and
the patience and time to follow through adequately, as you have done,
can be quite rare at times.
I will work on getting your material into 2.6.8pre (cvs tag
Version_2_6_8pre) asap. There is likely some additional work here to
do in this regard, as I've upgraded the binutils version, but not yet
tested our custom Macosx stuff. And thank you for indicating that GCL
has users on the Mac -- this helps us focus our priorities.
Would you consider volunteering to be a GCL developer?
Take care,
足立 聡 <address@hidden> writes:
> Dear Developers of GNU Common lisp,
>
> About a week ago, I sent the following email to address@hidden
> Recently, I noticed that only members of this mailing list are allowed
> to post an email to the list. So, I registered myself in the mailing
> list
> and now post my previous email again. Anyway, I am a user
> of GCL and Maxima and look forward to reading emails from
> address@hidden
>
> Sincerely yours,
> Satoshi Adachi
>
> Begin forwarded message:
>
> > From: 足立 聡 <address@hidden>
> > Date: 2005年10月18日 16:25:45:JST
> > To: address@hidden
> > Cc: 足立 聡 <address@hidden>
> > Subject: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build
> > maxima-5.9. [12] and so on.
> >
> >
> > Dear Developers of GNU Common Lisp (GCL):
> >
> >
> > ================================================================
> > This reports a bug and its fix for gcl-2.6.7 to build
> > maxima-5.9.[12] on MacOS X (10.4.2). The patch for gcl-2.6.7
> > is placed at an almost end part of this email between two
> > "===...===" lines. Other part in this email is written to
> > transfer some information about the relocation in MacOS X
> > to the maintainer of GCL, who may not be a user of MacOS X.
> >
> > ================================================================
> >
> > I have been using GCL as the base languange on which Maxima is
> > implemented.
> > My present personal environment for computation is MacOS X (10.4.2)
> > running on iBook (G4).
> >
> > Recently, I used gcl-2.6.7 to build maxima-5.9.1 and found that
> > maxima-5.9.1 can not be complied as
> >
> > ----------------------------------------------------------------------
> > ---------
> > ...
> > ...
> > ; - Compiling source file
> > ; "/Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/
> > clmacs.lisp"
> > Compiling /Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/
> > clmacs.lisp.
> > End of Pass 1.
> >
> > ;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
> > ;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
> > End of Pass 2.
> > OPTIMIZE levels: Safety=2, Space=2, Speed=3
> > Finished compiling binary-gcl/clmacs.o.
> >
> > ; - Loading binary file "binary-gcl/clmacs.o"
> > Loading binary-gcl/clmacs.o
> > error: unknown relocation entry
> > Error in FUNCALL [or a callee]: Cannot get relocated section contents
> > ----------------------------------------------------------------------
> > ---------
> >
> > This problem is originated from the source file of GCL
> >
> > gcl-2.6.7/binutils/bfd/mach-o-reloc.c
> >
> > at the line 1018. The source code around this line is the following:
> >
> > ----------------------------------------------------------------------
> > ---------
> > ...
> > switch (r_type)
> > {
> > case PPC_RELOC_HI16:
> > case PPC_RELOC_HI16_SECTDIFF:
> > value = ((instruction & 0xffff) << 16) | other_half;
> > break;
> >
> > case PPC_RELOC_LO16:
> > case PPC_RELOC_LO16_SECTDIFF:
> > value = (other_half << 16) | (instruction & 0xffff);
> > break;
> >
> > case PPC_RELOC_HA16:
> > case PPC_RELOC_HA16_SECTDIFF:
> > if (other_half & 0x8000) {
> > value = ((instruction & 0xffff) << 16) +
> > (0xffff0000 | other_ha(J\(B
> > lf);
> > } else {
> > value = ((instruction & 0xffff) << 16) + other_half;
> > }
> > break;
> >
> > case PPC_RELOC_LO14:
> > case PPC_RELOC_LO14_SECTDIFF:
> > value = (other_half << 16) | (instruction & 0xfffc);
> > break;
> >
> > case PPC_RELOC_BR24:
> > value = instruction & 0x03fffffc;
> > if (value & 0x02000000) value |= 0xfc000000;
> > break;
> >
> > case PPC_RELOC_BR14:
> > value = instruction & 0xfffc;
> > if (value & 0x8000) value |= 0xffff0000;
> > break;
> >
> > case PPC_RELOC_JBSR:
> > value = other_half;
> > break;
> >
> > default:
> > fprintf (stderr, "error: unknown relocation entry
> > (J\(Bn"); /* HERE */
> > return false;
> > }
> > }
> > ...
> > ----------------------------------------------------------------------
> > ---------
> >
> > I changed the above line marked by "/* HERE */" as
> >
> > ----------------------------------------------------------------------
> > ---------
> > fprintf (stderr, "error: unknown relocation entry, r_type = 0x%
> > x(J\(Bn", r_type);
> > ----------------------------------------------------------------------
> > ---------
> >
> > in order to inspect what is the value of the varible "r_type" that
> > caused
> > the error.
> >
> > Then, I recomplied gcl-2.6.7 with this modification and tried to build
> > maxima-5.9.1 again. The error message became as follows:
> >
> > ----------------------------------------------------------------------
> > ---------
> > ...
> > ...
> > ; - Loading binary file "binary-gcl/kclmac.o"
> > Loading binary-gcl/kclmac.o
> > start address -T 0x157ec00 Finished loading binary-gcl/kclmac.o
> >
> > ; - Compiling source file
> > ; "/Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/
> > clmacs.lisp"
> > Compiling /Volumes/HFS+1/usr/local/src/GNU/maxima-5.9.1/src/
> > clmacs.lisp.
> > End of Pass 1.
> >
> > ;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
> > ;; Note: Tail-recursive call of ALPHALESSP was replaced by iteration.
> > End of Pass 2.
> > OPTIMIZE levels: Safety=2, Space=2, Speed=3
> > Finished compiling binary-gcl/clmacs.o.
> >
> > ; - Loading binary file "binary-gcl/clmacs.o"
> > Loading binary-gcl/clmacs.o
> > error: unknown relocation entry, r_type = 0xf
> > ----------------------------------------------------------------------
> > ---------
> >
> > Namely, the variable "r_type" takes the value "0xf".
> >
> > Next, I read the documentation about the general relocation mechanism
> > on MacOS X, which is bundled with MacOS X, and inspected the header
> > files
> > under /usr/include/ that are related with relocation.
> >
> > In the header file /usr/include/mach-o/ppc/reloc.h,
> > the enumeration type "reloc_type_ppc", which classifies the type of
> > each relocation on MacOS X, is defined as
> >
> > ----------------------------------------------------------------------
> > ---------
> > ...
> > enum reloc_type_ppc
> > {
> > PPC_RELOC_VANILLA, /* generic relocation as discribed above */
> > PPC_RELOC_PAIR, /* the second relocation entry of a pair */
> > PPC_RELOC_BR14, /* 14 bit branch displacement (to a word
> > address) */
> > PPC_RELOC_BR24, /* 24 bit branch displacement (to a word
> > address) */
> > PPC_RELOC_HI16, /* a PAIR follows with the low half */
> > PPC_RELOC_LO16, /* a PAIR follows with the high half */
> > PPC_RELOC_HA16, /* Same as the RELOC_HI16 except the low 16
> > bits and the
> > * high 16 bits are added together with the
> > low 16 bits
> > * sign extened first. This means if bit
> > 15 of the low
> > * 16 bits is set the high 16 bits stored
> > in the
> > * instruction will be adjusted.
> > */
> > PPC_RELOC_LO14, /* Same as the LO16 except that the low 2
> > bits are not
> > * stored in the instruction and are always
> > zero. This
> > * is used in double word load/store
> > instructions.
> > */
> > PPC_RELOC_SECTDIFF, /* a PAIR follows with subtract symbol
> > value */
> > PPC_RELOC_PB_LA_PTR,/* prebound lazy pointer */
> > PPC_RELOC_HI16_SECTDIFF, /* section difference forms of above.
> > a PAIR */
> > PPC_RELOC_LO16_SECTDIFF, /* follows these with subtract symbol
> > value */
> > PPC_RELOC_HA16_SECTDIFF,
> > PPC_RELOC_JBSR,
> > PPC_RELOC_LO14_SECTDIFF,
> > PPC_RELOC_LOCAL_SECTDIFF /* like PPC_RELOC_SECTDIFF, but the
> > symbol
> > referenced was local. */
> > };
> > ----------------------------------------------------------------------
> > ---------
> >
> > The final item PPC_RELOC_LOCAL_SECTDIFF in the above list
> > for the enumeration type "reloc_type_ppc"
> > has the number 15 (0xf in hexadecimal), which is counted from 0 as
> > usual.
> > I found that this relocation type PPC_RELOC_LOCAL_SECTDIFF
> > caused the reported error in gcl-2.6.7 to build maxima-5.9.1.
> >
> > This item PPC_RELOC_LOCAL_SECTDIFF in the enumeration type
> > "reloc_type_ppc"
> > seems to have been added quite recently by Apple.
> >
> > I cannot find some written documentation for PPC_RELOC_LOCAL_SECTDIFF.
> > Accordingly, I inspected the source code of Darwin corresponding to
> > MacOS X (10.4.2), which is offered by Apple.
> >
> > I had downloaded and expaned all the source files for Darwin.
> > In the directory under which all the source files for Darwin are
> > stored,
> > I typed the following command:
> >
> > find . -type f -exec grep -H -n PPC_RELOC_LOCAL_SECTDIFF
> > '{}' .
> >
> > This command told me that PPC_RELOC_LOCAL_SECTDIFF appears only
> > in the following source files:
> >
> > cctools-576.3/as/notes
> > cctools-576.3/as/write_object.c
> > cctools-576.3/include/mach-o/ppc/reloc.h
> > cctools-576.3/include/notes
> > cctools-576.3/ld/notes
> > cctools-576.3/ld/ppc_reloc.c
> > cctools-576.3/libstuff/notes
> > cctools-576.3/libstuff/reloc.c
> > cctools-576.3/otool/notes
> > cctools-576.3/otool/ofile_print.c
> > cctools-576.3/otool/ppc_disasm.c
> > ld64-21/src/Readers/ObjectFileMachO.cpp
> > ld64-21/src/Writers/ExecutableFileMachO.cpp
> >
> > Among these files, I read cctools-576.3/ld/ppc_reloc.c in order to
> > known how the loader treats the relocation type
> > PPC_RELOC_LOCAL_SECTDIFF.
> >
> > It is found in the soruce file cctools-576.3/ld/ppc_reloc.c that
> > the relocation type PPC_RELOC_LOCAL_SECTDIFF is treated completely
> > in the same way as the other relocation type PPC_RELOC_SECTDIFF is
> > treated
> > except for the treatment in one code fragment.
> >
> > Except for the one code fragment, PPC_RELOC_LOCAL_SECTDIFF and
> > PPC_RELOC_SECTDIFF always appear in paralell in disjunctional
> > conditions.
> > For example, their first appearance looks as
> >
> > ...
> > else if(r_type == PPC_RELOC_SECTDIFF || /* HERE */
> > r_type == PPC_RELOC_LOCAL_SECTDIFF || /* HERE */
> > r_type == PPC_RELOC_HI16_SECTDIFF ||
> > r_type == PPC_RELOC_LO16_SECTDIFF ||
> > r_type == PPC_RELOC_LO14_SECTDIFF ||
> > r_type == PPC_RELOC_HA16_SECTDIFF){
> > ...
> >
> > The only one code fragment in cctools-576.3/ld/ppc_reloc.c
> > in which PPC_RELOC_LOCAL_SECTDIFF is treated differently from
> > PPC_RELOC_SECTDIFF is the following:
> >
> > ...
> > /*
> > * Now build up the value of the relocated
> > * expression one part at a time. First set the
> > * new value to the relocated r_value.
> > */
> > if(local_map->nfine_relocs != 0){
> > /*
> > * Check to see if this reference is legal with
> > * respect to indirect sections.
> > */
> > legal_reference(section_map, r_address,
> > local_map, r_value - local_map->s-
> > >addr +
> > offset, i,
> > r_type !=
> > PPC_RELOC_LOCAL_SECTDIFF); /* HERE */
> > value = fine_reloc_output_address(local_map,
> > r_value - local_map->s->addr,
> > local_map->output_section->s.addr);
> > }
> > else{
> > ...
> >
> > The function
> >
> > legal_reference(struct section_map *from_map,
> > unsigned long from_offset,
> > struct section_map *to_map,
> > unsigned long to_offset,
> > unsigned long from_reloc_index,
> > enum bool sectdiff_reloc)
> >
> > that is called in the above code fragment in such a way that the last
> > argument "sectdiff_reloc" is set to "r_type !=
> > PPC_RELOC_LOCAL_SECTDIFF"
> > is defined in another source file cctools-576.3/ld/
> > indirect_sections.c.
> >
> > It is found by reading cctools-576.3/ld/indirect_sections.c that
> > the boolean flag "sectdiff_reloc" is used in the function
> > legal_reference()
> > only for turning on several extra conditional tests that are
> > applied to
> > a given relocation entry. If the given relocation entry does not pass
> > one of these extra tests, an error message is printed and this is
> > informed to
> > its caller by the returned value.
> > This means that if the given relocation entry is
> > a correct one, whether the boolean flag "sectdiff_reloc" is true or
> > false
> > does not affect the result that is returned by the function
> > legal_reference().
> >
> > This observation suggests that
> > the new relocation type PPC_RELOC_LOCAL_SECTDIFF can be treated
> > in our source code for any program completely in the same way as
> > PPC_RELOC_SECTDIFF is treated
> > under the assumption that only correct relocation entries appear
> > in our program.
> >
> > This consideration allows me to rewrite the source file
> >
> > gcl-2.6.7/binutils/bfd/mach-o-reloc.c
> >
> > as follows:
> >
> > ======================================================================
> > =========
> > --- mach-o-reloc.c.org 2004-03-12 17:16:03.000000000 +0900
> > +++ mach-o-reloc.c 2005-10-15 06:40:18.000000000 +0900
> > @@ -18,11 +18,14 @@
> > PPC_RELOC_HA16_SECTDIFF = 12, /* expects a pair */
> > PPC_RELOC_JBSR = 13, /* expects a pair */
> > PPC_RELOC_LO14_SECTDIFF = 14, /* expects a pair */
> > + PPC_RELOC_LOCAL_SECTDIFF = 15, /* expects a pair */
> > PPC_RELOC_NONE = 255
> > };
> > +#define PPC_RELOC_SENTINEL (PPC_RELOC_LOCAL_SECTDIFF+1)
> > +
> > /* Entries not suffixed by "PCREL" are expected to be absolute.
> > Note, however,
> > that the canonicalization routine does not require this. This
> > means that adding
> > a new pc-rel entry is as simple as adding the corresponding
> > entries below, as
> > @@ -49,11 +52,14 @@
> > BFD_MACH_O_PPC_RELOC_HI16_SECTDIFF = 14,
> > BFD_MACH_O_PPC_RELOC_LO16_SECTDIFF = 15,
> > BFD_MACH_O_PPC_RELOC_HA16_SECTDIFF = 16,
> > - BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF = 17,
> > - BFD_MACH_O_PPC_RELOC_JBSR = 18
> > + BFD_MACH_O_PPC_RELOC_JBSR = 17,
> > + BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF = 18,
> > + BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF = 19,
> > };
> > +#define BFD_MACH_O_PPC_RELOC_SENTINEL
> > (BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF+1)
> > +
> > #define BFD_MACH_O_R_ABS 0
> > #define BFD_MACH_O_R_SCATTERED 0x80000000
> > @@ -457,8 +463,28 @@
> > false /* pcrel_offset */
> > ),
> > + /* The jbsr instruction is assembled to the branch island. For
> > + now, don't bother testing if the target can be reached
> > directly. */
> > +
> > /* 17 */
> > HOWTO(
> > + BFD_MACH_O_PPC_RELOC_JBSR, /* type */
> > + 0, /* right_shift */
> > + 2, /* size */
> > + 26, /* bitsize */
> > + false, /* pc_relative */
> > + 0, /* bitpos */
> > + complain_overflow_dont, /*
> > complain_overflow */
> > + NULL, /*
> > special_function */
> > + "BFD_MACH_O_PPC_RELOC_JBSR", /* name */
> > + false, /* partial_inplace */
> > + 0, /* src_mask */
> > + 0, /* dst_mask */
> > + false /* pcrel_offset */
> > + ),
> > +
> > + /* 18 */
> > + HOWTO(
> > BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF, /* type */
> > 0, /* right_shift */
> > 2, /* size */
> > @@ -474,25 +500,22 @@
> > false /* pcrel_offset */
> > ),
> > - /* The jbsr instruction is assembled to the branch island. For
> > - now, don't bother testing if the target can be reached
> > directly. */
> > -
> > - /* 18 */
> > + /* 19 */
> > HOWTO(
> > - BFD_MACH_O_PPC_RELOC_JBSR, /* type */
> > + BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF, /* type */
> > 0, /* right_shift */
> > 2, /* size */
> > - 26, /* bitsize */
> > + 32, /* bitsize */
> > false, /* pc_relative */
> > 0, /* bitpos */
> > complain_overflow_dont, /*
> > complain_overflow */
> > - NULL, /*
> > special_function */
> > - "BFD_MACH_O_PPC_RELOC_JBSR", /* name */
> > + bfd_mach_o_sectdiff_reloc, /*
> > special_function */
> > + "BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF", /* name */
> > false, /* partial_inplace */
> > 0, /* src_mask */
> > - 0, /* dst_mask */
> > + 0xffffffff, /* dst_mask */
> > false /* pcrel_offset */
> > - )
> > + ),
> > };
> > @@ -513,6 +536,7 @@
> > & reloc_howto_table [BFD_MACH_O_PPC_RELOC_HA16_SECTDIFF],
> > & reloc_howto_table [BFD_MACH_O_PPC_RELOC_JBSR],
> > & reloc_howto_table [BFD_MACH_O_PPC_RELOC_LO14_SECTDIFF],
> > + & reloc_howto_table [BFD_MACH_O_PPC_RELOC_LOCAL_SECTDIFF],
> > NULL,
> > NULL,
> > @@ -528,7 +552,8 @@
> > NULL,
> > NULL,
> > NULL,
> > - NULL
> > + NULL,
> > + NULL,
> > };
> > @@ -601,7 +626,7 @@
> > bfd *abfd ATTRIBUTE_UNUSED;
> > bfd_reloc_code_real_type code;
> > {
> > - if (code <= BFD_MACH_O_PPC_RELOC_JBSR) {
> > + if (code < BFD_MACH_O_PPC_RELOC_SENTINEL) {
> > return reloc_howto_table + code;
> > } else {
> > return NULL;
> > @@ -909,7 +934,8 @@
> > r_type == PPC_RELOC_HI16_SECTDIFF ||
> > r_type == PPC_RELOC_LO16_SECTDIFF ||
> > r_type == PPC_RELOC_HA16_SECTDIFF ||
> > - r_type == PPC_RELOC_LO14_SECTDIFF)
> > + r_type == PPC_RELOC_LO14_SECTDIFF ||
> > + r_type == PPC_RELOC_LOCAL_SECTDIFF)
> > {
> > struct scattered_relocation_info *srip = NULL;
> > enum bfd_mach_o_rtype pair_r_type = PPC_RELOC_NONE;
> > @@ -948,7 +974,9 @@
> > octets = relent->address * bfd_octets_per_byte (abfd);
> >
> > - if (r_type == PPC_RELOC_VANILLA || r_type ==
> > PPC_RELOC_SECTDIFF)
> > + if (r_type == PPC_RELOC_VANILLA ||
> > + r_type == PPC_RELOC_SECTDIFF ||
> > + r_type == PPC_RELOC_LOCAL_SECTDIFF)
> > {
> > switch (r_length)
> > {
> > @@ -1015,7 +1043,7 @@
> > break;
> >
> > default:
> > - fprintf (stderr, "error: unknown relocation
> > entry(J\(Bn");
> > + fprintf (stderr, "error: unknown relocation entry,
> > r_type = 0x%x(J\(Bn", r_type);
> > return false;
> > }
> > }
> > @@ -1070,7 +1098,8 @@
> > r_type == PPC_RELOC_HI16_SECTDIFF ||
> > r_type == PPC_RELOC_LO16_SECTDIFF ||
> > r_type == PPC_RELOC_HA16_SECTDIFF ||
> > - r_type == PPC_RELOC_LO14_SECTDIFF)
> > + r_type == PPC_RELOC_LO14_SECTDIFF ||
> > + r_type == PPC_RELOC_LOCAL_SECTDIFF)
> > {
> > bfd_mach_o_sectdiff *sectdiff = (bfd_mach_o_sectdiff *)
> > bfd_alloc (abfd, sizeof (bfd_mach_o_sectdiff));
> > @@ -1099,10 +1128,10 @@
> > relent->howto = NULL;
> >
> > - if ((r_type + (PPC_RELOC_LO14_SECTDIFF+1) * r_pcrel) <
> > sizeof (to_howto))
> > + if ((r_type + PPC_RELOC_SENTINEL * r_pcrel) < sizeof
> > (to_howto))
> > {
> > relent->howto =
> > - to_howto [r_type + (PPC_RELOC_LO14_SECTDIFF+1) *
> > r_pcrel];
> > + to_howto [r_type + PPC_RELOC_SENTINEL * r_pcrel];
> >
> > if (relent->howto ==
> > & reloc_howto_table [BFD_MACH_O_PPC_RELOC_VANILLA_2])
> > ======================================================================
> > =========
> >
> > The GCL that is complied with this fix succeeds in building
> > maxima-5.9.1.
> > Recently, Maxima was upgraded to maxima-5.9.2. I also confirmed that
> > the GCL with this fix succeeds in building maxima-5.9.2.
> >
> > I have been using the maxima-5.9.2 that was build in this way
> > for about one week. I found no problem in the maxima that is related
> > with this fix for gcl-2.6.7.
> >
> > I think that the maintainer of GCL may have already received
> > some bug report and its fix similar to this email, since I am sure
> > that there are a lot of users of GCL & Maxima on MacOS X.
> > In that case, this email may not bring any new information
> > to the maintainer of GCL. On the contrary, if the maintainer has not
> > yet received some email similar to this email, then please utilize
> > the information that this email contains to fix this bug in gcl-2.6.7
> > to build Maxima. If GCL cannot build Maxima on MacOSX, many people
> > in the world including me are very unhappy. So, please fix this
> > problem
> > in any way.
> >
> > Finally, sepeaking about the future development of
> > Binary File Dscriptor (BFD) library in the main branch,
> > someone needs to write a code for MacOS X to implement the extra tests
> > for the new relocation type PPC_RELOC_LOCAL_SECTDIFF
> > in order to keep the semantics of BFD including error checks
> > be compatible with the original semantics that is defined by Apple.
> >
> > Sincerely yours,
> >
> > Satoshi Adachi
> > address@hidden
> >
> > Department of Condensed
> > Matter Physics
> > Tokyo Insitute of Technology
> >
> > Tokyo, Megro Oookayama 2-12-1
> > JAPAN
> >
> > P.S Several years ago, I ported gcl-2.4.0 to MacOSX for my use.
> > However, I could not find enough time then to clean up the soruce code
> > to send a feedback. Now, my port became obsolate and I have no
> > ncessecity
> > to clean up my code. I am very happy to use gcl-2.6.7 on MacOSX,
> > which was ported by someone.
> > In my port, I used dlopen() and related functions for dynamical
> > loading
> > of object files and modified unexec() that is taken from GNU Emacs
> > to dump the memory image of GCL.
> > Just for historical interest, I put my dirty source code of
> > gcl-2.4.0 and gcl-2.5.3 for MacOSX in our anonymous ftp as
> >
> > ftp://ftp.aa.ap.titech.ac.jp/pub/adachi/
> > dirty_source_code_of_GCL_for_MacOSX/
> > {gcl-2.4.0-MacOSX-dirty-socurce-code-by-S.Adachi.gnutar.gz,
> > gcl-2.5.3-MacOSX-dirty-source-code-by-S.Adachi.gnutar.gz}
> >
> > I did not clean up anything. I am very sorry...
> > These tarfiles contain many LOG files and gabages.
> > These files are just for historical interest.
> >
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah