all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Problems compiling on Archlinux 64
@ 2006-11-21 11:55 Michael Fellinger
  2006-11-21 18:31 ` Chong Yidong
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Fellinger @ 2006-11-21 11:55 UTC (permalink / raw)
  Cc: ams

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-21 11:55 Problems compiling on Archlinux 64 Michael Fellinger
@ 2006-11-21 18:31 ` Chong Yidong
  2006-11-22  1:29   ` Michael Fellinger
  0 siblings, 1 reply; 19+ messages in thread
From: Chong Yidong @ 2006-11-21 18:31 UTC (permalink / raw)
  Cc: ams, emacs-devel

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?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-21 18:31 ` Chong Yidong
@ 2006-11-22  1:29   ` Michael Fellinger
  2006-11-22 11:53     ` Giorgos Keramidas
  2006-11-22 15:48     ` Chong Yidong
  0 siblings, 2 replies; 19+ messages in thread
From: Michael Fellinger @ 2006-11-22  1:29 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-22  1:29   ` Michael Fellinger
@ 2006-11-22 11:53     ` Giorgos Keramidas
  2006-11-24  1:27       ` Michael Fellinger
  2006-11-22 15:48     ` Chong Yidong
  1 sibling, 1 reply; 19+ messages in thread
From: Giorgos Keramidas @ 2006-11-22 11:53 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-22  1:29   ` Michael Fellinger
  2006-11-22 11:53     ` Giorgos Keramidas
@ 2006-11-22 15:48     ` Chong Yidong
  2006-11-23 15:12       ` Giorgos Keramidas
                         ` (2 more replies)
  1 sibling, 3 replies; 19+ messages in thread
From: Chong Yidong @ 2006-11-22 15:48 UTC (permalink / raw)
  Cc: Giorgos Keramidas, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-22 15:48     ` Chong Yidong
@ 2006-11-23 15:12       ` Giorgos Keramidas
  2006-11-24  2:32       ` Michael Fellinger
  2006-11-28  0:34       ` Glenn Morris
  2 siblings, 0 replies; 19+ messages in thread
From: Giorgos Keramidas @ 2006-11-23 15:12 UTC (permalink / raw)
  Cc: Michael Fellinger, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-22 11:53     ` Giorgos Keramidas
@ 2006-11-24  1:27       ` Michael Fellinger
  2006-11-25  5:06         ` Nick Roberts
  2006-11-25  6:59         ` Richard Stallman
  0 siblings, 2 replies; 19+ messages in thread
From: Michael Fellinger @ 2006-11-24  1:27 UTC (permalink / raw)


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)

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-22 15:48     ` Chong Yidong
  2006-11-23 15:12       ` Giorgos Keramidas
@ 2006-11-24  2:32       ` Michael Fellinger
  2006-11-28  0:34       ` Glenn Morris
  2 siblings, 0 replies; 19+ messages in thread
From: Michael Fellinger @ 2006-11-24  2:32 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-24  1:27       ` Michael Fellinger
@ 2006-11-25  5:06         ` Nick Roberts
  2006-11-25  5:46           ` Alfred M. Szmidt
  2006-11-25  6:59         ` Richard Stallman
  1 sibling, 1 reply; 19+ messages in thread
From: Nick Roberts @ 2006-11-25  5:06 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-25  5:06         ` Nick Roberts
@ 2006-11-25  5:46           ` Alfred M. Szmidt
  2006-11-26 21:29             ` Chong Yidong
  0 siblings, 1 reply; 19+ messages in thread
From: Alfred M. Szmidt @ 2006-11-25  5:46 UTC (permalink / raw)
  Cc: manveru, emacs-devel

   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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-24  1:27       ` Michael Fellinger
  2006-11-25  5:06         ` Nick Roberts
@ 2006-11-25  6:59         ` Richard Stallman
  1 sibling, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2006-11-25  6:59 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-25  5:46           ` Alfred M. Szmidt
@ 2006-11-26 21:29             ` Chong Yidong
  2006-11-26 21:40               ` Alfred M. Szmidt
  0 siblings, 1 reply; 19+ messages in thread
From: Chong Yidong @ 2006-11-26 21:29 UTC (permalink / raw)
  Cc: manveru, Nick Roberts, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-26 21:29             ` Chong Yidong
@ 2006-11-26 21:40               ` Alfred M. Szmidt
  2006-11-27  4:11                 ` Giorgos Keramidas
  0 siblings, 1 reply; 19+ messages in thread
From: Alfred M. Szmidt @ 2006-11-26 21:40 UTC (permalink / raw)
  Cc: manveru, nickrob, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-26 21:40               ` Alfred M. Szmidt
@ 2006-11-27  4:11                 ` Giorgos Keramidas
  0 siblings, 0 replies; 19+ messages in thread
From: Giorgos Keramidas @ 2006-11-27  4:11 UTC (permalink / raw)
  Cc: manveru, Chong Yidong, nickrob, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-22 15:48     ` Chong Yidong
  2006-11-23 15:12       ` Giorgos Keramidas
  2006-11-24  2:32       ` Michael Fellinger
@ 2006-11-28  0:34       ` Glenn Morris
  2006-11-28  0:49         ` Glenn Morris
  2006-11-28  0:58         ` Chong Yidong
  2 siblings, 2 replies; 19+ messages in thread
From: Glenn Morris @ 2006-11-28  0:34 UTC (permalink / raw)
  Cc: Michael Fellinger, Giorgos Keramidas, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-28  0:34       ` Glenn Morris
@ 2006-11-28  0:49         ` Glenn Morris
  2006-11-28  0:58         ` Chong Yidong
  1 sibling, 0 replies; 19+ messages in thread
From: Glenn Morris @ 2006-11-28  0:49 UTC (permalink / raw)
  Cc: Michael Fellinger, Giorgos Keramidas, emacs-devel

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-28  0:34       ` Glenn Morris
  2006-11-28  0:49         ` Glenn Morris
@ 2006-11-28  0:58         ` Chong Yidong
  2006-11-28  1:05           ` Glenn Morris
  1 sibling, 1 reply; 19+ messages in thread
From: Chong Yidong @ 2006-11-28  0:58 UTC (permalink / raw)
  Cc: Michael Fellinger, Giorgos Keramidas, emacs-devel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-28  0:58         ` Chong Yidong
@ 2006-11-28  1:05           ` Glenn Morris
  2006-11-28 16:04             ` Chong Yidong
  0 siblings, 1 reply; 19+ messages in thread
From: Glenn Morris @ 2006-11-28  1:05 UTC (permalink / raw)
  Cc: Michael Fellinger, Giorgos Keramidas, emacs-devel

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Problems compiling on Archlinux 64
  2006-11-28  1:05           ` Glenn Morris
@ 2006-11-28 16:04             ` Chong Yidong
  0 siblings, 0 replies; 19+ messages in thread
From: Chong Yidong @ 2006-11-28 16:04 UTC (permalink / raw)
  Cc: Michael Fellinger, Giorgos Keramidas, emacs-devel

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.

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2006-11-28 16:04 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-21 11:55 Problems compiling on Archlinux 64 Michael Fellinger
2006-11-21 18:31 ` Chong Yidong
2006-11-22  1:29   ` Michael Fellinger
2006-11-22 11:53     ` Giorgos Keramidas
2006-11-24  1:27       ` Michael Fellinger
2006-11-25  5:06         ` Nick Roberts
2006-11-25  5:46           ` Alfred M. Szmidt
2006-11-26 21:29             ` Chong Yidong
2006-11-26 21:40               ` Alfred M. Szmidt
2006-11-27  4:11                 ` Giorgos Keramidas
2006-11-25  6:59         ` Richard Stallman
2006-11-22 15:48     ` Chong Yidong
2006-11-23 15:12       ` Giorgos Keramidas
2006-11-24  2:32       ` Michael Fellinger
2006-11-28  0:34       ` Glenn Morris
2006-11-28  0:49         ` Glenn Morris
2006-11-28  0:58         ` Chong Yidong
2006-11-28  1:05           ` Glenn Morris
2006-11-28 16:04             ` Chong Yidong

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.