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

Previous Next

Full log

View this message in rfc822 format

From: "ISHIKAWA,chiaki" <ishikawa <at> yk.rim.or.jp>
To: 10896 <at> debbugs.gnu.org
Cc: "ISHIKAWA,chiaki" <ishikawa <at> yk.rim.or.jp>
Subject: bug#10896: Suggested Fix (for configure)
Date: Tue, 28 Feb 2012 02:19:33 +0900

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.