bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc.

bug#5655: 23.1; incorrect paths for crt1.o, crtn.o, etc.

[Nathan Phillip Brink]

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]

bug#5655: crt*.o

[Nathan Phillip Brink]

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!

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

I have added a --with-crt-dir configure option to the trunk.
(It is only used by amdx86-64 and ibms390x GNU/Linux builds.)

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Dan Nicolaescu]

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?

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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.

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Dan Nicolaescu]

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...

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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.

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Andreas Schwab]

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."

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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?

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Andreas Schwab]

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."

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Dan Nicolaescu]

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.

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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.

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Sven Joachim]

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

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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 )

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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.  */

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Dan Nicolaescu]

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.  */

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Sven Joachim]

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

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Sven Joachim]

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

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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 ----

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Sven Joachim]

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

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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)

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Sven Joachim]

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

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Glenn Morris]

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)

bug#5655: incorrect paths for crt1.o, crtn.o, etc.

[Sven Joachim]

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