bug#10896: 23.4; --with-crt-dir was required since crt1.0 not found (on *32bit* system)

bug#10896: 23.4; --with-crt-dir was required since crt1.0 not found (on *32bit* system)

[ishikawa]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your report will be posted to the bug-gnu-emacs@gnu.org mailing list
and the gnu.emacs.bug news group, and at http://debbugs.gnu.org.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

Compilation failed unless --with-crt-dir was specified during configure on a
32 bit system.

downloaded 23.4 and ran configure as below:
./configure --with-x-toolkit=gtk --without-xim

But then during the subsequent make
it failed due to the dependency on /usr/lib/crt1.0 to make temacs.

Upon investigation, the make variable CRT_DIR is set to /usr/lib
in src/Makefile.
And despite the comment that it is used only on amdx86-64 and ibms390x,
somehow it is being used on this 32-bit Debian system.

Quote from src/Makefile:
# Only used by amdx86-64 and ibms390x GNU/Linux.
CRT_DIR=/usr/lib

It is used in STARTFILES which is referenced as target of temacs
STARTFILES = pre-crt0.o $(CRT_DIR)/crt1.o $(CRT_DIR)/crti.o

crt1.0 is not under /usr/lib on my system. I had to search for it myself.
So I bit the bullet and specified --with-crt-dir in configure line as
below. And the compilation succeeded.

./configure --with-x-toolkit=gtk --without-xim
--with-crt-dir=/usr/lib/i386-linux-gnu

However, something is fishy here. Since
this is NOT a 64 bit system, and not ibms390, CRT_DIR should not be used if
I believe the comment in src/Makefile.
In my use of emacs for more than 20 years, I don't think I ever needed
to specify this CRT_DIR via --with-crt-dir on a popular target.
Maybe the logic to set CRT_DIR is a little broken here?
(Or maybe Debian users are very small or that the users of Debian who
compiles his/her emacs are rarity these days.)

FYI, uname -a prints out the following:
Linux debian-vbox-ci 2.6.39-2-686-pae #1 SMP Tue Jul 5 03:48:49 UTC 2011
i686 GNU/Linux

TIA

Chiaki Ishikawa


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/local/share/emacs/23.4/etc/DEBUG.


In GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9)
 of 2012-02-27 on debian-vbox-ci
Windowing system distributor `The X.Org Foundation', version 11.0.11103901
configured using `configure  '--with-x-toolkit=gtk' '--without-xim'
'--with-crt-dir=/usr/lib/i386-linux-gnu''

Important settings:
  value of $LC_ALL: ja_JP.ujis
  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: ja_JP.UTF-8
  value of $XMODIFIERS: @im=kinput2
  locale-coding-system: japanese-iso-8bit-unix
  default enable-multibyte-characters: t

Major mode: Apropos

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f C-g <escape> x m a n <return> e m a c s b u
g s <return> <escape> x e m a c s b u <tab> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> r e p o r t b u <tab> <backspace> C-g C-h
v C-g C-h a b u g <return> C-x o C-v C-v C-v <escape>
x r e p o r t - e m a c s - b u g <return>

Recent messages:
before font setup
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Invoking man emacsbugs in the background
Please wait: formatting the emacsbugs man page...
emacsbugs man page formatted
error in process sentinel: Man-bgproc-sentinel: Can't find the emacsbugs manpage
error in process sentinel: Can't find the emacsbugs manpage
Quit [2 times]
Type C-x 1 to remove help window.

Load-path shadows:
/usr/local/share/emacs/site-lisp/tree-widget/tree-widget hides
/usr/local/share/emacs/23.4/lisp/tree-widget
/usr/local/share/emacs/site-lisp/egg/its/thai hides
/usr/local/share/emacs/23.4/lisp/language/thai
/usr/local/share/emacs/23.4/lisp/textmodes/spell hides /home/ishikawa/bin/spell
/usr/local/share/emacs/site-lisp/tree-widget/dir-tree hides
/home/ishikawa/bin/dir-tree
/usr/local/share/emacs/23.4/lisp/textmodes/ispell hides
/home/ishikawa/bin/ispell
/usr/local/share/emacs/site-lisp/tree-widget/tree-widget-examples hides
/home/ishikawa/bin/tree-widget-examples
/usr/local/share/emacs/23.4/lisp/tempo hides /home/ishikawa/bin/tempo
/usr/local/share/emacs/site-lisp/tree-widget/tree-widget hides
/home/ishikawa/bin/tree-widget

Features:
(shadow sort mail-extr message sendmail ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
mailabbrev nnheader gnus-util netrc gmm-utils wid-edit mailheader
canlock sha1 hex-util hashcash warnings help-mode view apropos help-fns
man assoc dvc-autoloads dvc-core dvc-lisp dvc-buffers dvc-ui easymenu
dvc-register dvc-utils dvc-emacs ewoc dvc-defs dvc-site regexp-opt
server rmail rfc2047 rfc2045 ietf-drums time-date qp mm-util mail-prsvr
mail-utils emacsbug lpr autoinsert japan-util egg-util tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind font-render-setting gtk
x-toolkit x multi-tty emacs)

bug#10896: Suggested Fix (for configure)

[ISHIKAWA,chiaki]

This could be a Debian specific problem.
The failure was also observed on another Debian system.
(Which again is a cross between the current stable release, squeeze,
and the next version.)

I looked for crt1.o in supplied debian packages.

The following command prints out
the matched file names provided in each Debian package.

ishikawa@debian-vbox-ci:~$ dpkg --search "crt1.o"
libc6-dbg: /usr/lib/debug/usr/lib64/Scrt1.o
libc6-dbg: /usr/lib/debug/usr/lib64/crt1.o
libc6-dbg: /usr/lib/debug/usr/lib/i386-linux-gnu/crt1.o
libc6-dbg: /usr/lib/debug/usr/lib/i386-linux-gnu/Mcrt1.o
libc6-dev: /usr/lib/i386-linux-gnu/Scrt1.o
libc6-dbg: /usr/lib/debug/usr/lib/i386-linux-gnu/gcrt1.o
libc6-dbg: /usr/lib/debug/usr/lib64/Mcrt1.o
libc6-dbg: /usr/lib/debug/usr/lib64/gcrt1.o
libc6-dev: /usr/lib/i386-linux-gnu/Mcrt1.o
libc6-dev: /usr/lib/i386-linux-gnu/gcrt1.o
libc6-dev: /usr/lib/i386-linux-gnu/crt1.o
libc6-dbg: /usr/lib/debug/usr/lib/i386-linux-gnu/Scrt1.o


So they are all from libc6-dev, and libc6-dbg.

I got curious and checked the intallation status of libc6 on the computer.
Looks they are installed alright. See below

$ aptitude search libc6
i   libc6                           - Embedded GNU C Library: Shared
libraries
p   libc6-amd64                     - Embedded GNU C Library: 64bit
Shared libra
i A libc6-dbg                       - Embedded GNU C Library: detached
debugging
i A libc6-dev                       - Embedded GNU C Library:
Development Librar
p   libc6-dev-amd64                 - Embedded GNU C Library: 64bit
Development
i   libc6-i686                      - Embedded GNU C Library: Shared
libraries [
p   libc6-pic                       - Embedded GNU C Library: PIC
archive librar
p   libc6-prof                      - Embedded GNU C Library: Profiling
Librarie
p   libc6-xen                       - Embedded GNU C Library: Shared
libraries [

Lines that start with "i" in the first column mean the package on the
line are currently installed.

I wonder, though, why simple libc6 (not -dev, not -dbg) doesn't have
crt1.o according to the output of "dpkg --search".

Maybe emacs should not look at crt1.o?
At least not on the next Debian distribution currently in testing status?

The debian distribution on the PC I use is halfway across from
squeeze, the current stable version, to the next planned main release
version, w...something. I hate the clever naming.

GCC seems to have beeen installed without a problem.  It can compile
emacs after the aforementioned additional parameter to configure. It
can compile VirtualBox support modules for linux: I run this instance
of linux inside VirtualBox environment.  So the installation of GCC is
complete as far as I can tell.  (The other computer where emacs
configure without --with-crt-dir failed also has gcc
installed. It can compile and link mozill's thunderbird, a very
complex program, indeed. So GCC installation there is complete also.)

By the way, I diff'ed ./configure under 23.3 and 23.3 and didn't find
much change as far as CRT_DIR is concerned , so assume that it is not
that different.  So the cause seems to be a different packaging and
layout of libc6 under (newer) Debian packages.

I checked the time-stamp of the binary of emacs 23.3 which I compiled
myself on my PC and have been using.  emacs-23.3 compiled fine last
May (May 2011) when I used then current Debian distribution. So the
Debian packaging has changed between the current stable and the next
version (testing) since then.

Fix?

My suggestion is to move the test for the validity of CRT_DIR after
the case statement (and after the default setting of CRT_DIR). See
patch and the execution of configure below.  [Currently, it is tested
only inside the case statement for 64 bits checking. No checking is
done outside the case statement.]

Then, at least, the missing crt1.o is noticed immediately during the
configure before make is invoked.


PATCH to configure:

ishikawa@debian-vbox-ci:~/emacs-23.4$ diff -U 8 ./configure~ ./configure
--- ./configure~	2012-01-20 00:01:37.000000000 +0900
+++ ./configure	2012-02-27 17:39:20.000000000 +0900
@@ -5732,23 +5732,25 @@
    ## the location (bug#5655).
    ## Test for crtn.o, not just the directory, because sometimes the
    ## directory exists but does not have the relevant files (bug#1287).
    ## If user specified a crt-dir, use that unconditionally.
    if test "X$CRT_DIR" = "X"; then
      CRT_DIR=/usr/lib
      test -e /usr/lib64/crtn.o && CRT_DIR=/usr/lib64
    fi
-
-   test -e $CRT_DIR/crtn.o || test -e $CRT_DIR/crt0.o || \
-     as_fn_error $? "crt*.o not found.  Use --with-crt-dir to specify
the location." "$LINENO" 5
    ;;
+
 esac
 test "X$CRT_DIR" = "X" && CRT_DIR=/usr/lib

+test -e $CRT_DIR/crtn.o || test -e $CRT_DIR/crt0.o || \
+    as_fn_error $? "crt*.o not found.  Use --with-crt-dir to specify
the location." "$LINENO" 5
+
+




 if test "${with_sound}" != "no"; then
   # Sound support for GNU/Linux and the free BSDs.
   for ac_header in machine/soundcard.h sys/soundcard.h soundcard.h
 do :
ishikawa@debian-vbox-ci:~/emacs-23.4$ ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether gcc understands -Wno-pointer-sign... yes
checking whether gcc understands -Wdeclaration-after-statement... yes
checking whether ln -s works... yes
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking for install-info... /usr/bin/install-info
checking for install-info... (cached) /usr/bin/install-info
checking for install-info... (cached) /usr/bin/install-info
checking for gzip... /bin/gzip
checking for makeinfo... /usr/bin/makeinfo
checking for -znocombreloc... yes
configure: checking the machine- and system-dependent files to find out
 - which libraries the lib-src programs will want, and
 - whether the GNU malloc routines are usable...
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
configure: error: crt*.o not found.  Use --with-crt-dir to specify the
location.
ishikawa@debian-vbox-ci:~/emacs-23.4$

bug#10896: Suggested Fix (for configure)

[ISHIKAWA,chiaki]

OK, this is a problem in the next major release of Debian.

I found out that this choice of using //usr/lib/i386-linux-gnu/ to store
crt1.o and friends are necessitated by the Debian's choice of
multi-arch support in one way or the other.

So Debian, starting the next major revision called Wheezy (or whatever),
will store crt1.o not under /usr/lib directly and elsewhere (under a
subdirectory of /usr/lib based on architecture name, it seems.)

It turns out in the current major release, crt1.o *IS* stored under
/usr/lib. That is why I could compile emacs-23.3 May 2011 without
--with-crt-dir.

Upstream Debian package maintainers are advised to face this issue:

 http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libc6-dev;dist=unstable

I have no idea how wide the problem will be.

But maybe as a protective measure, emacs configure can be patched to
test CRT_DIR validity like the one I mentioned as a patch to catch this
type of configuration errors in advance.

Anyway, the lack of checking *OUTSIDE* and *AFTER* CRT_DIR is set is an
obvious error and so the checking should be done after the CRT_DIR
variable is set outside case like I reported IMHO.
This should help us catch other strange runtime library layout.

TIA

bug#10896: 23.4; --with-crt-dir was required since crt1.0 not found (on *32bit* system)

[Glenn Morris]

ishikawa wrote:

> Compilation failed unless --with-crt-dir was specified during configure on a
> 32 bit system.

That makes sense if you are using a Debian multi-arch system.

> And despite the comment that it is used only on amdx86-64 and ibms390x,
> somehow it is being used on this 32-bit Debian system.

We changed the way it works for 23.4 specifically for this issue, but
forgot to change the comment.

> So I bit the bullet and specified --with-crt-dir in configure line as
> below. And the compilation succeeded.

Good, that's what should happen.

> ./configure --with-x-toolkit=gtk --without-xim
> --with-crt-dir=/usr/lib/i386-linux-gnu
>
> However, something is fishy here. Since
> this is NOT a 64 bit system, and not ibms390, CRT_DIR should not be used if
> I believe the comment in src/Makefile.

The comment is incorrect. No need to panic!

> In my use of emacs for more than 20 years, I don't think I ever needed
> to specify this CRT_DIR via --with-crt-dir on a popular target.

It's due to Debian's fairly recent transition to multi-arch.


There isn't a bug here, other than an incorrect comment, and the fact
that you need to specify --with-crt-dir manually. This is all already
fixed for 24.1. You might like to try a pretest from
alpha.gnu.org/gnu/emacs/pretest

bug#10896: 23.4; --with-crt-dir was required since crt1.0 not found (on *32bit* system)

[Glenn Morris]

Glenn Morris wrote:

> There isn't a bug here, other than an incorrect comment, and the fact
> that you need to specify --with-crt-dir manually.

And the fact that configure should tell you that the build is going to
fail; but...

>  This is all already fixed for 24.1.

bug#10896: 23.4; --with-crt-dir was required since crt1.0 not found (on *32bit* system)

[ISHIKAWA,chiaki]

Thank you for your previous e-mail explaining the Debian's transition to 
multiarch support and the change in Emacs to support exactly this change.
(CRT_DIR seems to have been introduced in the last few months.)

I have read some documents at Debian web site and learnd quite a lot 
about mutliarch support.

I wish maintainers of other tool packages are just
as lucky as Emacs maintainer to move to this interesting
support infrastructure in a short time.

I understand emacs 24.1 fixes all the problems mentioned such as
configure doesn't fail before make is invoked.

Thank you again for the great package!

Happy Hacking,
CI

(2012/02/28 4:39), Glenn Morris wrote:
> Glenn Morris wrote:
>
>> There isn't a bug here, other than an incorrect comment, and the fact
>> that you need to specify --with-crt-dir manually.
>
> And the fact that configure should tell you that the build is going to
> fail; but...
>
>>   This is all already fixed for 24.1.
>
>
>
>
>
>
>