emacs build failure on today's debian

emacs build failure on today's debian

[Miles Bader]

   $ make
   ...
   make[1]: Entering directory `/usr/local/build/emacs/master/src'
   make[1]: *** No rule to make target `/usr/lib/crt1.o', needed by `temacs'.  Stop.
   make[1]: Leaving directory `/usr/local/build/emacs/master/src'
   make: *** [src] Error 2
   make: Leaving directory `/usr/local/build/emacs/master'

   $ locate crt1 | grep /usr/lib
   /usr/lib/x86_64-linux-gnu/Mcrt1.o
   /usr/lib/x86_64-linux-gnu/Scrt1.o
   /usr/lib/x86_64-linux-gnu/crt1.o
   /usr/lib/x86_64-linux-gnu/gcrt1.o

It seems pretty dodgy that Emacs is directly looking for these files at
all, but oh well, I guess it's some messiness related to dumping.  If it
needs to use them, though, isn't there a less brittle way to find out
where they are?

For instance, this seems to work with gcc (starting with gcc 4.3):

   $ gcc -print-file-name=crt1.o
   /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../crt1.o

Thanks,

-Miles

-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: emacs build failure on today's debian

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Wed, Jun 15 2011, Miles Bader wrote:

> It seems pretty dodgy that Emacs is directly looking for these files at
> all, but oh well, I guess it's some messiness related to dumping.  If it
> needs to use them, though, isn't there a less brittle way to find out
> where they are?

You can fix it with passing this to configure:

  --with-crt-dir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)/

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: emacs build failure on today's debian

[Miles Bader]

Julien Danjou <julien@danjou.info> writes:
>> It seems pretty dodgy that Emacs is directly looking for these files at
>> all, but oh well, I guess it's some messiness related to dumping.  If it
>> needs to use them, though, isn't there a less brittle way to find out
>> where they are?
>
> You can fix it with passing this to configure:
>
>   --with-crt-dir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)/

Right, that will work as a workaround right now, but I don't think users
should _have_ to do that, if it's possible for configure to figure it
out automatically.

So my question is really about the right way to do it for the future.

Thanks,

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: emacs build failure on today's debian

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> So my question is really about the right way to do it for the future.

Make it work without pre-crt0.

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

Re: emacs build failure on today's debian

[Bruce Stephens]

Julien Danjou <julien@danjou.info> writes:

> On Wed, Jun 15 2011, Miles Bader wrote:
>
>> It seems pretty dodgy that Emacs is directly looking for these files at
>> all, but oh well, I guess it's some messiness related to dumping.  If it
>> needs to use them, though, isn't there a less brittle way to find out
>> where they are?
>
> You can fix it with passing this to configure:
>
>   --with-crt-dir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)/

That what at least one debian/rules does.  I believe that now fails.  On
this workstation, "dpkg-architecture -qDEB_HOST_MULTIARCH" produces
x86_64-linux-gnu but /usr/lib/x86_64-linux-gnu does not contain any crt
files (just liblouis.so, whatever that is).

brs% gcc -print-file-name=crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/crt1.o

Re: emacs build failure on today's debian

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Wed, Jun 15 2011, Bruce Stephens wrote:

> That what at least one debian/rules does.  I believe that now fails.  On
> this workstation, "dpkg-architecture -qDEB_HOST_MULTIARCH" produces
> x86_64-linux-gnu but /usr/lib/x86_64-linux-gnu does not contain any crt
> files (just liblouis.so, whatever that is).
>
> brs% gcc -print-file-name=crt1.o
> /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/crt1.o

It works fine on Debian sid with libc6-dev installed.

If you're using stable/testing, there's no multiarch yet so you won't
see the problem anyhow.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: emacs build failure on today's debian

[Glenn Morris]

Miles Bader wrote:

> Right, that will work as a workaround right now, but I don't think users
> should _have_ to do that, if it's possible for configure to figure it
> out automatically.

I was told that it isn't:

https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/746510/comments/3

Re: emacs build failure on today's debian

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>> Right, that will work as a workaround right now, but I don't think users
>> should _have_ to do that, if it's possible for configure to figure it
>> out automatically.
>
> I was told that it isn't:
>
> https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/746510/comments/3

Er, but I actually mentioned a method that seems to work fine:

   $ gcc -print-file-name=crt1.o
   /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../crt1.o

As Andreas said, of course, the _real_ solution is to fix Emacs not to
explicitly reference crt1.o at all... but I assume that's a bigger change.

-Miles

-- 
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.

Re: emacs build failure on today's debian

[Glenn Morris]

Miles Bader wrote:

> Er, but I actually mentioned a method that seems to work fine:
>
>    $ gcc -print-file-name=crt1.o
>    /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../crt1.o

OK, great. Can you install something in configure.in that tries that
then (when GCC = yes and crt is not otherwise found).

Re: emacs build failure on today's debian

[Miles Bader]

How's this?  -miles


2011-06-16  Miles Bader  <miles@gnu.org>

	* configure.in: Try to determine CRT_DIR automatically when
	using gcc.

diff --git a/configure.in b/configure.in
index 9e7ea85..60f7c4e 100644
--- a/configure.in
+++ b/configure.in
@@ -988,6 +988,21 @@ dnl Do this early because it can frob feature test macros for Unix-98 &c.
 AC_SYS_LARGEFILE
 
 
+## If we're using gcc, and the user hasn't specified a crt-dir, try to
+## determine it automatically by asking gcc.  [If this doesn't work,
+## CRT_DIR will remain empty and system-dependent code will be used
+## below.]
+##
+if test "x${GCC}y$CRT_DIR" = xyesy; then
+   crt_file=`$CC --print-file-name=crt1.o`
+   case "$crt_file" in
+     */*)
+       CRT_DIR=`AS_DIRNAME(["$crt_file"])`
+       ;;
+   esac
+fi
+
+
 ## If user specified a crt-dir, use that unconditionally.
 if test "X$CRT_DIR" = "X"; then
 


-- 
Custard, n. A vile concoction produced by a malevolent conspiracy of the hen,
the cow, and the cook.

Re: emacs build failure on today's debian

[Glenn Morris]

Nice (I did not know about AS_DIRNAME). Maybe add a "2> /dev/null" for
the $CC call? Personally I would have only asked gcc if the existing
system-dependent stuff failed to find crt, but doing it before is fine
too.

Miles Bader wrote:

> +## If we're using gcc, and the user hasn't specified a crt-dir, try to
> +## determine it automatically by asking gcc.  [If this doesn't work,
> +## CRT_DIR will remain empty and system-dependent code will be used
> +## below.]
> +##
> +if test "x${GCC}y$CRT_DIR" = xyesy; then
> +   crt_file=`$CC --print-file-name=crt1.o`
> +   case "$crt_file" in
> +     */*)
> +       CRT_DIR=`AS_DIRNAME(["$crt_file"])`
> +       ;;
> +   esac
> +fi