XEmacs-bug: compilation (or linking) fails for changesets 5117-5147

[Ben Wing]

Hmm, you seem to be right.  It's pushed now.

On Thu, Mar 18, 2010 at 10:54 AM, robert delius royar <xemacs at frinabulax.org
> wrote:

> Ben,
>
> I applied the patch to both Mac OS X 10.4 and 10.5 (ppc) systems.  The 10.5
> worked fine.  The 10.4 required some updates to my X installation (which my
> be difficult for some users).  So far XEmacs is running fine with the patch
> and --with-union-type.
>
> Two things, I had to update alloc.c by hand.  The patch file would not work
> because the whitespace in the patches for alloc.c turned out to be 0xa0
> chars rather than 0x20 chars, so patch could not find the matching original
> lines.
>
> Also, the changeset #5148 showed up this morning (Thurs), but it was
> Sperber's patch to docs explaining the use of share rather than lib:
> changeset:   5148:9c4bf82eaac2
> user:        Mike Sperber <sperber at deinprogramm.de>
> date:        Thu Mar 18 11:53:38 2010 +0100
> summary:     Reflect change from `lib' to `share' in docs.
>
> Perhaps your changes are still in a separate workspace.
>
>
> Wed, 17 Mar 2010 (14:49 -0500 UTC) Ben Wing wrote:
>
>  Strange ...   there should be a changeset  #5148:641d0cdd1d00 as of Mar
>> 16:
>>
>> diff --git a/src/ChangeLog b/src/ChangeLog
>> --- a/src/ChangeLog
>> +++ b/src/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2010-03-16  Ben Wing  <ben at xemacs.org>
>> +
>> +       * alloc.c (make_lcrecord_list):
>> +       * alloc.c (alloc_managed_lcrecord):
>> +       Fix compilation problems identified by Robert Delius Royar.
>> +
>>  2010-03-15  Ben Wing  <ben at xemacs.org>
>>
>>         * extents.c (Fprevious_single_property_change):
>> diff --git a/src/alloc.c b/src/alloc.c
>> --- a/src/alloc.c
>> +++ b/src/alloc.c
>> @@ -3200,8 +3200,8 @@
>>  {
>>    /* Don't use alloc_automanaged_lcrecord() avoid infinite recursion
>>       allocating this. */
>> -  struct lcrecord_list *p = (struct lcrecord_list *)
>> -    old_alloc_lcrecord (&lrecord_lcrecord_list);
>> +  struct lcrecord_list *p =
>> +    XLCRECORD_LIST (old_alloc_lcrecord (&lrecord_lcrecord_list));
>>
>>    p->implementation = implementation;
>>    p->size = size;
>> @@ -3247,8 +3247,7 @@
>>        return val;
>>      }
>>    else
>> -    return wrap_pointer_1 (old_alloc_sized_lcrecord (list->size,
>> -
>> list->implementation));
>> +    return old_alloc_sized_lcrecord (list->size, list->implementation);
>>  }
>>
>>  /* "Free" a Lisp object LCRECORD by placing it on its associated free
>> list
>>
>>
>> On Wed, Mar 17, 2010 at 11:19 AM, robert delius royar <
>> xemacs at frinabulax.org> wrote:
>> Tue, 16 Mar 2010 (23:09 -0500 UTC) Ben Wing wrote:
>>
>>
>>
>>      On Tue, Mar 16, 2010 at 12:55 PM, robert delius royar <
>> xemacs at frinabulax.org> wrote:
>>           I updated XEmacs 21.5-b29 sources today to the latest changeset
>>           (5147:b0ab9aa48977).  Compilation failed with src/alloc.c
>> complaining of
>>           alloc.c: In function `make_lcrecord_list':
>>           alloc.c:3204: error: cannot convert to a pointer type
>>           alloc.c: In function `alloc_managed_lcrecord':
>>           alloc.c:3251: error: incompatible type for argument 1 of
>> `wrap_pointer_1'
>>
>>           I tried a number of other changesets until I found that 5116 is
>> the last
>>           one that works:
>>           changeset:   5116:e56f73345619
>>           parent:      3084:aaf96f4ba612
>>           user:        Ben Wing <ben at xemacs.org>
>>           date:        Sat Dec 26 00:20:16 2009 -0600
>>           summary:     Added tag ben-lisp-object-bp for changeset
>> aaf96f4ba612
>>
>>           In different compilations, different errors show up (most with
>> alloc.c).
>>           In one compilation, the compile continues but the link fails
>> complaining
>>           that some of the functions referenced in alloc.c are undefined.
>>
>>           Based on the errors, I suspect that it is possible that gcc4.2
>> does not
>>           accept the cast (struct lcrecord_list *) as a pointer to a
>> union.
>>           Compiling without-union-type works for 5147, but my experience
>> on PPC OS
>>           X has been that treating an int as a complex LispObject makes a
>> less
>>           stable executable.  I rarely see crashes with the union type,
>> but I used
>>           to see them regularly with the object defined as an int.
>>
>>           The bug tracker is currently out of commission, or I would have
>>           submitted this through it instead of posting to the mailing
>> list.
>>
>>
>>      OK, try it now.
>>
>>      ben
>>
>>
>> As of 12:00 p.m. US EDT Wed 17 March, the server is still down.  The
>> latest update in the source tree is from Mon 15 March, and
>> the source still does not compile --with-union-type (same error).
>>
>>
>> --
>> Dr. Robert Delius Royar                   Associate Professor of English
>> Morehead State University                             Morehead, Kentucky
>>
>>
>>
>>
>>
>
>
> --
> Dr. Robert Delius Royar                   Associate Professor of English
> Morehead State University                             Morehead, Kentucky
>  Without trolling, the Internet wouldn't be where it is today.
>                                                    -John Yeung