Build issues with the ben-mule branch (was: Re: ben-mule-21-5: ...)
(Should I send bugs about the ben-mule tree to the xemacs-mule list or
is this list fine?)
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
If you are willing to dig into the internals to get an idea of what
is supposed to work, then you can test those features. If not, the
most productive thing to do IMO would be to run with it, try
different stuff, keep accurate records of what does and doesn't work
as you expect, and send us a summary that we can use as a checklist.
(Working features too, that can be used in regression testing.)
Okay, this sounds reasonable...
Even so, much of what you do would tend to be redundant, as the
merge process itself will result in a lot of bug fixes and
completion of features. So I can only recommend that approach if
you'd like to learn more about the implementation, and become more
active as a developer. It would be excellent preparation for that.
I wish I could spend that much time playing with the xemacs code ;)
Perahps it may happen.
Anyway, after checking out the ben-mule-21-5 branch, I'm having some
trouble building it:
./configure --with-mule --with-canna
make
...
Loading unicode.el...*** Error in XEmacs initialization
(void-function define-ccl-program)
*** Backtrace
really-early-error-handler((void-function define-ccl-program))
(define-ccl-program ccl-c-notated-string-to-number (backquote (1 ...)))
(if (fboundp (quote ccl-execute)) (define-ccl-program ccl-c-notated-string-to-number
(backquote ...)))
# bind (current-load-list)
# (unwind-protect ...)
# bind (load-file-name)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
load-internal("trans-util" nil t nil binary)
(if (or (<= ... 0) (null ...)) (and (null noerror) (signal ... ...)) (load-internal
file noerror nomessage nosuffix (let ... ...)))
(if handler (funcall handler (quote load) filename noerror nomessage nosuffix) (if (or
... ...) (and ... ...) (load-internal file noerror nomessage nosuffix ...)))
[...]
etc. etc. etc.
The backtrace is quite long...Anyone know what the problem here is?
What is define-ccl-program, and why is it missing?
Also, while looking at the compile output I noticed something:
file-coding.c: In function `detect_coding_type':
file-coding.c:3576: warning: comparison is always true due to limited range of data type
I notice these things because on powerpc (and arm) a char is
unsigned, and assumptions about negative char values seem to ALWAYS
cause trouble when building on powerpc.
Here is the code in question:
...
for (i = 0; i < coding_detector_category_count; i++)
if (st->categories[i] >= 0)
not_unlikely++;
...
And the struct:
struct detection_state
{
int seen_non_ascii;
Bytecount bytes_seen;
char categories[MAX_DETECTOR_CATEGORIES];
Bytecount data_offset[MAX_DETECTORS];
/* ... more data follows; data_offset[detector_##TYPE] points to
the data for that type */
};
okay, categories is a char type, but:
#define MAX_DETECTOR_CATEGORIES 256
In the code snippit above, when char is signed the upper half of the
values will be negative. Is this the desired effect?
Without actually diving in and trying to figure this stuff out, I
can't tell, but either this should be changed to a signed char, or an
int (more likely)...
But the more real problem (since there probably are not >127 coding
detector categories), is that on powerpc that value can't be negative.
thoughts?
diff -u -r1.9.2.17 file-coding.h
--- src/file-coding.h 2001/10/27 01:57:29 1.9.2.17
+++ src/file-coding.h 2002/02/14 20:27:06
＠＠ -665,7 +665,7 ＠＠
int seen_non_ascii;
Bytecount bytes_seen;
- char categories[MAX_DETECTOR_CATEGORIES];
+ signed char categories[MAX_DETECTOR_CATEGORIES];
Bytecount data_offset[MAX_DETECTORS];
/* ... more data follows; data_offset[detector_##TYPE] points to
the data for that type */
--
Josh Huber