4:13 a.m.
--- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
APPROVE COMMIT 21.5
Per recommendation of Ben. This is not meant to block Marcus's
"xemacs.def.in in modules" patch, but it does work for Mac OS X.
This seems to have snuck in with the Xft merge commit. Sorry!
2005-11-07 Stephen J. Turnbull <stephen(a)xemacs.org>
* inline.c: Include modules headers regardless of HAVE_SHLIB.
Reproducing the patch (which was originally sent to xemacs-beta for
discussion).
In the lrecord code, if error checking is turned on, each Lisp object
type automatically gets a error_check_TYPE_name function defined using
DECLARE_INLINE_HEADER. For reasons I don't understand well at all, at
least on Mac OS X 10.3.9 with GCC 3.3 these functions don't get
instantiated for the PostgreSQL and LDAP modules.
The patch below wins for me, but it's not very pleasant as it seems to
imply it's not possible to get an error-checking build outside of the
XEmacs tree.
Comments appreciated.
diff -rN -u old-xft-integration-new/src/inline.c
new-xft-integration-new/src/inline.c
--- old-xft-integration-new/src/inline.c 2005-11-05
00:45:16.000000000 +0900
+++ new-xft-integration-new/src/inline.c 2005-11-05 00:45:24.000000000 +0900
＠＠ -67,11 +67,13 ＠＠
#include "syntax.h"
#include "window.h"
-#if defined (HAVE_LDAP) && !defined (HAVE_SHLIB)
+/* if we demand !define (HAVE_SHLIB) the inlines don't get instantiated */
+#if defined (HAVE_LDAP)
#include "../modules/ldap/eldap.h"
#endif
-#if defined (HAVE_POSTGRESQL) && !defined (HAVE_SHLIB)
+/* if we demand !define (HAVE_SHLIB) the inlines don't get instantiated */
+#if defined (HAVE_POSTGRESQL)
#include "../modules/postgresql/postgresql.h"
#endif
When I turn on error checking and build on Cygwin with this patch applied, I
(still) get lots of unresolved externals in the modules, mostly functions named
error_check_*. I've added those symbols xemacs.def.in.in and generated a new
patch. With the modified xemacs.def.in.in, I'm able to build on Cygwin with
both error checking enabled and disabled.
I have no idea whether or not this is the right thing to do, but it works for
Cygwin.
--Rick
Index: src/xemacs.def.in.in
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/xemacs.def.in.in,v
retrieving revision 1.11
diff -u -r1.11 xemacs.def.in.in
--- src/xemacs.def.in.in 2005/11/28 16:39:54 1.11
+++ src/xemacs.def.in.in 2005/11/29 04:06:01
＠＠ -82,6 +82,12 ＠＠
eputenv
#ifdef DEBUG_XEMACS
eq_with_ebola_notice /* EQ_WITH_EBOLA_NOTICE */
+error_check_cons
+error_check_ldap
+error_check_opaque_ptr
+error_check_pgconn
+error_check_pgresult
+error_check_string
#endif
free_opaque_ptr
get_coding_system_for_text_file
＠＠ -144,6 +150,9 ＠＠
vector2
vector3
warn_when_safe
+#ifdef DEBUG_XEMACS
+wrap_record_1
+#endif
write_c_string
write_fmt_string
write_fmt_string_lisp
＠＠ -187,6 +196,9 ＠＠
Fsignal
Fthrow
Fvector
+#ifdef DEBUG_XEMACS
+XINT_1
+#endif
/* Exported variables */
__temp_alloca_size__ /* ALLOCA */
5:38 a.m.
New subject: [AC21.5] Implicit INLINE_HEADERS in modules don't get instantiated
First, let me say "thanks!" before blowing off some steam. :-)
>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> When I turn on error checking and build on Cygwin with this
Rick> patch applied, I (still) get lots of unresolved externals in
Rick> the modules, mostly functions named error_check_*. I've
Rick> added those symbols xemacs.def.in.in and generated a new
Rick> patch. With the modified xemacs.def.in.in, I'm able to build
Rick> on Cygwin with both error checking enabled and disabled.
Aaaaaarrgh!!!! I was ready to release 21.5.24 (tarballs are already
built), but I guess I'll wait for Ben to weigh in on this.
Rick> I have no idea whether or not this is the right thing to do,
Rick> but it works for Cygwin.
AFAICT xemacs.def is Cygwin-specific, so I guess it's the right thing
to do.
Why do we need a separate file like this? I thought this was
precisely the kind of thing that inlines.c was intended to handle.
Would it be possible to deal with this in the same way (ie, #include
all the headers into xemacs.def with some preprcessor magic to extract
the needed symbols)?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:08 a.m.
New subject: [AC21.5] Implicit INLINE_HEADERS in modules don't get instantiated
Stephen J. Turnbull wrote:
Aaaaaarrgh!!!! I was ready to release 21.5.24 (tarballs are already
built), but I guess I'll wait for Ben to weigh in on this.
Rick> I have no idea whether or not this is the right thing to do,
Rick> but it works for Cygwin.
AFAICT xemacs.def is Cygwin-specific, so I guess it's the right thing
to do.
Why do we need a separate file like this? I thought this was
precisely the kind of thing that inlines.c was intended to handle.
Would it be possible to deal with this in the same way (ie, #include
all the headers into xemacs.def with some preprcessor magic to extract
the needed symbols)?
i don't completely understand what's going on here; but i think your
suggestion of auto-generating as much of this file as possible is
exactly the right thing. however, it's gonna take some work to get this
right; so i'd suggest for the moment that you apply rick's patch.
ben
7:52 a.m.
New subject: [AC21.5] Implicit INLINE_HEADERS in modules don't get instantiated
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> i don't completely understand what's going on here; but i
Ben> think your suggestion of auto-generating as much of this file
Ben> as possible is exactly the right thing. however, it's gonna
Ben> take some work to get this right; so i'd suggest for the
Ben> moment that you apply rick's patch.
Thanks, will do!
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:32 p.m.
New subject: [PATCH] repair xemacs.def.in.in (was: Implicit INLINE_HEADERS in modules don't get instantiated)
>>>>"RR" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
RR> I have no idea whether or not
this is the right thing to do, but
RR> it works for Cygwin.
I see some problems with Rick's patch:
RR> #ifdef DEBUG_XEMACS
RR> eq_with_ebola_notice /* EQ_WITH_EBOLA_NOTICE */
RR> +error_check_cons
The error_check_* symbols have to be conditioned on ERROR_CHECK_TYPES,
not on DEBUG_XEMACS.
RR> +error_check_ldap
This has to be conditioned on HAVE_LDAP. Only with HAVE_LDAP the
lrecord type `ldap' gets instantiated in inline.c.
RR> +error_check_pgconn
RR> +error_check_pgresult
This has to be conditioned on HAVA_POSTGRESQL, for the same reason as
above.
RR> +error_check_string
The new GC string implementation requires that two more symbols are
added: error_check_direct_string_data and
error_check_indirect_string_data.
RR> +#ifdef DEBUG_XEMACS
RR> +wrap_record_1
RR> +#endif
[...]
RR> +#ifdef DEBUG_XEMACS
RR> +XINT_1
RR> +#endif
Both symbols have to be conditioned on ERROR_CHECK_TYPES.
The patch below repairs it, my other patch
<87zmnpwst0.fsf(a)informatik.uni-tuebingen.de> is no longer needed.
>>>>"SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Aaaaaarrgh!!!! I was ready to release
21.5.24 (tarballs are
SJT> already built)
Stephen, it seems that not many people are using Cygwin anyway, so I
think this patch can wait until the release is out. No need to redo
the whole work for the third time!
src/ChangeLog addition:
2005-11-29 Marcus Crestani <crestani(a)xemacs.org>
* xemacs.def.in.in: Condition error_check_* symbols on
ERROR_CHECK_TYPES.
Index: src/xemacs.def.in.in
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/xemacs.def.in.in,v
retrieving revision 1.12
diff -u -r1.12 xemacs.def.in.in
--- src/xemacs.def.in.in 29 Nov 2005 08:38:32 -0000 1.12
+++ src/xemacs.def.in.in 29 Nov 2005 13:09:52 -0000
＠＠ -82,12 +82,22 ＠＠
eputenv
#ifdef DEBUG_XEMACS
eq_with_ebola_notice /* EQ_WITH_EBOLA_NOTICE */
+#endif
+#ifdef ERROR_CHECK_TYPES
error_check_cons
+#ifdef HAVA_LDAP
error_check_ldap
+#endif
error_check_opaque_ptr
+#ifdef HAVE_POSTGRESQL
error_check_pgconn
error_check_pgresult
+#endif
error_check_string
+#ifdef NEW_GC
+error_check_string_direct_data
+error_check_string_indirect_data
+#endif
#endif
free_opaque_ptr
get_coding_system_for_text_file
＠＠ -150,7 +160,7 ＠＠
vector2
vector3
warn_when_safe
-#ifdef DEBUG_XEMACS
+#ifdef ERROR_CHECK_TYPES
wrap_record_1
#endif
write_c_string
＠＠ -196,7 +206,7 ＠＠
Fsignal
Fthrow
Fvector
-#ifdef DEBUG_XEMACS
+#ifdef ERROR_CHECK_TYPES
XINT_1
#endif
--
Marcus
3:21 p.m.
New subject: [PATCH] repair xemacs.def.in.in
>>>> "Marcus" == Marcus Crestani
<crestani(a)informatik.uni-tuebingen.de> writes:
>>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Aaaaaarrgh!!!! I was ready to release 21.5.24 (tarballs are
SJT> already built)
Marcus> Stephen, it seems that not many people are using Cygwin
Marcus> anyway, so I think this patch can wait until the release
Marcus> is out. No need to redo the whole work for the third
Marcus> time!
Actually, a fair number of people are clearly using Cygwin; the
question is how many are simply avoiding modules or avoiding
error-checking because of these problems. Between your work with the
new gc and Ben's Unicode internal stuff, I expect substantial
instability for the next few weeks. So this is the checkpoint release
we point people at; I don't want known build breakage in it.
True, the instability of MC-ALLOC and the new gc so far hasn't leaked
into the non-MC-ALLOC builds, but with the refactoring that Ben is
(correctly IMO) demanding, it very well could.
So I think this release should wait a couple days.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:53 a.m.
New subject: [PATCH] repair xemacs.def.in.in
Stephen J. Turnbull wrote:
>>>>>"Marcus" == Marcus Crestani
<crestani(a)informatik.uni-tuebingen.de> writes:
>>>>>
>>>>>
>>>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Aaaaaarrgh!!!! I was ready to release 21.5.24 (tarballs are
SJT> already built)
Marcus> Stephen, it seems that not many people are using Cygwin
Marcus> anyway, so I think this patch can wait until the release
Marcus> is out. No need to redo the whole work for the third
Marcus> time!
Actually, a fair number of people are clearly using Cygwin; the
question is how many are simply avoiding modules or avoiding
error-checking because of these problems. Between your work with the
new gc and Ben's Unicode internal stuff, I expect substantial
instability for the next few weeks. So this is the checkpoint release
we point people at; I don't want known build breakage in it.
True, the instability of MC-ALLOC and the new gc so far hasn't leaked
into the non-MC-ALLOC builds, but with the refactoring that Ben is
(correctly IMO) demanding, it very well could.
So I think this release should wait a couple days.
btw i don't think i'm going to be able to commit unicode-internal until
mid-january or later.
3:46 p.m.
New subject: [PATCH] repair xemacs.def.in.in (was: Implicit INLINE_HEADERS in modules don't get instantiated)
--- Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
>>>>>"RR" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
RR> I have no idea whether or not this is the right thing to do, but
RR> it works for Cygwin.
I see some problems with Rick's patch:
RR> #ifdef DEBUG_XEMACS
RR> eq_with_ebola_notice /* EQ_WITH_EBOLA_NOTICE */
RR> +error_check_cons
The error_check_* symbols have to be conditioned on ERROR_CHECK_TYPES,
not on DEBUG_XEMACS.
RR> +error_check_ldap
This has to be conditioned on HAVE_LDAP. Only with HAVE_LDAP the
lrecord type `ldap' gets instantiated in inline.c.
RR> +error_check_pgconn
RR> +error_check_pgresult
This has to be conditioned on HAVA_POSTGRESQL, for the same reason as
above.
RR> +error_check_string
The new GC string implementation requires that two more symbols are
added: error_check_direct_string_data and
error_check_indirect_string_data.
RR> +#ifdef DEBUG_XEMACS
RR> +wrap_record_1
RR> +#endif
[...]
RR> +#ifdef DEBUG_XEMACS
RR> +XINT_1
RR> +#endif
Both symbols have to be conditioned on ERROR_CHECK_TYPES.
Thanks, Marcus, and good catch. I should've been more careful ;-)
--Rick
6932
days inactive
6933
days old
7 comments
4 participants
participants (4)
-
Ben Wing -
Marcus Crestani -
Rick Rankin -
Stephen J. Turnbull