add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

I suggest adding something like the following to etc/PROBLEMS and
etc/TODO. I not infrequently want to compile 32-bit apps on 64-bit
systems (so that they can be run on otherwise identical 64- and 32-bit
systems).



*** PROBLEMS    16 Dec 2006 14:00:15 -0000 1.202
--- PROBLEMS    9 Jan 2007 01:39:51 -0000
***************
*** 2355,2360 ****
--- 2355,2366 ----
  the problem, install the current version of GNU Sed, then rerun
  Emacs's configure script.
  
+ *** Building a 32-bit executable on a 64-bit GNU/Linux architecture fails.
+ 
+ For example, if CFLAGS=-m32 is passed to configure, the resulting
+ build will fail.  There is no fix for this problem at present - when
+ building on a 64-bit platform, you must build a 64-bit executable.
+ 
  *** Building the Cygwin port for MS-Windows can fail with some GCC
      version
  
  Building Emacs 22 with Cygwin builds of GCC 3.4.4-1 and 3.4.4-2 is


*** TODO   2 Jan 2007 18:29:37 -0000   1.137
--- TODO   9 Jan 2007 01:40:09 -0000
***************
*** 159,164 ****
--- 159,167 ----
  
  * Other features we would like:
  
+ ** Make it possible to build a 32-bit executable on 64-bit systems.
+   See http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-10/msg00462.html
+ 
  ** Remove the default toggling behavior of minor modes when called from elisp
  rather than interactively.  This a trivial one-liner in easy-mode.el.
  ** Create a category of errors called `user-error' for errors which are

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> I suggest adding something like the following to etc/PROBLEMS and
> etc/TODO. I not infrequently want to compile 32-bit apps on 64-bit
> systems (so that they can be run on otherwise identical 64- and 32-bit
> systems).

The right thing to do is to pass --build=i386-linux-gnu when configuring.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Richard Stallman]

    The right thing to do is to pass --build=i386-linux-gnu when configuring.

If you do that, does it work correctly?

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     The right thing to do is to pass --build=i386-linux-gnu when configuring.
>
> If you do that, does it work correctly?

I can't test myself, but it certainly works for ppc vs ppc64.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Andreas Schwab wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>>     The right thing to do is to pass --build=i386-linux-gnu when configuring.
>>
>> If you do that, does it work correctly?
>
> I can't test myself, but it certainly works for ppc vs ppc64.


I wasn't aware of this method, so thanks for telling me about it.

By itself, it does not work for me. The build process just goes on to
call "gcc" as normal, which compiles x86_64 objects rather than i386
ones.

I found I had to do:

i) export CFLAGS=-m32; export LDFLAGS=-m32
    (to get i386 objects)

ii) Add "--build=i386-linux-gnu --x-libraries=/usr/X11R6/lib --without-sound"

to configure's arguments. This is on RHEL4 x86_64. The --x option is
needed to stop the build trying to use the 64-bit libraries from
/usr/X11R6/lib64. The --sound option is I think needed just to work
around a RHEL bug (there seems to be no x86_64 package that provides a
32-bit libasound).


I imagine it's reasonable to expect configure to just Do The Right
Thing for all of these but the sound issue, without so much user
intervention? Actually, I guess it should auto-detect no compatible
sound libraries as well...

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Actually, I don't know any more if I'm asking for a reasonable thing.
Should I expect to be able to _compile_ 32-bit apps on an x86_64
system, or just _run_ them? The fact that almost none of the OS
"devel" packages exist in 32-bit form suggests the latter.


Glenn Morris wrote:

> I imagine it's reasonable to expect configure to just Do The Right
> Thing

With some playing around, I find the following change enables me to
just use configure --build=i386-linux-gnu to get the desired result. I
don't know how correct/desirable it is though.


Index: configure.in
===================================================================
RCS file: /sources/emacs/emacs/configure.in,v
retrieving revision 1.428
diff -c -c -w -r1.428 configure.in
*** configure.in	3 Jan 2007 23:47:04 -0000	1.428
--- configure.in	10 Jan 2007 04:09:31 -0000
***************
*** 1486,1491 ****
--- 1486,1523 ----
    CPPFLAGS="$c_switch_system $c_switch_machine $CPPFLAGS"
  fi
  
+ ## Build a 32-bit version on x86_64 GNU/Linux?
+ case "${canonical}" in
+   i386-*linux-gnu* )
+     case `$SHELL "$ac_aux_dir/config.guess"` in
+       x86_64-*-linux-gnu* )
+ 
+         x86_64_build_m32=yes
+ 
+         save_CFLAGS="$CFLAGS"
+         CFLAGS="-m32 $CFLAGS"
+         AC_MSG_CHECKING([whether compiler understands -m32])
+         AC_TRY_COMPILE([], [], has_option=yes, has_option=no,)
+         AC_MSG_RESULT($has_option)
+         if test $has_option = yes; then
+           REAL_CFLAGS="-m32 $REAL_CFLAGS"
+         fi
+         CFLAGS="$save_CFLAGS"
+         unset has_option
+         unset save_CFLAGS
+ 
+         save_LDFLAGS="$LDFLAGS"
+         LDFLAGS="-m32 $LDFLAGS"
+         AC_MSG_CHECKING([whether linker understands -m32])
+         AC_LINK_IFELSE([main(){return 0;}],
+           [AC_MSG_RESULT(yes)],
+           LDFLAGS="$save_LDFLAGS"
+           [AC_MSG_RESULT(no)])
+         unset save_LDFLAGS ;;
+ 
+     esac ;;
+ esac
+ 
  dnl For AC_FUNC_GETLOADAVG, at least:
  AC_CONFIG_LIBOBJ_DIR(src)
  
***************
*** 1765,1770 ****
--- 1797,1805 ----
  
  if test "${x_libraries}" != NONE; then
    if test -n "${x_libraries}"; then
+     if test -n "${x86_64_build_m32}"; then
+       x_libraries=`echo ${x_libraries} | sed -e "s:/lib64:/lib:g"`
+     fi
      LD_SWITCH_X_SITE=-L`echo ${x_libraries} | sed -e "s/:/ -L/g"`
      LD_SWITCH_X_SITE_AUX=-R`echo ${x_libraries} | sed -e "s/:/ -R/g"`
    fi

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Stefan Monnier]

> Actually, I don't know any more if I'm asking for a reasonable thing.
> Should I expect to be able to _compile_ 32-bit apps on an x86_64
> system, or just _run_ them? The fact that almost none of the OS
> "devel" packages exist in 32-bit form suggests the latter.

I for one have compiled Emacs in 32bit-mode on an amd64 machine in two
difference circumstances:

- once on my home machine which is a Debian GNU/Linux x86 system (no amd64
  lib or compiler installed) with an amd64 kernel (mostly to get access to
  more than 3GB of ram, although a bigmem kernel would have done the trick
  as well).

- once on my work machine, which is running a version of Fedora for amd64
  and where some of the 32bit libs are indeed missing.  There's still plenty
  of libs to build Emacs.  The main reason there was to test the 32bit
  build, as well as to get a build which uses less memory.


        Stefan

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Stefan Monnier wrote:

> - once on my work machine, which is running a version of Fedora for
> amd64 and where some of the 32bit libs are indeed missing. There's
> still plenty of libs to build Emacs.

[my reply is off-topic for Emacs, I think]

In RHEL 4, there is no package that provides 32-bit devel files for:
libasound, libjpeg, libtiff, libungif, libpng, etc. So you can build
a 32-bit Emacs, but it is missing a lot of optional support.

The non-devel packages provide libfoo.so.VERSION in 32- and 64-bit
forms, but the symlink libfoo.so (sans version) gets relegated to the
devel package, which only exists in x86_64 form, most of the time. Of
course, one can trivially add the necessary 32-bit symlink, but it
certainly gave me the impression one is only supposed to be able to
_run_ 32-bit apps, not _compile_ them. Having said that, I've been
told more 32-bit devel packages will feature in RHEL5.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Jan 2007 10:28:30 -0500
> Cc: Andreas Schwab <schwab@suse.de>, rms@gnu.org, emacs-devel@gnu.org
> 
> I for one have compiled Emacs in 32bit-mode on an amd64 machine in two
> difference circumstances:

How about sharing the experience: how did you configure and build to
get a 32bit binaries?

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Stefan Monnier]

>> I for one have compiled Emacs in 32bit-mode on an amd64 machine in two
>> difference circumstances:

> How about sharing the experience: how did you configure and build to
> get a 32bit binaries?

On my work machine it was a while back and I can't remember doing much: it
seemed to just work.  But I probably had to muck around with something,
I just can't remember it, probably because it was fairly obvious.

On my home machine I reported my problems here at the time and basically
fixed them for this one time by adding 

   #ifndef _LP64
   /* It's actually running in x86 compatibility mode. */
   #include "m/intel386.h"
   #else

to src/m/amdx86-64.h and a few other quick&dirt hacks.
Luckily my system is pure 32bit (other than the kernel) so I didn't have to
deal with issues such as /usr/lib64/crtn.o.


        Stefan


PS: IMHO we shouldn't need to specify --build=i386-linux-gnu.  Instead,
passing CC="gcc -m32" should be sufficient.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Stefan Monnier wrote:

> PS: IMHO we shouldn't need to specify --build=i386-linux-gnu.  Instead,
> passing CC="gcc -m32" should be sufficient.

This may be a superfluous comment (depending on the meaning of
"should"), but in practice it is not sufficient (RHEL4 x86_64 with all
available relevant 32-bit libs installed):

Using CC="gcc -m32":

1) Configure wrongly picks /usr/X11R6/lib64 for the X windows
   libraries. Manually fix this by passing --x-libraries=/usr/X11R6/lib.

2) Configure wrongly decides sound is available, when it is not
  (there is no standard package for this OS that provides 32-bit
  "libasound.so"). Bootstrap fails trying to create temacs due to the
  lack of compatible libasound.so. Fix this by manually passing
  --without-sound.

3) Configure sets HAVE_X86_64_LIB64_DIR to 1, so linking temacs fails
   because it tries to use /usr/lib64/crt1.o etc rather than
   /usr/lib/crt1.o etc. After correcting this...

4) temacs segfaults after loading subr during dumping.

There are also hundreds of "warning: left shift count >= width of
type" on compilation.


Just using --build=i386-linux-gnu is also not sufficient. The build
just calls "gcc" as usual, which compiles 64-bit objects.


Only the combination of the two methods works for me (still subject to
1 and 2, not 3 or 4). No compilation warnings either.


Quite possibly the fix is trivial for someone who knows what they are
doing. I have nothing else to say as to what the "right" approach is
or how to do it; I can only offer to test any solutions.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Only the combination of the two methods works for me (still subject to
> 1 and 2, not 3 or 4). No compilation warnings either.

And this is exactly the supported way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Stefan Monnier]

>> PS: IMHO we shouldn't need to specify --build=i386-linux-gnu.  Instead,
>> passing CC="gcc -m32" should be sufficient.

> This may be a superfluous comment (depending on the meaning of
> "should"),

Yes, it is superfluous ;-)
I didn't mean that it works, but that we should make it work.


        Stefan

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Richard Stallman]

The change as you wrote it looks rather ad-hoc.  I have a suspicion
that a person who is more familiar with the design of Emacs
configure.in might find a much cleaner fix.  But I am not familiar
enough with it to do any better myself.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Richard Stallman wrote:

> The change as you wrote it looks rather ad-hoc.  I have a suspicion
> that a person who is more familiar with the design of Emacs
> configure.in might find a much cleaner fix.

I think you are absolutely right (indeed, almost charitable in your
circumlocution!). :)

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Richard Stallman]

Does anyone have the expertise to look for a cleaner version of this
change?


From: Glenn Morris <rgm@gnu.org>
To: emacs-devel@gnu.org
Cc: rms@gnu.org,  Andreas Schwab <schwab@suse.de>
Subject: Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system
Date: Tue, 09 Jan 2007 23:14:02 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii



Actually, I don't know any more if I'm asking for a reasonable thing.
Should I expect to be able to _compile_ 32-bit apps on an x86_64
system, or just _run_ them? The fact that almost none of the OS
"devel" packages exist in 32-bit form suggests the latter.


Glenn Morris wrote:

> I imagine it's reasonable to expect configure to just Do The Right
> Thing

With some playing around, I find the following change enables me to
just use configure --build=i386-linux-gnu to get the desired result. I
don't know how correct/desirable it is though.


Index: configure.in
===================================================================
RCS file: /sources/emacs/emacs/configure.in,v
retrieving revision 1.428
diff -c -c -w -r1.428 configure.in
*** configure.in	3 Jan 2007 23:47:04 -0000	1.428
--- configure.in	10 Jan 2007 04:09:31 -0000
***************
*** 1486,1491 ****
--- 1486,1523 ----
    CPPFLAGS="$c_switch_system $c_switch_machine $CPPFLAGS"
  fi
  
+ ## Build a 32-bit version on x86_64 GNU/Linux?
+ case "${canonical}" in
+   i386-*linux-gnu* )
+     case `$SHELL "$ac_aux_dir/config.guess"` in
+       x86_64-*-linux-gnu* )
+ 
+         x86_64_build_m32=yes
+ 
+         save_CFLAGS="$CFLAGS"
+         CFLAGS="-m32 $CFLAGS"
+         AC_MSG_CHECKING([whether compiler understands -m32])
+         AC_TRY_COMPILE([], [], has_option=yes, has_option=no,)
+         AC_MSG_RESULT($has_option)
+         if test $has_option = yes; then
+           REAL_CFLAGS="-m32 $REAL_CFLAGS"
+         fi
+         CFLAGS="$save_CFLAGS"
+         unset has_option
+         unset save_CFLAGS
+ 
+         save_LDFLAGS="$LDFLAGS"
+         LDFLAGS="-m32 $LDFLAGS"
+         AC_MSG_CHECKING([whether linker understands -m32])
+         AC_LINK_IFELSE([main(){return 0;}],
+           [AC_MSG_RESULT(yes)],
+           LDFLAGS="$save_LDFLAGS"
+           [AC_MSG_RESULT(no)])
+         unset save_LDFLAGS ;;
+ 
+     esac ;;
+ esac
+ 
  dnl For AC_FUNC_GETLOADAVG, at least:
  AC_CONFIG_LIBOBJ_DIR(src)
  
***************
*** 1765,1770 ****
--- 1797,1805 ----
  
  if test "${x_libraries}" != NONE; then
    if test -n "${x_libraries}"; then
+     if test -n "${x86_64_build_m32}"; then
+       x_libraries=`echo ${x_libraries} | sed -e "s:/lib64:/lib:g"`
+     fi
      LD_SWITCH_X_SITE=-L`echo ${x_libraries} | sed -e "s/:/ -L/g"`
      LD_SWITCH_X_SITE_AUX=-R`echo ${x_libraries} | sed -e "s/:/ -R/g"`
    fi

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Giorgos Keramidas]

On 2007-01-09 23:14, Glenn Morris <rgm@gnu.org> wrote:
> Actually, I don't know any more if I'm asking for a reasonable thing.
> Should I expect to be able to _compile_ 32-bit apps on an x86_64
> system, or just _run_ them? The fact that almost none of the OS
> "devel" packages exist in 32-bit form suggests the latter.

This depends on the availability of 32-bit versions of the runtime
libraries.  On some systems, both versions of the libraries are
installed, or are available for installation.  On others, only the
'native' binary format is supported.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> I found I had to do:
>
> i) export CFLAGS=-m32; export LDFLAGS=-m32
>     (to get i386 objects)

You should set CC="gcc -m32" instead.  You are in essence using a
different compiler.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Andreas Schwab wrote:

> You should set CC="gcc -m32" instead.  You are in essence using a
> different compiler.

Well, OK, but that seems fairly counterintuitive to me. I'd expect
that to look for an executable called "gcc -m32".

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Andreas Schwab wrote:
>
>> You should set CC="gcc -m32" instead.  You are in essence using a
>> different compiler.
>
> Well, OK, but that seems fairly counterintuitive to me. I'd expect
> that to look for an executable called "gcc -m32".

CC is not handled differently from CFLAGS, both in the shell and in the
makefile.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Andreas Schwab wrote:

> CC is not handled differently from CFLAGS, both in the shell and in the
> makefile.

I'm not entirely sure what that statement means, other than it will in
fact work and not look for "gcc -m32". Which I did not doubt (I see in
the make info pages that 'The "name of a program" may also contain
some command arguments'), I just personally find it an odd way of
doing things. I guess it has the advantage of not needing to set
LDFLAGS as well.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> I just personally find it an odd way of doing things.

You are using a different compiler in essence, so it should be identified
by $CC.

> I guess it has the advantage of not needing to set LDFLAGS as well.

Yes, that's the main point.  It will make sure the right compiler is used
independent of the use of $CFLAGS or $LDFLAGS.  For example, you don't
have to think about -m32 if you want to override CFLAGS temporally.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Stuart D. Herring]

> Andreas Schwab wrote:
>
>> You should set CC="gcc -m32" instead.  You are in essence using a
>> different compiler.
>
> Well, OK, but that seems fairly counterintuitive to me. I'd expect
> that to look for an executable called "gcc -m32".

That would be CC="\"gcc -m32\"" instead; the plain " characters in this
case are for (and are removed by) the shell invoking make, not make or the
shells it invokes.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 10 Jan 2007 14:31:44 -0500
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Andreas Schwab wrote:
> 
> > You should set CC="gcc -m32" instead.  You are in essence using a
> > different compiler.
> 
> Well, OK, but that seems fairly counterintuitive to me. I'd expect
> that to look for an executable called "gcc -m32".

CC specifies a shell command, not a file name of the compiler's
executable.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Richard Stallman]

    I found I had to do:

    i) export CFLAGS=-m32; export LDFLAGS=-m32
	(to get i386 objects)

    ii) Add "--build=i386-linux-gnu --x-libraries=/usr/X11R6/lib --without-sound"

Could you please mention this in etc/MACHINES and etc/PROBLEMS?

    I imagine it's reasonable to expect configure to just Do The Right
    Thing for all of these but the sound issue, without so much user
    intervention? Actually, I guess it should auto-detect no compatible
    sound libraries as well...

Yes, it should.  However, we don't need to fix that now
if it is not straightforward.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Richard Stallman wrote:

> Could you please mention this in etc/MACHINES and etc/PROBLEMS?

I did so. It can be removed if someone wants to install a proper fix
for configure.in.

A lot of the stuff in etc/MACHINES seems to be only of historical
interest now, BTW.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Richard Stallman]

Please install your change in etc/PROBLEMS.  However, I think this
feature is not crucial, so please don't add the item to etc/TODO.  If
someone implements it, we would install it assuming the code is clean,
but it isn't a priority.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Giorgos Keramidas]

On 2007-01-08 20:44, Glenn Morris <rgm@gnu.org> wrote:
> I suggest adding something like the following to etc/PROBLEMS and
> etc/TODO. I not infrequently want to compile 32-bit apps on 64-bit
> systems (so that they can be run on otherwise identical 64- and 32-bit
> systems).

I don't really think the text below is correct.

I have been building 32-bit versions of Emacs 22 on Solaris amd64
systems for several months now, and the build works fine.  This means
that, at least the following part of the text below is false:

    "when building on a 64-bit platform, you must build a 64-bit
    executable"

Depending on the set of runtime libraries, and the support of the build
system for compiling and installing 32-bit vs. 64-bit binaries, the
above statement may or may not be true.

> *** PROBLEMS    16 Dec 2006 14:00:15 -0000 1.202
> --- PROBLEMS    9 Jan 2007 01:39:51 -0000
> ***************
> *** 2355,2360 ****
> --- 2355,2366 ----
>   the problem, install the current version of GNU Sed, then rerun
>   Emacs's configure script.
>   
> + *** Building a 32-bit executable on a 64-bit GNU/Linux architecture fails.
> + 
> + For example, if CFLAGS=-m32 is passed to configure, the resulting
> + build will fail.  There is no fix for this problem at present - when
> + building on a 64-bit platform, you must build a 64-bit executable.
> + 
>   *** Building the Cygwin port for MS-Windows can fail with some GCC
>       version
>   
>   Building Emacs 22 with Cygwin builds of GCC 3.4.4-1 and 3.4.4-2 is
> 
> 
> *** TODO   2 Jan 2007 18:29:37 -0000   1.137
> --- TODO   9 Jan 2007 01:40:09 -0000
> ***************
> *** 159,164 ****
> --- 159,167 ----
>   
>   * Other features we would like:
>   
> + ** Make it possible to build a 32-bit executable on 64-bit systems.
> +   See http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-10/msg00462.html
> + 
>   ** Remove the default toggling behavior of minor modes when called from elisp
>   rather than interactively.  This a trivial one-liner in easy-mode.el.
>   ** Create a category of errors called `user-error' for errors which are

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Andreas Schwab]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On 2007-01-08 20:44, Glenn Morris <rgm@gnu.org> wrote:
>> I suggest adding something like the following to etc/PROBLEMS and
>> etc/TODO. I not infrequently want to compile 32-bit apps on 64-bit
>> systems (so that they can be run on otherwise identical 64- and 32-bit
>> systems).
>
> I don't really think the text below is correct.
>
> I have been building 32-bit versions of Emacs 22 on Solaris amd64
> systems for several months now, and the build works fine.  This means
> that, at least the following part of the text below is false:
>
>     "when building on a 64-bit platform, you must build a 64-bit
>     executable"

Same for PowerPC64 systems, where the runtime environment is 32-bit by
default.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Glenn Morris]

Giorgos Keramidas wrote:

> I don't really think the text below is correct.

Which is why it was never installed, following the subsequent
discussion in this thread.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Richard Stallman]

    I don't really think the text below is correct.

    I have been building 32-bit versions of Emacs 22 on Solaris amd64
    systems for several months now, and the build works fine.  This means
    that, at least the following part of the text below is false:

Can you write text that is more correct?

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Giorgos Keramidas]

On 2007-01-15 18:28, Richard Stallman <rms@gnu.org> wrote:
>     I don't really think the text below is correct.
> 
>     I have been building 32-bit versions of Emacs 22 on Solaris amd64
>     systems for several months now, and the build works fine.  This means
>     that, at least the following part of the text below is false:
> 
> Can you write text that is more correct?

Yes.

Please note that I haven't been able to build a 64-only version of Emacs
on Solaris amd64; Emacs 22.X crashes during the autoload stage of the
bootstrap process, when I try to build a 64-bit binary on Solaris.

Nevertheless, I can definitely help with writing the text for 32-bit
builds for Solaris and FreeBSD.  For other systems, I may need some help
from people who are more experienced in their use, and have more current
installations than me.

Re: add etc/PROBLEMS entry for building 32-bit exe on 64-bit system

[Giorgos Keramidas]

On 2007-01-16 01:33, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> On 2007-01-15 18:28, Richard Stallman <rms@gnu.org> wrote:
> >     I don't really think the text below is correct.
> > 
> >     I have been building 32-bit versions of Emacs 22 on Solaris amd64
> >     systems for several months now, and the build works fine.  This means
> >     that, at least the following part of the text below is false:
> > 
> > Can you write text that is more correct?
> 
> Yes.
> 
> Please note that I haven't been able to build a 64-only version of Emacs
> on Solaris amd64; Emacs 22.X crashes during the autoload stage of the
> bootstrap process, when I try to build a 64-bit binary on Solaris.
> 
> Nevertheless, I can definitely help with writing the text for 32-bit
> builds for Solaris and FreeBSD.  For other systems, I may need some help
> from people who are more experienced in their use, and have more current
> installations than me.

Hi all,

I posted the following to rms@gnu.org, but forgot to Cc: the list, so
here it is, in case anyone else has time to review the text too:

%%
diff -r 1f853b6e3574 -r 59b73f6c6f46 ChangeLog
--- a/ChangeLog	Fri Jan 19 07:10:51 2007 +0200
+++ b/ChangeLog	Fri Jan 19 17:04:43 2007 +0200
@@ -1,3 +1,8 @@ 2007-01-18  Bruno Haible  <bruno@clisp.o
+2007-01-19  Giorgos Keramidas  <keramida@ceid.upatras.gr> (tiny change)
+
+	* etc/MACHINES: Describe how 32-bit and 64-bit versions of Emacs
+	  can be compiled on Solaris systems.
+
 2007-01-18  Bruno Haible  <bruno@clisp.org> (tiny change)
 
 	* INSTALL: Info files moved to share/info.
diff -r 1f853b6e3574 -r 59b73f6c6f46 etc/MACHINES
--- a/etc/MACHINES	Fri Jan 19 07:10:51 2007 +0200
+++ b/etc/MACHINES	Fri Jan 19 17:04:43 2007 +0200
@@ -1021,11 +1021,27 @@ Sun 3, Sun 4 (sparc), Sun 386 (m68k-sun-
 			       sparc-sun-sunos4.1.3noshr, sparc-sun-solaris2.*,
 			       i386-sun-solaris2.*, sparc*-*-linux-gnu)
 
+  To build a 32-bit Emacs (i.e. if you are having any sort of problem
+  bootstrapping a 64-bit version), you can use the Sun Studio compiler
+  and configure Emacs with:
+
+    env CC="cc -xarch=v7" CFLAGS='' ./configure    # on SPARC systems
+    env CC="cc -xarch=386" CFLAGS='' ./configure   # on x86 systems
+
+  On Solaris 2.10, it is also possible to use /usr/sfw/bin/gcc to build
+  a 32-bit version of Emacs.  Just make sure you point ./configure to
+  the right compiler:
+
+    env CC='/usr/sfw/bin/gcc -m32' ./configure
+
   To build a 64-bit Emacs (with larger maximum buffer size and
   including large file support) on a Solaris system which supports
   64-bit executables, use the Sun compiler, configuring something like
   this (see the cc documentation for information on 64-bit
-  compilation):  env CC="cc -xarch=v9" ./configure
+  compilation):
+
+    env CC="cc -xarch=v9" CFLAGS='' ./configure    # on SPARC systems
+    env CC="cc -xarch=amd64" CFLAGS='' ./configure # on x86 systems
 
   As of version 2.95, GCC doesn't support the 64-bit ABI properly, but
   later releases may.
%%

There is a buglet in the version I posted to Richard.  The last command,
which can be used to build a 64-bit Emacs on Solaris uses -xarch=386,
which should be replaced with the version shown above (-xarch=amd64).

Regards,
Giorgos