7:48 p.m.
The error appears to be caused by a bug in the way autoconf deals with
WORDS_BIGENDIAN when configure runs on a G5.
The resulting src/config.h from autoconf 2.63 places
/* #undef WORDS_BIGENDIAN */
in src/config.h whereas 2.62- and 2.61-created configurse add
#define WORDS_BIGENDIAN 1
to src/config.h
When a 2.62 (or 2.61) created configure runs, it says
checking whether byte ordering is bigendian... yes
but 2.63 script says
checking whether byte ordering is bigendian... universal
I have no idea whether those are different answers, but they seem to be.
This appears to cause a conflict when --with-union-type is defined from
configure. I recreated configure with autoconf (version 2.61 and 2.62)
and found that WORDS_BIGENDIAN was defined, and the resulting make
worked even with unions used for Lisp_Object.
Could this point to the potential for even more subtle bugs
Here is the configuration that works fine when autoconf 2.62 is used:
./configure '--with-mule' '--with-widgets=athena'
'--with-athena=next'
'--with-dialogs=athena' '--with-scrollbars=lucid'
'--without-debug'
'--without-error-checking' '--with-x11'
'--prefix=/Users/royar/usr/local' '--with-png' '--with-jpeg'
'--with-tiff' '--with-xmu' '--with-xim=no'
'--enable-sound=none,esd'
'--disable-xfs' '--enable-dump-in-exec' '--with-modules'
'--enable-external-widget' '--with-dynamic' '--disable-kkcc'
'--disable-mc-alloc' '--without-ipv6-cname' '--without-ldap'
'--enable-optimization' '--with-cflags-optimization=-Os -pipe -mcpu=970
-mtune=970 -mpim-altivec -arch ppc' '--with-xft=emacs,gauges,tabs'
'--with-compiler=gcc-4.2' '--with-bignum=gmp'
'--with-union-type'
'CC=/usr/bin/gcc-4.2' 'CFLAGS=' 'LDFLAGS=-L/usr/lib -lncurses
-lgmp
-lz -L/usr/X11/lib -lpng -lXpm -lXft -lXrender -lXmu -lXt -lXext
-lX11 -lSM -lICE -lneXtaw -lfontconfig -L/opt/local/lib -ltiff -ljpeg
-lesd'
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:20 a.m.
robert delius royar writes:
The error appears to be caused by a bug in the way autoconf deals
with
WORDS_BIGENDIAN when configure runs on a G5.
The resulting src/config.h from autoconf 2.63 places
/* #undef WORDS_BIGENDIAN */
in src/config.h whereas 2.62- and 2.61-created configurse add
#define WORDS_BIGENDIAN 1
to src/config.h
That seems bad.
When a 2.62 (or 2.61) created configure runs, it says
checking whether byte ordering is bigendian... yes
but 2.63 script says
checking whether byte ordering is bigendian... universal
They are different answers (on my G4 Mac OS X 10.4.11 2.63 still says
"yes"), but why it matters I don't understand. I guess I'll have to
back up to 2.62 for the moment.
Could this point to the potential for even more subtle bugs
Yes, but there's not much we can do about "potential" unless somebody
is willing to do the work of porting our whole configuration script to
a better system. We're stuck with autoconf for now, and will have to
put up with the bugs.
Thank you for the report.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:36 p.m.
Thu, 1 Jan 2009 (16:20 +0900 UTC) Stephen J. Turnbull wrote:
robert delius royar writes:
> The error appears to be caused by a bug in the way autoconf deals with
> WORDS_BIGENDIAN when configure runs on a G5.
> The resulting src/config.h from autoconf 2.63 places
> /* #undef WORDS_BIGENDIAN */
> in src/config.h whereas 2.62- and 2.61-created configurse add
> #define WORDS_BIGENDIAN 1
> to src/config.h
That seems bad.
> When a 2.62 (or 2.61) created configure runs, it says
> checking whether byte ordering is bigendian... yes
> but 2.63 script says
> checking whether byte ordering is bigendian... universal
They are different answers (on my G4 Mac OS X 10.4.11 2.63 still says
"yes"), but why it matters I don't understand. I guess I'll have to
back up to 2.62 for the moment.
I read a bit about the yes vs. universal issue after I sent my email.
The problem can't be solved by projects without additional logic. The
test autoconf uses appears to be something such as
if compiling on Apple OS X gcc
if gcc flags contain an -arch flag
if -arch flag contains *ppc* or *86*
assume we are compiling for a universal system
else
further tests
else
further tests
The problem is that the writers appear not to have considered that
someone would select an architecture who was compiling on a specific
system just to get the optimization for that arch rather than for one of
its (earlier) compatible archs (example, forcing G5 optimization when
gcc would normally optimize for powerpc generic G4/G5 or forcing Xcode
NOT to create a universal binary)
The workaround is (for the user) to remove -arch from flags or to set
$ac_cv_c_bigendian to "yes" in the environment before running the
configure.
> Could this point to the potential for even more subtle bugs
Yes, but there's not much we can do about "potential" unless somebody
is willing to do the work of porting our whole configuration script to
a better system. We're stuck with autoconf for now, and will have to
put up with the bugs.
As is often the case when users with a little knowledge build packages
such as XEmacs, user error uncovers potential problems. I was using
-arch in a way that made sense for my three-Mac set up, but in a way
that was not what the autoconf writers anticipated. Hobbyists (or
knackers) such as I are often a pain for tech support.
Thank you for the report.
You are welcome
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6151
days inactive
6152
days old
2 comments
2 participants
participants (2)
-
robert delius royar -
Stephen J. Turnbull