Problems compiling on Archlinux 64

Problems compiling on Archlinux 64

[Michael Fellinger]

Hello List,

This is my first mail to this list and i just started out with emacs... hope i 
don't break any rules here ;)

However, since we just have the emacs22 pretest period, i thought i should 
give it a try and went to build it on an archlinux 64bit system.

result: surprise, surprise, it won't build.
reason: there is no /usr/lib64 directory
backtrace:
make[2]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/lisp'
(cd src; make -w bootstrap)
make[2]: Entering directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src'
gcc -c -D_BSD_SOURCE   -Demacs -DHAVE_CONFIG_H -DUSE_LUCID  -I. -I/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src -D_BSD_SOURCE -I/usr/include/alsa -g -O2 -Wno-pointer-sign  
pre-crt0.c
make[2]: *** No rule to make target `/usr/lib64/crt1.o', needed by `temacs'. 
Stop.
make[2]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs'
make: *** [bootstrap] Error 2

I was told that this directory (/usr/lib64) does not exist since Archlinux 
follows the LFS and Archlinux64 the CLFS standards. The same seems to be the  
case for FreeBSD.

From m/amsx86-64.h:
> The libraries for binaries native to the build host's architecture are 
installed under /usr/lib in FreeBSD, and the ones that need special paths are 
32-bit compatibility libraries (installed under /usr/lib32).  To build a 
native binary of Emacs on FreeBSD/amd64 we can just point to /usr/lib.
And because of that, emacs fails to compile since it cannot 
find /usr/lib64/(crt1.o|crti.o)

I have no proposed solution apart from providing a different header with 
different paths, but i guess you guys know how to figure that out (my C-fu is 
rather weak)

Thanks for your help in advance.
^manveru


my System:
[manveru@sigma emacs]$ uname -a
Linux sigma 2.6.18-ARCH #1 SMP PREEMPT Tue Oct 3 21:59:13 IST 2006 x86_64 AMD 
Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux

the crt1.o:
[manveru@sigma emacs]$ file /usr/lib/crt1.o
/usr/lib/crt1.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), for 
GNU/Linux 2.6.6, not stripped

Re: Problems compiling on Archlinux 64

[Chong Yidong]

Michael Fellinger <manveru@weez-int.com> writes:

> make[2]: *** No rule to make target `/usr/lib64/crt1.o', needed by `temacs'. 
> Stop.
> make[2]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src'
> make[1]: *** [bootstrap-build] Error 2
> make[1]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs'
> make: *** [bootstrap] Error 2
>
> I was told that this directory (/usr/lib64) does not exist since Archlinux 
> follows the LFS and Archlinux64 the CLFS standards. The same seems to be the  
> case for FreeBSD.

Do other amdx86-64 distributions use /usr/lib64?  If so, how do we
distinguish between the two cases?

Re: Problems compiling on Archlinux 64

[Michael Fellinger]

On Wednesday 22 November 2006 03:31, Chong Yidong wrote:
> Michael Fellinger <manveru@weez-int.com> writes:
> > make[2]: *** No rule to make target `/usr/lib64/crt1.o', needed by
> > `temacs'. Stop.
> > make[2]: Leaving directory
> > `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src' make[1]: ***
> > [bootstrap-build] Error 2
> > make[1]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs'
> > make: *** [bootstrap] Error 2
> >
> > I was told that this directory (/usr/lib64) does not exist since
> > Archlinux follows the LFS and Archlinux64 the CLFS standards. The same
> > seems to be the case for FreeBSD.
>
> Do other amdx86-64 distributions use /usr/lib64?  If so, how do we
> distinguish between the two cases?

Well, the simplest way i could come up with is to look if such a folder exists 
at all simply doing this check after looking up `arch` returns a 
64bit-system.
As far as i know quite some distributions use /usr/lib64 to use both 64bit and 
32bit (in /usr/lib) libraries. However, distributions who do not support 
32bit libs at all only use /usr/lib
this is the case (only as far as i know) for FreeBSD (sorry guys, of course 
it's _no_ distribution ;), LFS (by default), Slackware (Slax), Archlinux and 
Gentoo.
Some more might be out there, especially all that are based on the distros i 
mentioned.

thanks again for looking into this.

^manveru

Re: Problems compiling on Archlinux 64

[Giorgos Keramidas]

On 2006-11-22 10:29, Michael Fellinger <manveru@weez-int.com> wrote:
>On Wednesday 22 November 2006 03:31, Chong Yidong wrote:
>>Michael Fellinger <manveru@weez-int.com> writes:
>>> make[2]: *** No rule to make target `/usr/lib64/crt1.o', needed by
>>> `temacs'. Stop.
>>> make[2]: Leaving directory
>>> `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src' make[1]: ***
>>> [bootstrap-build] Error 2
>>> make[1]: Leaving directory `/home/manveru/pkgbuilds/emacs-cvs/src/emacs'
>>> make: *** [bootstrap] Error 2
>>>
>>> I was told that this directory (/usr/lib64) does not exist since
>>> Archlinux follows the LFS and Archlinux64 the CLFS standards. The same
>>> seems to be the case for FreeBSD.
>>
>> Do other amdx86-64 distributions use /usr/lib64?  If so, how do we
>> distinguish between the two cases?
> 
> Well, the simplest way i could come up with is to look if such a
> folder exists at all simply doing this check after looking up `arch`
> returns a 64bit-system.

Well, yes... and no.  I wouldn't like this change for 64-bit FreeBSD
systems, for example (for the reason you explained below in:

> As far as i know quite some distributions use /usr/lib64 to use both
> 64bit and 32bit (in /usr/lib) libraries. However, distributions who do
> not support 32bit libs at all only use /usr/lib this is the case (only
> as far as i know) for FreeBSD (sorry guys, of course it's _no_
> distribution ;) [...]

Is there some way to uniquely identify Archlinux?

This could be even something like:

    iff we are on a linux system and...
    iff this is a 64-bit system and...
    iff file /etc/archlinux-release exists then...
        handle /usr/lib64 in a special manner

Re: Problems compiling on Archlinux 64

[Michael Fellinger]

On Wednesday 22 November 2006 20:53, Giorgos Keramidas wrote:
> On 2006-11-22 10:29, Michael Fellinger <manveru@weez-int.com> wrote:
> >On Wednesday 22 November 2006 03:31, Chong Yidong wrote:
> >>Michael Fellinger <manveru@weez-int.com> writes:
> >>> make[2]: *** No rule to make target `/usr/lib64/crt1.o', needed by
> >>> `temacs'. Stop.
> >>> make[2]: Leaving directory
> >>> `/home/manveru/pkgbuilds/emacs-cvs/src/emacs/src' make[1]: ***
> >>> [bootstrap-build] Error 2
> >>> make[1]: Leaving directory
> >>> `/home/manveru/pkgbuilds/emacs-cvs/src/emacs' make: *** [bootstrap]
> >>> Error 2
> >>>
> >>> I was told that this directory (/usr/lib64) does not exist since
> >>> Archlinux follows the LFS and Archlinux64 the CLFS standards. The same
> >>> seems to be the case for FreeBSD.
> >>
> >> Do other amdx86-64 distributions use /usr/lib64?  If so, how do we
> >> distinguish between the two cases?
> >
> > Well, the simplest way i could come up with is to look if such a
> > folder exists at all simply doing this check after looking up `arch`
> > returns a 64bit-system.
>
> Well, yes... and no.  I wouldn't like this change for 64-bit FreeBSD

ditto... i meant for linux only

>
> systems, for example (for the reason you explained below in:
> > As far as i know quite some distributions use /usr/lib64 to use both
> > 64bit and 32bit (in /usr/lib) libraries. However, distributions who do
> > not support 32bit libs at all only use /usr/lib this is the case (only
> > as far as i know) for FreeBSD (sorry guys, of course it's _no_
> > distribution ;) [...]
>
> Is there some way to uniquely identify Archlinux?
>
> This could be even something like:
>
>     iff we are on a linux system and...
>     iff this is a 64-bit system and...
>     iff file /etc/archlinux-release exists then...
>         handle /usr/lib64 in a special manner

Well, here is what you need :) The other factors are tested for already.

[manveru@pi ~]$ cat /etc/arch-release 
Arch Linux 0.7.2 (Gimmick)

Re: Problems compiling on Archlinux 64

[Nick Roberts]

 > > Is there some way to uniquely identify Archlinux?
 > >
 > > This could be even something like:
 > >
 > >     iff we are on a linux system and...
 > >     iff this is a 64-bit system and...
 > >     iff file /etc/archlinux-release exists then...
 > >         handle /usr/lib64 in a special manner
 > 
 > Well, here is what you need :) The other factors are tested for already.
 > 
 > [manveru@pi ~]$ cat /etc/arch-release 
 > Arch Linux 0.7.2 (Gimmick)

I think this would be a case of the tail wagging the dog.  There are over 100
GNU/Linux distributions and I don't think Emacs should have to test for each of
them.  Aren't there some standards that the distributions conform to?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Problems compiling on Archlinux 64

[Alfred M. Szmidt]

   I think this would be a case of the tail wagging the dog.  There
   are over 100 GNU/Linux distributions and I don't think Emacs should
   have to test for each of them.  Aren't there some standards that
   the distributions conform to?

No, sadly.  Host libraries are supposed to be put in /usr/lib, and not
/usr/lib64 if the host is 64-bit, so the best/simplest solution is
probably to not use /usr/lib64 at all, and mention in etc/PROBLEMS
that on 64-bit GNU/Linux systems that install 64-bit libraries in
/usr/lib64 (and 32-bit in /usr/lib) that one has to modify
m/amdx86-64.h or something along those lines.

Another way might be to use the output of `gcc -print-search-dirs',
and check in which directory crti.o exists in.  

My two groszy.

Re: Problems compiling on Archlinux 64

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Host libraries are supposed to be put in /usr/lib, and not
> /usr/lib64 if the host is 64-bit, so the best/simplest solution is
> probably to not use /usr/lib64 at all, and mention in etc/PROBLEMS
> that on 64-bit GNU/Linux systems that install 64-bit libraries in
> /usr/lib64 (and 32-bit in /usr/lib) that one has to modify
> m/amdx86-64.h or something along those lines.

According to the OP,

   As far as i know quite some distributions use /usr/lib64 to use
   both 64bit and 32bit (in /usr/lib) libraries. However,
   distributions who do not support 32bit libs at all only use
   /usr/lib

The fix I suggested was to use /usr/lib64 if that directory exists,
and /usr/lib otherwise.  Do you think it is not right?

Re: Problems compiling on Archlinux 64

[Alfred M. Szmidt]

   > Host libraries are supposed to be put in /usr/lib, and not
   > /usr/lib64 if the host is 64-bit, so the best/simplest solution
   > is probably to not use /usr/lib64 at all, and mention in
   > etc/PROBLEMS that on 64-bit GNU/Linux systems that install 64-bit
   > libraries in /usr/lib64 (and 32-bit in /usr/lib) that one has to
   > modify m/amdx86-64.h or something along those lines.

   According to the OP,

      As far as i know quite some distributions use /usr/lib64 to use
      both 64bit and 32bit (in /usr/lib) libraries. However,
      distributions who do not support 32bit libs at all only use
      /usr/lib

   The fix I suggested was to use /usr/lib64 if that directory exists,
   and /usr/lib otherwise.  Do you think it is not right?

If it works, I think it is right.  I was under the impression that it
didn't work, and people were comming up with strange solutions that
would check what distribution of GNU/Linux was being used and pick the
directory that way.

Re: Problems compiling on Archlinux 64

[Giorgos Keramidas]

On 2006-11-26 22:40, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>    Chong Yidong wrote:
>    The fix I suggested was to use /usr/lib64 if that directory exists,
>    and /usr/lib otherwise.  Do you think it is not right?
> 
> If it works, I think it is right.  I was under the impression that it
> didn't work, and people were comming up with strange solutions that
> would check what distribution of GNU/Linux was being used and pick the
> directory that way.

No, that would be horrible.  With dozens of GNU/Linux distributions out
there, it would bloat the checks unnecessarily.  IMHO, the fix cyd@ has
suggested is much better than distribution-specific checks :)

- Giorgos

Re: Problems compiling on Archlinux 64

[Richard Stallman]

    > Well, yes... and no.  I wouldn't like this change for 64-bit FreeBSD

    ditto... i meant for linux only

Did you mean GNU/Linux only?  Linux is not a system like FreeBSD,
it is just a kernel, and it isn't enough by itself to run Emacs on.

Re: Problems compiling on Archlinux 64

[Chong Yidong]

Does this completely untested patch give good results (you'll have to
regenerate configure to test it, of course)?

*** emacs/configure.in.~1.418.~	2006-11-14 10:54:05.000000000 -0500
--- emacs/configure.in	2006-11-22 10:42:46.000000000 -0500
***************
*** 1485,1490 ****
--- 1485,1500 ----
  AC_SYS_LARGEFILE
  
  
+ ### The standard library on x86-64 GNU/Linux distributions can 
+ ### be located in either /usr/lib64 or /usr/lib.
+ case "${canonical}" in
+   x86_64-*-linux-gnu* )
+     if test -d /usr/lib64; then
+       AC_DEFINE(HAVE_X86_64_LIB64_DIR, 1,
+         [Define to 1 if the file /usr/lib64 exists.])
+ fi
+ esac
+ 
  dnl This function defintion taken from Gnome 2.0
  dnl PKG_CHECK_MODULES(GSTUFF, gtk+-2.0 >= 1.3 glib = 1.3.4, action-if, action-not)
  dnl defines GSTUFF_LIBS, GSTUFF_CFLAGS, see pkg-config man page
*** emacs/src/m/amdx86-64.h.~1.11.~	2006-10-30 09:06:42.000000000 -0500
--- emacs/src/m/amdx86-64.h	2006-11-22 10:44:40.000000000 -0500
***************
*** 128,134 ****
--- 128,138 ----
  #else /* !__OpenBSD__ && !__FreeBSD__ */
  
  #undef START_FILES
+ #ifdef HAVE_X86_64_LIB64_DIR
  #define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o
+ #else
+ #define START_FILES pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o
+ #endif
  
  /* The duplicate -lgcc is intentional in the definition of LIB_STANDARD.
     The reason is that some functions in libgcc.a call functions from libc.a,
***************
*** 136,142 ****
--- 140,150 ----
     versions of ld are one-pass linkers, we need to mention -lgcc twice,
     or else we risk getting unresolved externals.  */
  #undef LIB_STANDARD
+ #ifdef HAVE_X86_64_LIB64_DIR
  #define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o
+ #else
+ #define LIB_STANDARD -lgcc -lc -lgcc /usr/lib/crtn.o
+ #endif
  
  #endif /* __FreeBSD__ */

Re: Problems compiling on Archlinux 64

[Giorgos Keramidas]

On 2006-11-22 10:48, Chong Yidong <cyd@stupidchicken.com> wrote:
> Does this completely untested patch give good results (you'll have to
> regenerate configure to test it, of course)?

I just finished building an Emacs snapshot with these changes on FreeBSD
7.0-CURRENT.  No obvious regressions can be seen, so it should be ok.

- Giorgos

> *** emacs/configure.in.~1.418.~	2006-11-14 10:54:05.000000000 -0500
> --- emacs/configure.in	2006-11-22 10:42:46.000000000 -0500
> ***************
> *** 1485,1490 ****
> --- 1485,1500 ----
>   AC_SYS_LARGEFILE
>   
>   
> + ### The standard library on x86-64 GNU/Linux distributions can 
> + ### be located in either /usr/lib64 or /usr/lib.
> + case "${canonical}" in
> +   x86_64-*-linux-gnu* )
> +     if test -d /usr/lib64; then
> +       AC_DEFINE(HAVE_X86_64_LIB64_DIR, 1,
> +         [Define to 1 if the file /usr/lib64 exists.])
> + fi
> + esac
> + 
>   dnl This function defintion taken from Gnome 2.0
>   dnl PKG_CHECK_MODULES(GSTUFF, gtk+-2.0 >= 1.3 glib = 1.3.4, action-if, action-not)
>   dnl defines GSTUFF_LIBS, GSTUFF_CFLAGS, see pkg-config man page
> *** emacs/src/m/amdx86-64.h.~1.11.~	2006-10-30 09:06:42.000000000 -0500
> --- emacs/src/m/amdx86-64.h	2006-11-22 10:44:40.000000000 -0500
> ***************
> *** 128,134 ****
> --- 128,138 ----
>   #else /* !__OpenBSD__ && !__FreeBSD__ */
>   
>   #undef START_FILES
> + #ifdef HAVE_X86_64_LIB64_DIR
>   #define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o
> + #else
> + #define START_FILES pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o
> + #endif
>   
>   /* The duplicate -lgcc is intentional in the definition of LIB_STANDARD.
>      The reason is that some functions in libgcc.a call functions from libc.a,
> ***************
> *** 136,142 ****
> --- 140,150 ----
>      versions of ld are one-pass linkers, we need to mention -lgcc twice,
>      or else we risk getting unresolved externals.  */
>   #undef LIB_STANDARD
> + #ifdef HAVE_X86_64_LIB64_DIR
>   #define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o
> + #else
> + #define LIB_STANDARD -lgcc -lc -lgcc /usr/lib/crtn.o
> + #endif
>   
>   #endif /* __FreeBSD__ */

Re: Problems compiling on Archlinux 64

[Michael Fellinger]

On Thursday 23 November 2006 00:48, Chong Yidong wrote:
> Does this completely untested patch give good results (you'll have to
> regenerate configure to test it, of course)?

Alright, that did the trick!
Thank you _so_ much, i really hope this goes into the final release :)
If you have further things to try for me, just write, but this is definitly 
the path to success.

^manveru

>
> *** emacs/configure.in.~1.418.~	2006-11-14 10:54:05.000000000 -0500
> --- emacs/configure.in	2006-11-22 10:42:46.000000000 -0500
> ***************
> *** 1485,1490 ****
> --- 1485,1500 ----
>   AC_SYS_LARGEFILE
>
>
> + ### The standard library on x86-64 GNU/Linux distributions can
> + ### be located in either /usr/lib64 or /usr/lib.
> + case "${canonical}" in
> +   x86_64-*-linux-gnu* )
> +     if test -d /usr/lib64; then
> +       AC_DEFINE(HAVE_X86_64_LIB64_DIR, 1,
> +         [Define to 1 if the file /usr/lib64 exists.])
> + fi
> + esac
> +
>   dnl This function defintion taken from Gnome 2.0
>   dnl PKG_CHECK_MODULES(GSTUFF, gtk+-2.0 >= 1.3 glib = 1.3.4, action-if,
> action-not) dnl defines GSTUFF_LIBS, GSTUFF_CFLAGS, see pkg-config man page
> *** emacs/src/m/amdx86-64.h.~1.11.~	2006-10-30 09:06:42.000000000 -0500
> --- emacs/src/m/amdx86-64.h	2006-11-22 10:44:40.000000000 -0500
> ***************
> *** 128,134 ****
> --- 128,138 ----
>   #else /* !__OpenBSD__ && !__FreeBSD__ */
>
>   #undef START_FILES
> + #ifdef HAVE_X86_64_LIB64_DIR
>   #define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o
> + #else
> + #define START_FILES pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o
> + #endif
>
>   /* The duplicate -lgcc is intentional in the definition of LIB_STANDARD.
>      The reason is that some functions in libgcc.a call functions from
> libc.a, ***************
> *** 136,142 ****
> --- 140,150 ----
>      versions of ld are one-pass linkers, we need to mention -lgcc twice,
>      or else we risk getting unresolved externals.  */
>   #undef LIB_STANDARD
> + #ifdef HAVE_X86_64_LIB64_DIR
>   #define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o
> + #else
> + #define LIB_STANDARD -lgcc -lc -lgcc /usr/lib/crtn.o
> + #endif
>
>   #endif /* __FreeBSD__ */

Re: Problems compiling on Archlinux 64

[Glenn Morris]

Chong Yidong wrote:

> Does this completely untested patch give good results (you'll have to
> regenerate configure to test it, of course)?

Building currently fails on x86-64 Red Hat Enterprise Linux 4, which
uses a /usr/lib64 directory. I think you also need a change to
src/config.in like the one below.

PS I guess this whole issue will cause problems if people try to build
a 32-bit Emacs on a 64-bit system (eg with -"m32"), but I think that
already doesn't work for other reasons:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-10/msg00462.html



*** config.in 14 Nov 2006 08:21:49 -0000 1.218
--- config.in 28 Nov 2006 00:19:15 -0000
***************
*** 691,696 ****
--- 691,700 ----
  /* Define to 1 if you have the X11R6 or newer version of Xlib. */
  #undef HAVE_X11R6
  
+/* Define to 1 if building a 64-bit Emacs on a system with the
+   64-bit standard library in /usr/lib64 (as opposed to /usr/lib). */
+ #undef HAVE_X86_64_LIB64_DIR
+ 
  /* Define to 1 if you have the X11R6 or newer version of Xt. */
  #undef HAVE_X11XTR6

Re: Problems compiling on Archlinux 64

[Glenn Morris]

Glenn Morris wrote:

> uses a /usr/lib64 directory. I think you also need a change to
> src/config.in like the one below.

It seems I meant to say "need to regenerate src/config.in", sorry.
Maybe that should have happened automatically, although I was
bootstrapping and it did not.

Re: Problems compiling on Archlinux 64

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Building currently fails on x86-64 Red Hat Enterprise Linux 4, which
> uses a /usr/lib64 directory. I think you also need a change to
> src/config.in like the one below.

Just to confirm (your message wasn't clear): does the compilation work
after this patch is applied?

> *** config.in 14 Nov 2006 08:21:49 -0000 1.218
> --- config.in 28 Nov 2006 00:19:15 -0000
> ***************
> *** 691,696 ****
> --- 691,700 ----
>   /* Define to 1 if you have the X11R6 or newer version of Xlib. */
>   #undef HAVE_X11R6
>   
> +/* Define to 1 if building a 64-bit Emacs on a system with the
> +   64-bit standard library in /usr/lib64 (as opposed to /usr/lib). */
> + #undef HAVE_X86_64_LIB64_DIR
> + 
>   /* Define to 1 if you have the X11R6 or newer version of Xt. */
>   #undef HAVE_X11XTR6

Re: Problems compiling on Archlinux 64

[Glenn Morris]

Chong Yidong wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
>> Building currently fails on x86-64 Red Hat Enterprise Linux 4, which
>> uses a /usr/lib64 directory. I think you also need a change to
>> src/config.in like the one below.
>
> Just to confirm (your message wasn't clear): does the compilation work
> after this patch is applied?

Yes, it works after changing config.in. Sorry for being unclear. It's
just a case of checking in a regenerated src/config.in to make
everything consistent.

Re: Problems compiling on Archlinux 64

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>>> Building currently fails on x86-64 Red Hat Enterprise Linux 4, which
>>> uses a /usr/lib64 directory. I think you also need a change to
>>> src/config.in like the one below.
>>
>> Just to confirm (your message wasn't clear): does the compilation work
>> after this patch is applied?
>
> Yes, it works after changing config.in. Sorry for being unclear. It's
> just a case of checking in a regenerated src/config.in to make
> everything consistent.

Done.  Thanks.