>>> Compiling source in /var/tmp/portage/app-editors/emacs-22.2-r3/work/emacs-22.2 ... * Configuring to build with no toolkit * econf: updating emacs-22.2/config.sub with /usr/share/gnuconfig/config.sub * econf: updating emacs-22.2/config.guess with /usr/share/gnuconfig/config.guess ./configure --prefix=/usr --host=sh4-unknown-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --program-suffix=-emacs-22 --infodir=/usr/share/info/emacs-22 --without-carbon --without-sound --with-x --without-toolkit-scroll-bars --with-jpeg --with-tiff --with-gif --with-png --with-xpm --with-x-toolkit=no --without-gtk --without-hesiod --without-kerberos --without-kerberos5 --build=sh4-unknown-linux-gnu checking build system type... sh4-unknown-linux-gnu checking host system type... sh4-unknown-linux-gnu configure: error: Emacs hasn't been ported to `sh4-unknown-linux-gnu' systems. Check `etc/MACHINES' for recognized configuration names. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/app-editors/emacs-22.2-r3/work/emacs-22.2/config.log * * ERROR: app-editors/emacs-22.2-r3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * emacs-22.2-r3.ebuild, line 153: Called econf 'src_compile' 'src_compile' '--program-suffix=-emacs-22' '--infodir=/usr/share/info/emacs-22' '--without-carbon' '--without-sound' '--with-x' '--without-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-xpm' '--with-x-toolkit=no' '--without-gtk' '--without-hesiod' * ebuild.sh, line 513: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/app-editors:emacs-22.2-r3:20080920-180658.log'. * The ebuild environment file is located at '/var/tmp/portage/app-editors/emacs-22.2-r3/temp/environment'. *
Created attachment 165948 [details, diff] Patch for configure.in Hm, you had keyworded and stabilised emacs-22.1-r3 on sh in January, bug 180642 ;-) Let's try a stupid approach, maybe it just works with attached patch? I've taken it from configure.in of Emacs 21.4.
> Let's try a stupid approach, maybe it just works with attached patch? > I've taken it from configure.in of Emacs 21.4. To correct myself, it's not in vanilla Emacs 21, but from our own 04_all_sh.patch (by matsuu, back in 2005, according to the ChangeLog). Looks like it hasn't found its way upstream.
In fact, dropping of SuperH support was announced by upstream (why they regard it an "obsolete platform" is a mystery to me): http://lists.gnu.org/archive/html/info-gnu-emacs/2007-11/msg00000.html So maybe we should start an effort to have it included in Emacs 23 again?
That patch works fine, quick!
frankly i find the emacs policy of hardcoding architectures/operating systems to be completely moronic, but my opinion doesnt really matter. nor does emacs really matter to me ... nano forever! if Raúl says it works, then ship it
Fixed in 22.2-r3 and 22.3. The Gentoo patch for Emacs 21 also had big-endian SuperH support in src/m/sheb.h, should we account for that, too?
yes please ... "eb" is appended after the number so "sh4" is little endian SH4 while "sh4eb" is big endian SH4
Patch for big-endian is ready, I'll commit it next week. (I'm abroad atm without commit access.)
> "sh4" is little endian SH4 while "sh4eb" is big endian SH4 Looks like upstream doesn't like different "machine" files for the two byte sexes, so we should test for endianness from within C. @Mike: Would the following work? #include <endian.h> #if __BYTE_ORDER == __LITTLE_ENDIAN # undef WORDS_BIG_ENDIAN #elif __BYTE_ORDER == __BIG_ENDIAN # define WORDS_BIG_ENDIAN #else # error "unknown byte sex" #endif
(In reply to comment #9) yes, that should work fine for all Linux ports i think
