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
