Debian Bug report logs - #248796
emacs21: FTBFS amd64: machine description missing

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: emacs21: FTBFS amd64: machine description missing

Date: Thu, 13 May 2004 05:46:37 +0200

[Message part 1 (text/plain, inline)]

Package: emacs21
Version: 21.3+1-4
Severity: important
Tags: patch
Justification: fails to build from source

Hi,

attached is patch that allows emacs21 to be build on amd64. I copied
and adapted the machine description from alpha and the resulting
binary doesn't show any emidiat problems (can edit files and python2.3
builds with it). I'm not sure if the settings are all right or if
anything is missing but they seem to work.

So baring anyone finding bugs I would like this to get included.

MfG
	Goswin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.5-amd64
Locale: LANG=C, LC_CTYPE=de_DE

[emacs21_21.3+1.patch (text/plain, attachment)]

Message #10 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jmarant@free.fr>

To: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>, 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Fri, 14 May 2004 09:20:23 +0200

Quoting Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>:

> Package: emacs21
> Version: 21.3+1-4
> Severity: important
> Tags: patch
> Justification: fails to build from source
> 
> Hi,
> 
> attached is patch that allows emacs21 to be build on amd64. I copied
> and adapted the machine description from alpha and the resulting
> binary doesn't show any emidiat problems (can edit files and python2.3
> builds with it). I'm not sure if the settings are all right or if
> anything is missing but they seem to work.
> 
> So baring anyone finding bugs I would like this to get included.

Thanks.

Since AMD64 is already supported in Emacs mainline CVS, I'm going to
compare both ports first.

Cheers,

-- 
Jérôme Marant

Message #15 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Jerome Marant <jmarant@free.fr>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Fri, 14 May 2004 09:40:48 +0200

Jérôme Marant <jmarant@free.fr> writes:

> Quoting Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>:
>
>> Package: emacs21
>> Version: 21.3+1-4
>> Severity: important
>> Tags: patch
>> Justification: fails to build from source
>> 
>> Hi,
>> 
>> attached is patch that allows emacs21 to be build on amd64. I copied
>> and adapted the machine description from alpha and the resulting
>> binary doesn't show any emidiat problems (can edit files and python2.3
>> builds with it). I'm not sure if the settings are all right or if
>> anything is missing but they seem to work.
>> 
>> So baring anyone finding bugs I would like this to get included.
>
> Thanks.
>
> Since AMD64 is already supported in Emacs mainline CVS, I'm going to
> compare both ports first.
>
> Cheers,
>
> -- 
> Jérôme Marant

Then mainlain will be better, 99% sure. If you have a patch you want
to try drop in on debian-amd64 and some of us can test it.

MfG
        Goswin

Message #20 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jmarant@free.fr>

To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Sat, 15 May 2004 10:21:57 +0200

[Message part 1 (text/plain, inline)]

Quoting Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:

> Then mainlain will be better, 99% sure. If you have a patch you want
> to try drop in on debian-amd64 and some of us can test it.

Could you please try with this file and tell me if it works fine?

TIA.

configure.in is almost the same as yours:

-------------
  ## AMD x86-64 Linux-based GNU system
  x86_64-*-linux-gnu* )
    machine=amdx86-64 opsys=gnu-linux
  ;;
-------------    

-- 

Jérôme Marant

[amdx86-64.h (text/x-c-header, attachment)]

Message #23 received at 248796-submitter@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jmarant@free.fr>

To: 248796-submitter@bugs.debian.org

Subject: Anybody there?

Date: Wed, 19 May 2004 16:31:36 +0200

Hello,

Did you try to test the amd64 from upstream I sent last
time?

-- 
Jérôme Marant

Message #28 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Debian Bug Tracking System <248796@bugs.debian.org>

Subject: emacs21: mainline cvs patch FTBFS

Date: Wed, 19 May 2004 21:12:24 +0000

[Message part 1 (text/plain, inline)]

Package: emacs21
Severity: normal
Followup-For: Bug #248796

Hi,

I replaced mypatch with the the mainline file you send but then emacs21
fails, build log is attached. I guess mainline has some more amd64 patches
and optimizations in there.

MfG
	Goswin

-- System Information:
Debian Release: testing/unstable
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.5-amd64
Locale: LANG=C, LC_CTYPE=C

[emacs21_21.3+1-5.0.0.2.pure64_amd64.build (text/plain, attachment)]

Message #33 received at 248796@bugs.debian.org (full text, mbox, reply):

From: jmarant@nerim.net (Jérôme Marant)

To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: mainline cvs patch FTBFS

Date: Thu, 20 May 2004 11:57:56 +0200

Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:

> Package: emacs21
> Severity: normal
> Followup-For: Bug #248796
>
> Hi,
>
> I replaced mypatch with the the mainline file you send but then emacs21
> fails, build log is attached. I guess mainline has some more amd64 patches
> and optimizations in there.

It is quite hard to understand what's going on.

I'll go with your patch, if you think Emacs works fine with it. Do you
confirm you did not encounter any problem?

Thanks.

-- 
Jérôme Marant

Message #38 received at 248796@bugs.debian.org (full text, mbox, reply):

From: jmarant@nerim.net (Jérôme Marant)

To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: mainline cvs patch FTBFS

Date: Thu, 20 May 2004 13:58:06 +0200

[Message part 1 (text/plain, inline)]

Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:

> Package: emacs21
> Severity: normal
> Followup-For: Bug #248796
>
> Hi,
>
> I replaced mypatch with the the mainline file you send but then emacs21
> fails, build log is attached. I guess mainline has some more amd64 patches
> and optimizations in there.

Hmm, last attemp. Could you please try with this file?
It has many chances to work better.

TIA.

[amdx86-64.h (text/x-chdr, inline)]

/* machine description file for AMD x86-64.
   Copyright (C) 2002 Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs; see the file COPYING.  If not, write to
the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.  */


/* The following line tells the configuration script what sort of 
   operating system this machine is likely to run.
   USUAL-OPSYS="linux"  */

#define BITS_PER_LONG           64
#define BITS_PER_EMACS_INT      64

/* Define WORDS_BIG_ENDIAN iff lowest-numbered byte in a word
   is the most significant byte.  */

#undef WORDS_BIG_ENDIAN

/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
 * group of arguments and treat it as an array of the arguments.  */

#define NO_ARG_ARRAY

/* Define WORD_MACHINE if addresses and such have
 * to be corrected before they can be used as byte counts.  */

/* #define WORD_MACHINE */

/* Now define a symbol for the cpu type, if your compiler
   does not define it automatically:
   Ones defined so far include vax, m68000, ns16000, pyramid,
   orion, tahoe, APOLLO and many others */
/* __x86_64 defined automatically.  */

/* Use type int rather than a union, to represent Lisp_Object */
/* This is desirable for most machines.  */

#define NO_UNION_TYPE

/* Define the type to use.  */
#define EMACS_INT               long
#define EMACS_UINT              unsigned long
#define SPECIAL_EMACS_INT

/* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend
   the 24-bit bit field into an int.  In other words, if bit fields
   are always unsigned.

   If you use NO_UNION_TYPE, this flag does not matter.  */

#define EXPLICIT_SIGN_EXTEND

/* Data type of load average, as read out of kmem.  */

#define LOAD_AVE_TYPE long

/* Convert that into an integer that is 100 for a load average of 1.0  */

#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE)

/* Define CANNOT_DUMP on machines where unexec does not work.
   Then the function dump-emacs will not be defined
   and temacs will do (load "loadup") automatically unless told otherwise.  */

/* #define CANNOT_DUMP */

/* Define VIRT_ADDR_VARIES if the virtual addresses of
   pure and impure space as loaded can vary, and even their
   relative order cannot be relied on.

   Otherwise Emacs assumes that text space precedes data space,
   numerically.  */

/* #define VIRT_ADDR_VARIES */

/* Define NO_REMAP if memory segmentation makes it not work well
   to change the boundary between the text section and data section
   when Emacs is dumped.  If you define this, the preloaded Lisp
   code will not be sharable; but that's better than failing completely.  */

/* #define NO_REMAP */

#define PNTR_COMPARISON_TYPE unsigned long

/* On the 64 bit architecture, we can use 60 bits for addresses */

#define VALBITS         60

/* This definition of MARKBIT is necessary because of the comparison of
   ARRAY_MARK_FLAG and MARKBIT in an #if in lisp.h, which cpp doesn't like. */

#define MARKBIT         0x8000000000000000L

/* Define XINT and XUINT so that they can take arguments of type int */
#define XINT(a)  (((long) (a) << (BITS_PER_LONG - VALBITS)) >> (BITS_PER_LONG - VALBITS))
#define XUINT(a) ((long) (a) & VALMASK)

/* Define XPNTR to avoid or'ing with DATA_SEG_BITS */

#define XPNTR(a) XUINT (a)

#undef START_FILES
#define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o

#undef LIB_STANDARD
#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o

[Message part 3 (text/plain, inline)]

 

-- 
Jérôme Marant

Message #43 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: jmarant@nerim.net (Jérôme Marant)

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: mainline cvs patch FTBFS

Date: Thu, 20 May 2004 14:24:41 +0200

jmarant@nerim.net (=?iso-8859-15?q?J=E9r=F4me_Marant?=) writes:

> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
>> Package: emacs21
>> Severity: normal
>> Followup-For: Bug #248796
>>
>> Hi,
>>
>> I replaced mypatch with the the mainline file you send but then emacs21
>> fails, build log is attached. I guess mainline has some more amd64 patches
>> and optimizations in there.
>
> It is quite hard to understand what's going on.
>
> I'll go with your patch, if you think Emacs works fine with it. Do you
> confirm you did not encounter any problem?
>
> Thanks.
>
> -- 
> Jérôme Marant

I edited some files and some packages Build-Depend on it and did
build. I didn't test anything fancy like games on it.

If I find some spare time and don't forget I will compare the two
machine files and try to merge them setting by setting until it fails.
If you don't hear from me in say 2 weeks give me a shout.

I suggest holding this patch back till then unless you're doing a
release anyway. No point getting all the buildds to build it if
something is going to change again in a week.

MfG
        Goswin

PS: The exmacs21 amd64 deb with my patch is on debian-amd64.alioth.d.o
so your not holding anything up by waiting.

MfG
        Goswin

Message #48 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Debian Bug Tracking System <248796@bugs.debian.org>

Subject: emacs21: New patch based on cvs

Date: Thu, 05 Aug 2004 02:43:15 +0200

[Message part 1 (text/plain, inline)]

Package: emacs21
Version: 21.3+1-7
Severity: normal
Followup-For: Bug #248796

Hi,

we have a new patch for emacs21 that is based on the upstream cvs:

http://debian-amd64.alioth.debian.org/gcc-3.4/patches/emacs21_21.3+1-7.0.0.1.amd64.patch

The patch was tested with gcc-3.4 as default which seem to build
fine. I now tried to rebuild the package with gcc-3.3 and it failed:

cd debian/pkg-bin-common/usr/lib/emacs/21.3/x86_64-linux/ \
  && test `ls fns-*.el | wc -l` -eq 1 \
  && rm fns-*.el
make: *** [binary-arch] Error 1

mrvn@dual:~/t/emacs21/emacs21-21.3+1% ls debian/pkg-bin-common/usr/lib/emacs/21.3/x86_64-linux
cvtmail*      fakemail*      hexl*      rcs2log*     yow*
digest-doc*   fns-21.3.1.el  movemail*  sorted-doc*
emacsserver*  fns-21.3.2.el  profile*   vcdiff*


As you can see there are 2 fns-*.el files present for some reason. I'm
too tired to investigate this now but I thought I let you know about
it, maybe you know whats wrong.

MfG
	Goswin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.5-amd64
Locale: LANG=C, LC_CTYPE=de_DE

[emacs21_21.3+1-7_amd64.build (text/plain, attachment)]

Message #53 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jmarant@free.fr>

To: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>, 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: New patch based on cvs

Date: Thu, 5 Aug 2004 13:37:48 +0200

Quoting Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>:

> Package: emacs21
> Version: 21.3+1-7
> Severity: normal
> Followup-For: Bug #248796
>
> Hi,
>
> we have a new patch for emacs21 that is based on the upstream cvs:
>
>
http://debian-amd64.alioth.debian.org/gcc-3.4/patches/emacs21_21.3+1-7.0.0.1.amd64.patch
>

IIRC, this is the second patch I sent to you last time.

> The patch was tested with gcc-3.4 as default which seem to build
> fine. I now tried to rebuild the package with gcc-3.3 and it failed:
>
> cd debian/pkg-bin-common/usr/lib/emacs/21.3/x86_64-linux/ \
>   && test `ls fns-*.el | wc -l` -eq 1 \
>   && rm fns-*.el
> make: *** [binary-arch] Error 1
>
> mrvn@dual:~/t/emacs21/emacs21-21.3+1% ls
> debian/pkg-bin-common/usr/lib/emacs/21.3/x86_64-linux
> cvtmail*      fakemail*      hexl*      rcs2log*     yow*
> digest-doc*   fns-21.3.1.el  movemail*  sorted-doc*
> emacsserver*  fns-21.3.2.el  profile*   vcdiff*
>
>
> As you can see there are 2 fns-*.el files present for some reason. I'm
> too tired to investigate this now but I thought I let you know about
> it, maybe you know whats wrong.

I would be pleased to help, if you can give me access to such a
machine with everything I need to rebuild the package.

Cheers,

--
Jérôme Marant

Message #58 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Jerome Marant <jmarant@free.fr>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: New patch based on cvs

Date: Thu, 05 Aug 2004 14:06:32 +0200

Jérôme Marant <jmarant@free.fr> writes:

> Quoting Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>:
>
>> Package: emacs21
>> Version: 21.3+1-7
>> Severity: normal
>> Followup-For: Bug #248796
>>
>> Hi,
>>
>> we have a new patch for emacs21 that is based on the upstream cvs:
>>
>>
> http://debian-amd64.alioth.debian.org/gcc-3.4/patches/emacs21_21.3+1-7.0.0.1.amd64.patch
>>
>
> IIRC, this is the second patch I sent to you last time.

Hmm, sorry then. I was under the impression this was a new one made
for the gcc-3.4 build.

>> The patch was tested with gcc-3.4 as default which seem to build
>> fine. I now tried to rebuild the package with gcc-3.3 and it failed:
>>
>> cd debian/pkg-bin-common/usr/lib/emacs/21.3/x86_64-linux/ \
>>   && test `ls fns-*.el | wc -l` -eq 1 \
>>   && rm fns-*.el
>> make: *** [binary-arch] Error 1
>>
>> mrvn@dual:~/t/emacs21/emacs21-21.3+1% ls
>> debian/pkg-bin-common/usr/lib/emacs/21.3/x86_64-linux
>> cvtmail*      fakemail*      hexl*      rcs2log*     yow*
>> digest-doc*   fns-21.3.1.el  movemail*  sorted-doc*
>> emacsserver*  fns-21.3.2.el  profile*   vcdiff*
>>
>>
>> As you can see there are 2 fns-*.el files present for some reason. I'm
>> too tired to investigate this now but I thought I let you know about
>> it, maybe you know whats wrong.
>
> I would be pleased to help, if you can give me access to such a
> machine with everything I need to rebuild the package.

What is the problem with there being two scripts? Could I disable that
test and delete both?

> Cheers,

If you send your username and a ssh key to Mattias Wadenstein (maswan)
<maswan@kennedy.acc.umu.se> (i think works) he can give you an
account.

MfG
        Goswin

Message #63 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Frederik Schueler <fs@lowpingbastards.de>

To: 248796@bugs.debian.org

Subject: status of this bug?

Date: Fri, 28 Jan 2005 15:02:26 +0100

[Message part 1 (text/plain, inline)]

Hello,

what is the state of the emacs21 amd64 build patch? 

may I politely ask why it is still not included in the source package?

we have at least 10 packages FTBFS because of this currently, among them
important packages like auctex and python2.3.

The bug is open since 260 days now.

Kind regards
Frederik Schueler

-- 
ENOSIG

[signature.asc (application/pgp-signature, inline)]

Message #68 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jmarant@free.fr>

To: Frederik Schueler <fs@lowpingbastards.de>, 248796@bugs.debian.org

Subject: Re: Bug#248796: status of this bug?

Date: Fri, 28 Jan 2005 17:05:44 +0100

Quoting Frederik Schueler <fs@lowpingbastards.de>:

> Hello,
>
> what is the state of the emacs21 amd64 build patch?
>
> may I politely ask why it is still not included in the source package?
>
> we have at least 10 packages FTBFS because of this currently, among them
> important packages like auctex and python2.3.
>
> The bug is open since 260 days now.

Yes, but amd64 is not an official Debian port yet (and sarge is not
released for amd64), so it has always been in the lowest priorities.

--
Jérôme Marant

Message #73 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: Frederik Schueler <fs@lowpingbastards.de>

Cc: 248796@bugs.debian.org, Jérôme Marant <jerome@debian.org>

Subject: Re: Bug#248796: status of this bug?

Date: Fri, 28 Jan 2005 11:09:28 -0600

Frederik Schueler <fs@lowpingbastards.de> writes:

> what is the state of the emacs21 amd64 build patch? 
>
> may I politely ask why it is still not included in the source package?
>
> we have at least 10 packages FTBFS because of this currently, among them
> important packages like auctex and python2.3.

As I recall, the last I saw of this bug, Jérôme and Goswin were going
back and forth trying to determine a correct patch, and I didn't think
they had come up with a conclusive answer, but perhaps they did (I may
well have misunderstood).

Jérôme: so was one of those patches good enough that I should go ahead
and apply it?  (We can test on one of the ia64 machines if we need
to.)

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Message #78 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jerome.marant@free.fr>

To: Rob Browning <rlb@defaultvalue.org>

Cc: Frederik Schueler <fs@lowpingbastards.de>, 248796@bugs.debian.org

Subject: Re: Bug#248796: status of this bug?

Date: Fri, 28 Jan 2005 19:42:27 +0100

Rob Browning <rlb@defaultvalue.org> writes:

> Jérôme: so was one of those patches good enough that I should go ahead
> and apply it?  (We can test on one of the ia64 machines if we need
> to.)

The latest one is the good one. BTW, It requires a modification of
configure.in.

I could have applied it a long time ago but sarge was "about to
release" so I didn't want to apply untested changes. But sarge
is still not released ...

-- 
Jérôme Marant

Message #83 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: 248796@bugs.debian.org

Subject: Re: emacs21: FTBFS amd64: machine description missing

Date: Fri, 28 Jan 2005 19:53:15 +0100

Hi,

I can confirm that the patch on:
http://debian-amd64.alioth.debian.org/gcc-3.4/patches/emacs21_21.3+1-7.0.0.1.amd64.patch

builds fine on amd64.

It seems to have 1 important change over the last amdx86-64.h you
send:

+/* Define C_ALLOCA if this machine does not support a true alloca
+   and the one written in C should be used instead.
+   Define HAVE_ALLOCA to say that the system provides a properly
+   working alloca function and it should be used.
+   Define neither one if an assembler-language alloca
+   in the file alloca.s should be used.  */
+
+#define C_ALLOCA
+#define HAVE_ALLOCA

It also changes from references from /usr/lib64 to /usr/lib,
which is also a good thing.

If you could please use that patch.


Kurt

Message #88 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jerome.marant@free.fr>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Fri, 28 Jan 2005 22:00:45 +0100

Kurt Roeckx <kurt@roeckx.be> writes:

> Hi,

Hi,

> I can confirm that the patch on:
> http://debian-amd64.alioth.debian.org/gcc-3.4/patches/emacs21_21.3+1-7.0.0.1.amd64.patch
>
> builds fine on amd64.
>
> It seems to have 1 important change over the last amdx86-64.h you
> send:
>
> +/* Define C_ALLOCA if this machine does not support a true alloca
> +   and the one written in C should be used instead.
> +   Define HAVE_ALLOCA to say that the system provides a properly
> +   working alloca function and it should be used.
> +   Define neither one if an assembler-language alloca
> +   in the file alloca.s should be used.  */
> +
> +#define C_ALLOCA
> +#define HAVE_ALLOCA

There is no such change in the Emacs CVS trunk, at any version. We need a
rationale for adding this change, please. And if it is really necessary
we'd better talk to upstream first, wouldn't we?

> It also changes from references from /usr/lib64 to /usr/lib,
> which is also a good thing.

Where and how exactly? I can't see.

> If you could please use that patch.

Yes, as soon as we have dealt with those issues.

Cheers,

-- 
Jérôme Marant

Message #93 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Jérôme Marant <jerome.marant@free.fr>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Sat, 29 Jan 2005 00:13:48 +0100

On Fri, Jan 28, 2005 at 10:00:45PM +0100, Jérôme Marant wrote:
> >
> > It seems to have 1 important change over the last amdx86-64.h you
> > send:
> >
> > +/* Define C_ALLOCA if this machine does not support a true alloca
> > +   and the one written in C should be used instead.
> > +   Define HAVE_ALLOCA to say that the system provides a properly
> > +   working alloca function and it should be used.
> > +   Define neither one if an assembler-language alloca
> > +   in the file alloca.s should be used.  */
> > +
> > +#define C_ALLOCA
> > +#define HAVE_ALLOCA
> 
> There is no such change in the Emacs CVS trunk, at any version. We need a
> rationale for adding this change, please. And if it is really necessary
> we'd better talk to upstream first, wouldn't we?

To me it looks like defining both is not the right thing and we
probably want HAVE_ALLOCA as used on most other arches it seems.

Defining HAVE_ALLOCA seems to prevent using alloca.s.

If you're not using that, you get that build failure Goswin send
the log off that looked like this:
O|195.92|x86_64-linux-gcc -c allocax.s
E|195.92|allocax.s: Assembler messages:
E|195.92|allocax.s:1: Error: no such instruction: `typedef long unsigned int size_t'
[...]

With only HAVE_ALLOCA defined it builds fine, so I suggest you
add that and send it upstream.

> > It also changes from references from /usr/lib64 to /usr/lib,
> > which is also a good thing.
> 
> Where and how exactly? I can't see.

@@ -115,7 +126,7 @@
 #undef START_FILES
-#define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o
+#define START_FILES pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o

 #undef LIB_STANDARD
-#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o
+#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib/crtn.o

/usr/lib64 is where those files are installed on most amd64
systems.  In debian they're really installed in /usr/lib and we
currently have a symlink from /usr/lib64 to /usr/lib.  So basicly
it'll work either way and that's not a change you should send
upstream.

This is all going to change one day when we introduce multiarch
in which case such hardcoded paths will fail since we'll moving
most things from /usr/lib and /usr/lib64 to somewhere else.


Kurt

Message #98 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Frederik Schueler <fs@lowpingbastards.de>

To: jerome.marant@free.fr

Cc: Frederik Schueler <fs@lowpingbastards.de>, 248796@bugs.debian.org

Subject: Re: Bug#248796: status of this bug?

Date: Sat, 29 Jan 2005 00:25:41 +0100

[Message part 1 (text/plain, inline)]

Hello,

On Fri, Jan 28, 2005 at 05:05:44PM +0100, Jérôme Marant wrote:
> > The bug is open since 260 days now.
> 
> Yes, but amd64 is not an official Debian port yet (and sarge is not
> released for amd64), so it has always been in the lowest priorities.

Thats true. Sadly we won't support amd64 in sarge, although the port
matured over the last 9 months and has become pretty stable. The
argument to not include it 6 months ago was the imminent release of 
sarge, but this is another story.

I fully understand how you prioritize your work, and I dont argue
against it. It would even be absolutely legitimate to tag this bug 
wontfix unless pure64 enters sid and becomes a release candidate.

It is just bothersome for the amd64 porting team to always have to patch
emacs21 on every new release. Fortunately you don't release as often as
the zsh-beta package ;-)

Well, I just wanted to ask, since the last activity on this bug is from
some months ago. If you could apply the patch before the next upload,
you would make a lot of people happy ;)

Kind regards
Frederik Schueler

-- 
ENOSIG

[signature.asc (application/pgp-signature, inline)]

Message #103 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: Frederik Schueler <fs@lowpingbastards.de>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: status of this bug?

Date: Sat, 29 Jan 2005 14:12:18 +0100

Frederik Schueler <fs@lowpingbastards.de> writes:

> Hello,
>
> what is the state of the emacs21 amd64 build patch? 
>
> may I politely ask why it is still not included in the source package?

The CVS is fixed but differently from what I hacked together.

The maintainer did send a backport patch from CVS but that didn't
compile.

So, this could need another look at the cvs and another try to extract
the right changes for this.

> we have at least 10 packages FTBFS because of this currently, among them
> important packages like auctex and python2.3.
>
> The bug is open since 260 days now.
>
> Kind regards
> Frederik Schueler
>
> -- 
> ENOSIG

MfG
        Goswin

Message #108 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: 248796@bugs.debian.org

Subject: Re: emacs21: FTBFS amd64: machine description missing

Date: Thu, 3 Mar 2005 00:03:49 +0100

Hi,

Is there any progress on this?  Did you send that patch to define
HAVE_ALLOCA upstream?  I really think that that is all that is
missing to get a working version.


Kurt

Message #113 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jmarant@free.fr>

To: Kurt Roeckx <kurt@roeckx.be>, 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Thu, 3 Mar 2005 10:54:43 +0100

Quoting Kurt Roeckx <kurt@roeckx.be>:

> Hi,
>
> Is there any progress on this?  Did you send that patch to define
> HAVE_ALLOCA upstream?  I really think that that is all that is
> missing to get a working version.

Upstream didn't reply. There is no such HAVE_ALLOCA in the upstream
code for amd64, because it seems to be autodetected by the configure
script.
I'd really like to know why it seems to work upstream and no on
Debian system. Would you please investigate?

--
Jérôme Marant

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Message #118 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: jerome.marant@free.fr

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: emacs21: FTBFS amd64: machine description missing

Date: Thu, 3 Mar 2005 21:16:25 +0100

On Thu, Mar 03, 2005 at 10:54:43AM +0100, Jérôme Marant wrote:
> Quoting Kurt Roeckx <kurt@roeckx.be>:
> 
> >Hi,
> >
> >Is there any progress on this?  Did you send that patch to define
> >HAVE_ALLOCA upstream?  I really think that that is all that is
> >missing to get a working version.
> 
> Upstream didn't reply. There is no such HAVE_ALLOCA in the upstream
> code for amd64, because it seems to be autodetected by the configure
> script.
> I'd really like to know why it seems to work upstream and no on
> Debian system. Would you please investigate?

During configure, I see this:
checking for alloca... yes

I also find those:
./mac/inc/config.h:/* #undef HAVE_ALLOCA_H */
./debian/build-x/src/config.h:#define HAVE_ALLOCA_H 1
./debian/build-nox/src/config.h:#define HAVE_ALLOCA_H 1

I added this line to src/config.in:
#undef HAVE_ALLOCA

And it build perfectly then.

I suggest adding C_ALLOCA there too since the autoconf macro
AC_FUNC_ALLOCA can set both.

I have no idea what upstream changed since the version in debian,
they might have put that in src/config.in too and removed the
defines from all other places.

I think the easier solution is just to define it in
./src/m/amdx86-64.h for now.


Kurt

Message #125 received at 248796@bugs.debian.org (full text, mbox, reply):

From: Jérôme Marant <jerome.marant@free.fr>

To: Frederik Schueler <fs@lowpingbastards.de>

Cc: 248796@bugs.debian.org

Subject: Re: Bug#248796: status of this bug?

Date: Sat, 12 Mar 2005 17:41:42 +0100

Frederik Schueler <fs@lowpingbastards.de> writes:

> Hello,
>
> On Fri, Jan 28, 2005 at 05:05:44PM +0100, Jérôme Marant wrote:
>> > The bug is open since 260 days now.
>> 
>> Yes, but amd64 is not an official Debian port yet (and sarge is not
>> released for amd64), so it has always been in the lowest priorities.
>
> Thats true. Sadly we won't support amd64 in sarge, although the port
> matured over the last 9 months and has become pretty stable. The
> argument to not include it 6 months ago was the imminent release of 
> sarge, but this is another story.

The AMD64 support will appear in the upcoming package.

Cheers,

-- 
Jérôme Marant

Message #130 received at 248796-close@bugs.debian.org (full text, mbox, reply):

From: Rob Browning <rlb@defaultvalue.org>

To: 248796-close@bugs.debian.org

Subject: Bug#248796: fixed in emacs21 21.4a-1

Date: Thu, 17 Mar 2005 20:47:24 -0500

Source: emacs21
Source-Version: 21.4a-1

We believe that the bug you reported is fixed in the latest version of
emacs21, which is due to be installed in the Debian FTP archive:

emacs21-bin-common_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21-bin-common_21.4a-1_i386.deb
emacs21-common_21.4a-1_all.deb
  to pool/main/e/emacs21/emacs21-common_21.4a-1_all.deb
emacs21-el_21.4a-1_all.deb
  to pool/main/e/emacs21/emacs21-el_21.4a-1_all.deb
emacs21-nox_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21-nox_21.4a-1_i386.deb
emacs21_21.4a-1.diff.gz
  to pool/main/e/emacs21/emacs21_21.4a-1.diff.gz
emacs21_21.4a-1.dsc
  to pool/main/e/emacs21/emacs21_21.4a-1.dsc
emacs21_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21_21.4a-1_i386.deb
emacs21_21.4a.orig.tar.gz
  to pool/main/e/emacs21/emacs21_21.4a.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 248796@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rob Browning <rlb@defaultvalue.org> (supplier of updated emacs21 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 15 Mar 2005 11:00:04 -0600
Source: emacs21
Binary: emacs21-el emacs21-common emacs21-nox emacs21-bin-common emacs21
Architecture: source all i386
Version: 21.4a-1
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning <rlb@defaultvalue.org>
Changed-By: Rob Browning <rlb@defaultvalue.org>
Description: 
 emacs21    - The GNU Emacs editor
 emacs21-bin-common - The GNU Emacs editor's shared, architecture dependent files
 emacs21-common - The GNU Emacs editor's shared, architecture independent infrastru
 emacs21-el - GNU Emacs LISP (.el) files
 emacs21-nox - The GNU Emacs editor (without X support)
Closes: 248796 291221 294313 296618 297796
Changes: 
 emacs21 (21.4a-1) unstable; urgency=medium
 .
   * New upstream release. (closes: #294313) [Jérôme Marant]
     - debian/patches/movemail-pop-fmt-vulnerability.dpatch: removed since
     it has been applied upstream.
 .
   * Apply patch from Romain Francoise <rfrancoise@debian.org> making PCL-CVS
     compliant with recent versions of CVS. (closes: #291221) [Jérôme Marant]
     - debian/patches/pcl-cvs-format.dpatch: new file.
     - debian/00list: updated.
     - debian/control: tightened dependency on dpatch (>= 2.0.9).
 .
   * Add MIME type to desktop file. (closes: #296618) [Jérôme Marant]
     - debian/emacs.desktop: added MimeType entry.
 .
   * Apply patch supporting the AMD64 architecture. This is a slightly
     modified patch derived from the Emacs CVS mainline. Thanks to
     Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> and
     amd64 porters. (closes: #248796) [Jérôme Marant]
     - debian/patches/arch-amd64.patch: new file.
     - debian/00list: updated.
 .
   * Hard code leim version in copyright.in for now.  with 21.4a the emacs
     tar.gz name changed, but the leim archive name didn't. [rlb]
     - debian/copyright.in
     - debian/copyright
 .
   * Remove prebuild target from debian/rules.  Instead, just issue
     instructions to the user. [rlb]
     - debian/rules
 .
   * Fix invocation of wc -l when counting fns-*.el files. [rlb]
     - debian/rules
 .
   * Use dpatch for the autotool related diff rather than generating and
     applying a diff manually.  What was the debian/autofiles.diff is now
     handled via debian/patches/autofiles.dpatch.  Also, we no longer try
     to automatically generate the diff when needed.  Instead, the diff
     must be generated manually via "debian/rules autofiles-sync".
 .
     The earlier approach was broken because dpatch files that
     autofiles.diff depended on could end up later in the Debian diff (and
     hence have newer timestamps).  This would cause an unexpected run of
     aclocal, etc.  and break the buildds.  If we ever want to re-automate
     generation of the autofiles diff, we'll need to use dpatch md5 sigs
     (or similar) rather than timestamps.  (closes: #297796) [rlb]
     - debian/autofiles.diff: removed
     - debian/patches/00list: added autofiles
     - debian/patches/autofiles.dpatch: new
     - debian/rules: updated
Files: 
 796e8a7c58901cc55ef59fb9b67be5e0 780 editors optional emacs21_21.4a-1.dsc
 0a85e242da6eb61f86fda5ad1c762d5a 18113820 editors optional emacs21_21.4a.orig.tar.gz
 7020902ea97ea293ed53e49424244a87 146923 editors optional emacs21_21.4a-1.diff.gz
 3f3112ecbe0b262cb2c58bb23abacf75 7151284 editors optional emacs21-el_21.4a-1_all.deb
 7ab522a59888ac2f9f4951fd7257f187 10985754 editors optional emacs21-common_21.4a-1_all.deb
 2fb490567c42431d219c611e237d4ad9 1812090 editors optional emacs21-nox_21.4a-1_i386.deb
 2989d60960cf2e5bab2be0d67e13eaee 2004584 editors optional emacs21_21.4a-1_i386.deb
 aafd91755d877f959fb4b82ff7139cac 134826 editors optional emacs21-bin-common_21.4a-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCOi7tJcjTd4x+c6QRAhTnAJ9BaJATrEcSZhghAQOo0ZZTkrPKFwCgsV6J
QaZehVUHpfHtzEiU9hLlpuo=
=jTlR
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.