* bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc.
@ 2010-02-28 4:30 Nathan Phillip Brink
2010-03-01 23:22 ` bug#5655: crt*.o Nathan Phillip Brink
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Nathan Phillip Brink @ 2010-02-28 4:30 UTC (permalink / raw
To: 5655
https://bugs.gentoo.org/306831
Attempting to build a copy of emacs utilizing the 32-bit ABI available on an amd64 system revealed that emacs has hard-coded paths to files such as crt1.o, crtn.o, etc. in its Makefile.ins. This is also a problem when trying to build emacs on freebsd systems.
It would seem to me that an application shouldn't need to link directly against crt*.o. It appears to make the buildsystem quite implementation specific, for example.
Perhaps it would be good enough if emacs's autoconf scripts were able to divine the proper location for these crt files. You can see an example of how gentoo's emacs ebuild fixes this for freebsd people at http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-editors/emacs/emacs-23.1-r2.ebuild?view=markup (see the src_prepare() function and the crtbegin.o and crtend.o stuff.)
In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.14.7)
of 2009-08-24 on ohnopublishing.net
configured using `configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23' '--with-sound' '--with-x' '--without-toolkit-scroll-bars' '--without-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--without-xft' '--without-libotf' '--without-m17n-flt' '--with-x-toolkit=gtk' '--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-gpm' '--with-dbus' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-O2 -pipe -march=athlon64 -g -ggdb' 'LDFLAGS=-Wl,--as-needed -Wl,-O1 -Wl,-t -Wl,--enable-new-dtags -Wl,--
hash-style=both''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
dired-omit-mode: t
display-time-mode: t
server-mode: t
global-cwarn-mode: t
diff-auto-refine-mode: t
tooltip-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
ESC [ 3 ~ ESC [ 3 ~ C-x C-s C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f RET ESC [ 3 ~ ESC [ 4 ~ ESC [ 3
~ ESC [ 4 ~ ESC [ 1 ~ C-f C-f C-f C-f C-f C-f C-f C-f
C-f SPC ESC [ 4 ~ C-b C-x C-s C-b C-b C-b C-b C-b C-b
C-b C-b C-b C-b C-b ESC [ 4 ~ C-b SPC w h i c h SPC
d C-b ESC [ 3 ~ C-b C-b C-b C-b C-b C-b C-b C-b C-b
C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b
C-b C-b ESC [ 4 ~ C-b C-b C-b C-b C-b C-b C-b ESC [
3 ~ ESC [ 3 ~ ESC [ 3 ~ ESC [ 3 ~ ESC [ 3 ~ u s i n
g SPC d y n a m i c SPC l i n k i n g C-x C-s ESC [
3 ~ C-p C-p ESC [ 3 ~ SPC C-f C-f RET ESC [ 3 ~ ESC
[ 4 ~ C-n C-b RET ESC [ 3 ~ C-x C-s C-n C-n C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-x C-s C-x 5 0 ESC x r e p TAB
o TAB r TAB RET
Recent messages:
Saving file /home/ohnobinki/ohnobinki_overlay/sys-devel/libtool/files/2.2.6b/libtool-2.2.6b-ltdl.m4-no-la.patch...
Wrote /home/ohnobinki/ohnobinki_overlay/sys-devel/libtool/files/2.2.6b/libtool-2.2.6b-ltdl.m4-no-la.patch
Saving file /home/ohnobinki/ohnobinki_overlay/sys-devel/libtool/files/2.2.6b/libtool-2.2.6b-ltdl.m4-no-la.patch...
Wrote /home/ohnobinki/ohnobinki_overlay/sys-devel/libtool/files/2.2.6b/libtool-2.2.6b-ltdl.m4-no-la.patch
Saving file /home/ohnobinki/ohnobinki_overlay/sys-devel/libtool/files/2.2.6b/libtool-2.2.6b-ltdl.m4-no-la.patch...
Wrote /home/ohnobinki/ohnobinki_overlay/sys-devel/libtool/files/2.2.6b/libtool-2.2.6b-ltdl.m4-no-la.patch
(No changes need to be saved)
When done with this frame, type M-x delete-frame
Making completion list... [2 times]
call-interactively: End of buffer [3 times]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: crt*.o
2010-02-28 4:30 bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc Nathan Phillip Brink
@ 2010-03-01 23:22 ` Nathan Phillip Brink
2010-04-24 2:24 ` bug#5655: incorrect paths for crt1.o, crtn.o, etc Glenn Morris
` (2 subsequent siblings)
3 siblings, 0 replies; 24+ messages in thread
From: Nathan Phillip Brink @ 2010-03-01 23:22 UTC (permalink / raw
To: 5655
On the Gentoo bug, I was notified that the gcc -print-file-name is a hack which shouldn't be used by you. Rather, emacs needs to have provision for locating crt*.o in a different directory than /usr/lib. I suppose that the best thing for starters would be a --with-crt-path ./configure option so that the user may specify his system's libdir (/usr/lib64 and /usr/lib32, in my case).
--
ohnobinki
Look out for missing apostrophes!
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-02-28 4:30 bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc Nathan Phillip Brink
2010-03-01 23:22 ` bug#5655: crt*.o Nathan Phillip Brink
@ 2010-04-24 2:24 ` Glenn Morris
2010-04-24 19:26 ` Dan Nicolaescu
2010-04-26 16:36 ` Glenn Morris
2010-04-27 3:18 ` Glenn Morris
3 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-24 2:24 UTC (permalink / raw
To: 5655-done
I have added a --with-crt-dir configure option to the trunk.
(It is only used by amdx86-64 and ibms390x GNU/Linux builds.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-24 2:24 ` bug#5655: incorrect paths for crt1.o, crtn.o, etc Glenn Morris
@ 2010-04-24 19:26 ` Dan Nicolaescu
2010-04-24 19:51 ` Glenn Morris
0 siblings, 1 reply; 24+ messages in thread
From: Dan Nicolaescu @ 2010-04-24 19:26 UTC (permalink / raw
To: 5655
Glenn Morris <rgm@gnu.org> writes:
> I have added a --with-crt-dir configure option to the trunk.
> (It is only used by amdx86-64 and ibms390x GNU/Linux builds.)
It looks like the FreeBSD code in amdx86-64.h is now the same as the #else code.
Can they be unified?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-24 19:26 ` Dan Nicolaescu
@ 2010-04-24 19:51 ` Glenn Morris
2010-04-25 21:19 ` Dan Nicolaescu
0 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-24 19:51 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5655
Dan Nicolaescu wrote:
> It looks like the FreeBSD code in amdx86-64.h is now the same as the
> #else code. Can they be unified?
Yes, I think you are right, well spotted. I did so.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-24 19:51 ` Glenn Morris
@ 2010-04-25 21:19 ` Dan Nicolaescu
0 siblings, 0 replies; 24+ messages in thread
From: Dan Nicolaescu @ 2010-04-25 21:19 UTC (permalink / raw
To: Glenn Morris; +Cc: 5655
Glenn Morris <rgm@gnu.org> writes:
> Dan Nicolaescu wrote:
>
>> It looks like the FreeBSD code in amdx86-64.h is now the same as the
>> #else code. Can they be unified?
>
> Yes, I think you are right, well spotted. I did so.
Thanks
One more thing: can src/s/gnu-linux.h be changed to use $(CRT_DIR),
that would avoid the need to special case GNU_LINUX in the src/m/* files...
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-02-28 4:30 bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc Nathan Phillip Brink
2010-03-01 23:22 ` bug#5655: crt*.o Nathan Phillip Brink
2010-04-24 2:24 ` bug#5655: incorrect paths for crt1.o, crtn.o, etc Glenn Morris
@ 2010-04-26 16:36 ` Glenn Morris
2010-04-26 17:16 ` Andreas Schwab
2010-04-26 17:33 ` Dan Nicolaescu
2010-04-27 3:18 ` Glenn Morris
3 siblings, 2 replies; 24+ messages in thread
From: Glenn Morris @ 2010-04-26 16:36 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5655
Dan Nicolaescu wrote:
> One more thing: can src/s/gnu-linux.h be changed to use $(CRT_DIR),
> that would avoid the need to special case GNU_LINUX in the src/m/* files...
Sorry, I don't understand the proposal; but CRT_DIR == /usr/lib in the
majority of cases. It can only be different on x86_64-*-linux-gnu* or
s390x-*-linux-gnu* systems. So you should feel free to replace
/usr/lib by $CRT_DIR anywhere else basically.
It would be nice to move all the crt*.o logic entirely to configure
(and so make the --with-crt-dir option work the same on all
platforms), but I don't know how to replicate the logic of m/sparc.h
and m/macppc.h in configure.in.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-26 16:36 ` Glenn Morris
@ 2010-04-26 17:16 ` Andreas Schwab
2010-04-26 17:26 ` Glenn Morris
2010-04-26 17:33 ` Dan Nicolaescu
1 sibling, 1 reply; 24+ messages in thread
From: Andreas Schwab @ 2010-04-26 17:16 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
Glenn Morris <rgm@gnu.org> writes:
> Sorry, I don't understand the proposal; but CRT_DIR == /usr/lib in the
> majority of cases. It can only be different on x86_64-*-linux-gnu* or
> s390x-*-linux-gnu* systems.
Or sparc64-* or ppc64-*.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-26 17:16 ` Andreas Schwab
@ 2010-04-26 17:26 ` Glenn Morris
2010-04-26 17:33 ` Andreas Schwab
0 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-26 17:26 UTC (permalink / raw
To: Andreas Schwab; +Cc: Dan Nicolaescu, 5655
Andreas Schwab wrote:
>> Sorry, I don't understand the proposal; but CRT_DIR == /usr/lib in the
>> majority of cases. It can only be different on x86_64-*-linux-gnu* or
>> s390x-*-linux-gnu* systems.
>
> Or sparc64-* or ppc64-*.
How can CRT_DIR be different from /usr/lib on these systems, given the
test of $canonical configure does?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-26 16:36 ` Glenn Morris
2010-04-26 17:16 ` Andreas Schwab
@ 2010-04-26 17:33 ` Dan Nicolaescu
1 sibling, 0 replies; 24+ messages in thread
From: Dan Nicolaescu @ 2010-04-26 17:33 UTC (permalink / raw
To: Glenn Morris; +Cc: 5655
Glenn Morris <rgm@gnu.org> writes:
> Dan Nicolaescu wrote:
>
>> One more thing: can src/s/gnu-linux.h be changed to use $(CRT_DIR),
>> that would avoid the need to special case GNU_LINUX in the src/m/* files...
>
> Sorry, I don't understand the proposal; but CRT_DIR == /usr/lib in the
> majority of cases. It can only be different on x86_64-*-linux-gnu* or
> s390x-*-linux-gnu* systems. So you should feel free to replace
> /usr/lib by $CRT_DIR anywhere else basically.
What I am saying is that if
src/s/gnu-linux.h
would use $(CRT_DIR)
then src/m/amdx86-64.h would not need special casing for GNU_LINUX.
> It would be nice to move all the crt*.o logic entirely to configure
> (and so make the --with-crt-dir option work the same on all
> platforms), but I don't know how to replicate the logic of m/sparc.h
> and m/macppc.h in configure.in.
${canonical} should be sparc64-* for the 64 bit case, versul sparc-* for the 32 bit one.
Same for powerpc.
Alternatively, less clean, but maybe easier to do: the same trick used for
c_switch_machine could be used for LIB_STANDARD/START_FILES.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-26 17:26 ` Glenn Morris
@ 2010-04-26 17:33 ` Andreas Schwab
0 siblings, 0 replies; 24+ messages in thread
From: Andreas Schwab @ 2010-04-26 17:33 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
Glenn Morris <rgm@gnu.org> writes:
> Andreas Schwab wrote:
>
>>> Sorry, I don't understand the proposal; but CRT_DIR == /usr/lib in the
>>> majority of cases. It can only be different on x86_64-*-linux-gnu* or
>>> s390x-*-linux-gnu* systems.
>>
>> Or sparc64-* or ppc64-*.
>
> How can CRT_DIR be different from /usr/lib on these systems, given the
> test of $canonical configure does?
Not CRT_DIR, but the location of crt0.o. Sorry for being unclear.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-02-28 4:30 bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc Nathan Phillip Brink
` (2 preceding siblings ...)
2010-04-26 16:36 ` Glenn Morris
@ 2010-04-27 3:18 ` Glenn Morris
2010-04-27 6:31 ` Sven Joachim
3 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-27 3:18 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5655
Dan Nicolaescu wrote:
> src/s/gnu-linux.h
> would use $(CRT_DIR)
> then src/m/amdx86-64.h would not need special casing for GNU_LINUX.
[...]
> ${canonical} should be sparc64-* for the 64 bit case, versul sparc-*
> for the 32 bit one. Same for powerpc.
See the latest version, it certainly looks much simpler now. I hope I
understood all this correctly and haven't broken anything; especially
the else branch of src/m/amdx86-64.h.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 3:18 ` Glenn Morris
@ 2010-04-27 6:31 ` Sven Joachim
2010-04-27 6:51 ` Glenn Morris
0 siblings, 1 reply; 24+ messages in thread
From: Sven Joachim @ 2010-04-27 6:31 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
On 2010-04-27 05:18 +0200, Glenn Morris wrote:
> Dan Nicolaescu wrote:
>
>> src/s/gnu-linux.h
>> would use $(CRT_DIR)
>> then src/m/amdx86-64.h would not need special casing for GNU_LINUX.
> [...]
>> ${canonical} should be sparc64-* for the 64 bit case, versul sparc-*
>> for the 32 bit one. Same for powerpc.
>
> See the latest version, it certainly looks much simpler now. I hope I
> understood all this correctly and haven't broken anything; especially
> the else branch of src/m/amdx86-64.h.
Alas, my combination of a 64-bit kernel and 32-bit userland on x86 is
broken now:
,----
| % /.configure && make
| [...]
| /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib64/crt1.o' is incompatible with i386 output
| /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib64/crti.o' is incompatible with i386 output
| /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib64/crtn.o' is incompatible with i386 output
| /usr/bin/ld: final link failed: Invalid operation
| collect2: ld returned 1 exit status
| make[1]: *** [temacs] Error 1
`----
Sven
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 6:31 ` Sven Joachim
@ 2010-04-27 6:51 ` Glenn Morris
2010-04-27 7:04 ` Glenn Morris
0 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-27 6:51 UTC (permalink / raw
To: Sven Joachim; +Cc: Dan Nicolaescu, 5655
Sven Joachim wrote:
> Alas, my combination of a 64-bit kernel and 32-bit userland on x86 is
> broken now:
>
> ,----
> | % /.configure && make
> | [...]
> | /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib64/crt1.o' is incompatible with i386 output
Sorry about that. Can you try to debug it? It's not obvious to me why
that should happen. What is $canonical on your system?
(In the meantime, you can work round it by passing --with-crt-dir=usr/lib )
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 6:51 ` Glenn Morris
@ 2010-04-27 7:04 ` Glenn Morris
2010-04-27 7:11 ` Dan Nicolaescu
2010-04-27 7:25 ` Sven Joachim
0 siblings, 2 replies; 24+ messages in thread
From: Glenn Morris @ 2010-04-27 7:04 UTC (permalink / raw
To: Sven Joachim; +Cc: Dan Nicolaescu, 5655
Glenn Morris wrote:
> Sorry about that. Can you try to debug it? It's not obvious to me why
> that should happen. What is $canonical on your system?
I guess it is this comment in src/m/amdx86-64.h. It seems to me that
the right fix is to set $canonical correctly on such a system to
i386-*-linux-gnu* rather than x86_64-*-linux-gnu*.
/* Although we're running on an amd64 kernel, we're actually compiling for
the x86 architecture. The user should probably have provided an
explicit --build to `configure', but if everything else than the kernel
is running in i386 mode, then the bug is really ours: we should
have guessed better. */
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 7:04 ` Glenn Morris
@ 2010-04-27 7:11 ` Dan Nicolaescu
2010-04-27 7:49 ` Sven Joachim
2010-04-27 7:25 ` Sven Joachim
1 sibling, 1 reply; 24+ messages in thread
From: Dan Nicolaescu @ 2010-04-27 7:11 UTC (permalink / raw
To: Glenn Morris; +Cc: 5655, Sven Joachim
Glenn Morris <rgm@gnu.org> writes:
> Glenn Morris wrote:
>
>> Sorry about that. Can you try to debug it? It's not obvious to me why
>> that should happen. What is $canonical on your system?
>
> I guess it is this comment in src/m/amdx86-64.h. It seems to me that
> the right fix is to set $canonical correctly on such a system to
> i386-*-linux-gnu* rather than x86_64-*-linux-gnu*.
Agreed, IMHO this is an ugly hack.
Sven, what does
./config.guess
output on your machine?
It's doubtful that emacs is the only program that has to deal with
this situation, it would be interesting to know what the usual
practice is...
> /* Although we're running on an amd64 kernel, we're actually compiling for
> the x86 architecture. The user should probably have provided an
> explicit --build to `configure', but if everything else than the kernel
> is running in i386 mode, then the bug is really ours: we should
> have guessed better. */
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 7:04 ` Glenn Morris
2010-04-27 7:11 ` Dan Nicolaescu
@ 2010-04-27 7:25 ` Sven Joachim
2010-04-27 17:33 ` Glenn Morris
1 sibling, 1 reply; 24+ messages in thread
From: Sven Joachim @ 2010-04-27 7:25 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
On 2010-04-27 09:04 +0200, Glenn Morris wrote:
> Glenn Morris wrote:
>
>> Sorry about that. Can you try to debug it? It's not obvious to me why
>> that should happen. What is $canonical on your system?
x86_64-unknown-linux-gnu
> I guess it is this comment in src/m/amdx86-64.h. It seems to me that
> the right fix is to set $canonical correctly on such a system to
> i386-*-linux-gnu* rather than x86_64-*-linux-gnu*.
This is a general autoconf problem, it uses "uname -m" which does not
describe the system adequately.
> /* Although we're running on an amd64 kernel, we're actually compiling for
> the x86 architecture. The user should probably have provided an
> explicit --build to `configure', but if everything else than the kernel
> is running in i386 mode, then the bug is really ours: we should
> have guessed better. */
Well, "./configure --build=i486-pc-linux-gnu" works, I can live with
that for now.
Thanks for tackling this problem, previously it had not been possible to
build a 64-bit Emacs with CC="gcc -m64", but now it is (using various
--without-foo options because the only available 64-bit libraries are
libc and ncurses).
Sven
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 7:11 ` Dan Nicolaescu
@ 2010-04-27 7:49 ` Sven Joachim
0 siblings, 0 replies; 24+ messages in thread
From: Sven Joachim @ 2010-04-27 7:49 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5655
On 2010-04-27 09:11 +0200, Dan Nicolaescu wrote:
> Glenn Morris <rgm@gnu.org> writes:
>
>> I guess it is this comment in src/m/amdx86-64.h. It seems to me that
>> the right fix is to set $canonical correctly on such a system to
>> i386-*-linux-gnu* rather than x86_64-*-linux-gnu*.
>
> Agreed, IMHO this is an ugly hack.
>
> Sven, what does
> ./config.guess
> output on your machine?
x86_64-unknown-linux-gnu
> It's doubtful that emacs is the only program that has to deal with
> this situation, it would be interesting to know what the usual
> practice is...
My experience is that nobody really cares. Most programs build fine
despite the wrong guessed build system type, and for the ones that don't
you have to specify the --build option or run the whole build process
under linux32.
In Debian there is dpkg-architecture which prints correct values that
you can feed as --build and --host arguments, but I am not aware of a
general solution.
Sven
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 7:25 ` Sven Joachim
@ 2010-04-27 17:33 ` Glenn Morris
2010-04-27 19:27 ` Sven Joachim
0 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-27 17:33 UTC (permalink / raw
To: Sven Joachim; +Cc: Dan Nicolaescu, 5655
Sven Joachim wrote:
> Well, "./configure --build=i486-pc-linux-gnu" works, I can live with
> that for now.
I'm not sure if that isn't the right solution. It seems this is an old
autoconf issue, but I can't see that there is a standard solution. Eg
http://lists.gnu.org/archive/html/autoconf/2005-05/msg00004.html
The following patch might make things behave like they used to, could
you try it out? You will need to run autoconf.
*** configure.in 2010-04-27 08:09:01 +0000
--- configure.in 2010-04-27 17:22:23 +0000
***************
*** 761,766 ****
--- 761,776 ----
if test "x$RANLIB" = x; then
AC_PROG_RANLIB
fi
+
+ ## Although we're running on an amd64 kernel, we're actually compiling for
+ ## the x86 architecture. The user should probably have provided an
+ ## explicit --build to `configure', but if everything else than the kernel
+ ## is running in i386 mode, we can help them out.
+ if test "$machine" = "amdx86-64"; then
+ AC_CHECK_DECL([i386])
+ test "$ac_cv_have_decl_i386" = "yes" && machine=intel386
+ fi
+
AC_PATH_PROG(INSTALL_INFO, install-info)
AC_PATH_PROG(INSTALL_INFO, install-info,, /usr/sbin)
AC_PATH_PROG(INSTALL_INFO, install-info,:, /sbin)
*** src/m/amdx86-64.h 2010-04-27 03:14:14 +0000
--- src/m/amdx86-64.h 2010-04-27 17:27:11 +0000
***************
*** 17,31 ****
You should have received a copy of the GNU General Public License
along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */
- #ifdef i386
- /* Although we're running on an amd64 kernel, we're actually compiling for
- the x86 architecture. The user should probably have provided an
- explicit --build to `configure', but if everything else than the kernel
- is running in i386 mode, then the bug is really ours: we should have
- guessed better. */
- #include "m/intel386.h"
- #else
-
/* The following line tells the configuration script what sort of
operating system this machine is likely to run.
USUAL-OPSYS="linux" */
--- 17,22 ----
***************
*** 90,96 ****
#define LIB_STANDARD -lgcc -lc -lgcc $(CRT_DIR)/crtn.o
#endif /* SOLARIS2 */
- #endif /* !i386 */
/* arch-tag: 8a5e001d-e12e-4692-a3a6-0b15ba271c6e
(do not change this comment) */
--- 81,86 ----
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 17:33 ` Glenn Morris
@ 2010-04-27 19:27 ` Sven Joachim
2010-04-27 19:32 ` Glenn Morris
0 siblings, 1 reply; 24+ messages in thread
From: Sven Joachim @ 2010-04-27 19:27 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
On 2010-04-27 19:33 +0200, Glenn Morris wrote:
> The following patch might make things behave like they used to, could
> you try it out? You will need to run autoconf.
Does not seem to work at all.
>
> *** configure.in 2010-04-27 08:09:01 +0000
> --- configure.in 2010-04-27 17:22:23 +0000
> ***************
> *** 761,766 ****
> --- 761,776 ----
> if test "x$RANLIB" = x; then
> AC_PROG_RANLIB
> fi
> +
> + ## Although we're running on an amd64 kernel, we're actually compiling for
> + ## the x86 architecture. The user should probably have provided an
> + ## explicit --build to `configure', but if everything else than the kernel
> + ## is running in i386 mode, we can help them out.
> + if test "$machine" = "amdx86-64"; then
> + AC_CHECK_DECL([i386])
> + test "$ac_cv_have_decl_i386" = "yes" && machine=intel386
> + fi
> +
> AC_PATH_PROG(INSTALL_INFO, install-info)
> AC_PATH_PROG(INSTALL_INFO, install-info,, /usr/sbin)
> AC_PATH_PROG(INSTALL_INFO, install-info,:, /sbin)
Okay, configure picks this up:
checking whether i386 is declared... yes
> *** src/m/amdx86-64.h 2010-04-27 03:14:14 +0000
> --- src/m/amdx86-64.h 2010-04-27 17:27:11 +0000
> ***************
> *** 17,31 ****
> You should have received a copy of the GNU General Public License
> along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */
>
> - #ifdef i386
> - /* Although we're running on an amd64 kernel, we're actually compiling for
> - the x86 architecture. The user should probably have provided an
> - explicit --build to `configure', but if everything else than the kernel
> - is running in i386 mode, then the bug is really ours: we should have
> - guessed better. */
> - #include "m/intel386.h"
> - #else
> -
> /* The following line tells the configuration script what sort of
> operating system this machine is likely to run.
> USUAL-OPSYS="linux" */
> --- 17,22 ----
> ***************
> *** 90,96 ****
> #define LIB_STANDARD -lgcc -lc -lgcc $(CRT_DIR)/crtn.o
>
> #endif /* SOLARIS2 */
> - #endif /* !i386 */
>
> /* arch-tag: 8a5e001d-e12e-4692-a3a6-0b15ba271c6e
> (do not change this comment) */
> --- 81,86 ----
This part does not apply cleanly, and after I removed the corresponding lines
manually things broke badly because BITS_PER_LONG got #defined to 64 etc.
Sven
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 19:27 ` Sven Joachim
@ 2010-04-27 19:32 ` Glenn Morris
2010-04-27 19:59 ` Sven Joachim
0 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-27 19:32 UTC (permalink / raw
To: Sven Joachim; +Cc: Dan Nicolaescu, 5655
Sven Joachim wrote:
> Does not seem to work at all.
Sorry, the configure.in part was missing a line (machfile):
*** configure.in 2010-04-27 08:09:01 +0000
--- configure.in 2010-04-27 19:29:48 +0000
***************
*** 761,766 ****
--- 761,779 ----
if test "x$RANLIB" = x; then
AC_PROG_RANLIB
fi
+
+ ## Although we're running on an amd64 kernel, we're actually compiling for
+ ## the x86 architecture. The user should probably have provided an
+ ## explicit --build to `configure', but if everything else than the kernel
+ ## is running in i386 mode, we can help them out.
+ if test "$machine" = "amdx86-64"; then
+ AC_CHECK_DECL([i386])
+ if test "$ac_cv_have_decl_i386" = "yes"; then
+ machine=intel386
+ machfile="m/${machine}.h"
+ fi
+ fi
+
AC_PATH_PROG(INSTALL_INFO, install-info)
AC_PATH_PROG(INSTALL_INFO, install-info,, /usr/sbin)
AC_PATH_PROG(INSTALL_INFO, install-info,:, /sbin)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 19:32 ` Glenn Morris
@ 2010-04-27 19:59 ` Sven Joachim
2010-04-27 20:17 ` Glenn Morris
0 siblings, 1 reply; 24+ messages in thread
From: Sven Joachim @ 2010-04-27 19:59 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
On 2010-04-27 21:32 +0200, Glenn Morris wrote:
> Sorry, the configure.in part was missing a line (machfile):
That's better, but unfortunately it does not fix the problem described
in <87iq7dcsp6.fsf@turtle.gmx.de>.
Sven
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 19:59 ` Sven Joachim
@ 2010-04-27 20:17 ` Glenn Morris
2010-04-28 5:49 ` Sven Joachim
0 siblings, 1 reply; 24+ messages in thread
From: Glenn Morris @ 2010-04-27 20:17 UTC (permalink / raw
To: Sven Joachim; +Cc: Dan Nicolaescu, 5655
Sven Joachim wrote:
> That's better, but unfortunately it does not fix the problem described
> in <87iq7dcsp6.fsf@turtle.gmx.de>.
Painfully inching towards a solution.
*** configure.in 2010-04-27 08:09:01 +0000
--- configure.in 2010-04-27 20:14:42 +0000
***************
*** 761,766 ****
--- 761,780 ----
if test "x$RANLIB" = x; then
AC_PROG_RANLIB
fi
+
+ ## Although we're running on an amd64 kernel, we're actually compiling for
+ ## the x86 architecture. The user should probably have provided an
+ ## explicit --build to `configure', but if everything else than the kernel
+ ## is running in i386 mode, we can help them out.
+ if test "$machine" = "amdx86-64"; then
+ AC_CHECK_DECL([i386])
+ if test "$ac_cv_have_decl_i386" = "yes"; then
+ canonical=`echo "$canonical" | sed -e 's/^amd64/i386/' -e 's/^x86_64/i386/'`
+ machine=intel386
+ machfile="m/${machine}.h"
+ fi
+ fi
+
AC_PATH_PROG(INSTALL_INFO, install-info)
AC_PATH_PROG(INSTALL_INFO, install-info,, /usr/sbin)
AC_PATH_PROG(INSTALL_INFO, install-info,:, /sbin)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#5655: incorrect paths for crt1.o, crtn.o, etc.
2010-04-27 20:17 ` Glenn Morris
@ 2010-04-28 5:49 ` Sven Joachim
0 siblings, 0 replies; 24+ messages in thread
From: Sven Joachim @ 2010-04-28 5:49 UTC (permalink / raw
To: Glenn Morris; +Cc: Dan Nicolaescu, 5655
On 2010-04-27 22:17 +0200, Glenn Morris wrote:
> Painfully inching towards a solution.
>
> *** configure.in 2010-04-27 08:09:01 +0000
> --- configure.in 2010-04-27 20:14:42 +0000
> ***************
> *** 761,766 ****
> --- 761,780 ----
> if test "x$RANLIB" = x; then
> AC_PROG_RANLIB
> fi
> +
> + ## Although we're running on an amd64 kernel, we're actually compiling for
> + ## the x86 architecture. The user should probably have provided an
> + ## explicit --build to `configure', but if everything else than the kernel
> + ## is running in i386 mode, we can help them out.
> + if test "$machine" = "amdx86-64"; then
> + AC_CHECK_DECL([i386])
> + if test "$ac_cv_have_decl_i386" = "yes"; then
> + canonical=`echo "$canonical" | sed -e 's/^amd64/i386/' -e 's/^x86_64/i386/'`
> + machine=intel386
> + machfile="m/${machine}.h"
> + fi
> + fi
> +
> AC_PATH_PROG(INSTALL_INFO, install-info)
> AC_PATH_PROG(INSTALL_INFO, install-info,, /usr/sbin)
> AC_PATH_PROG(INSTALL_INFO, install-info,:, /sbin)
Thanks, this works.
Sven
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-04-28 5:49 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-28 4:30 bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc Nathan Phillip Brink
2010-03-01 23:22 ` bug#5655: crt*.o Nathan Phillip Brink
2010-04-24 2:24 ` bug#5655: incorrect paths for crt1.o, crtn.o, etc Glenn Morris
2010-04-24 19:26 ` Dan Nicolaescu
2010-04-24 19:51 ` Glenn Morris
2010-04-25 21:19 ` Dan Nicolaescu
2010-04-26 16:36 ` Glenn Morris
2010-04-26 17:16 ` Andreas Schwab
2010-04-26 17:26 ` Glenn Morris
2010-04-26 17:33 ` Andreas Schwab
2010-04-26 17:33 ` Dan Nicolaescu
2010-04-27 3:18 ` Glenn Morris
2010-04-27 6:31 ` Sven Joachim
2010-04-27 6:51 ` Glenn Morris
2010-04-27 7:04 ` Glenn Morris
2010-04-27 7:11 ` Dan Nicolaescu
2010-04-27 7:49 ` Sven Joachim
2010-04-27 7:25 ` Sven Joachim
2010-04-27 17:33 ` Glenn Morris
2010-04-27 19:27 ` Sven Joachim
2010-04-27 19:32 ` Glenn Morris
2010-04-27 19:59 ` Sven Joachim
2010-04-27 20:17 ` Glenn Morris
2010-04-28 5:49 ` Sven Joachim
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.