* emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) @ 2010-04-21 3:55 Nelson H. F. Beebe 2010-04-21 9:18 ` Andreas Schwab 2010-04-21 16:05 ` Neal Becker 0 siblings, 2 replies; 5+ messages in thread From: Nelson H. F. Beebe @ 2010-04-21 3:55 UTC (permalink / raw) To: emacs-devel; +Cc: beebe A build of emacs-23.1.96 on GNU/Linux AMD64 (Red Hat 4.8) with % set path=(/bin /usr/bin) % env LDFLAGS='-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64' ./configure && make all check failed like this: configure:15477: gcc -o conftest -O2 -D_BSD_SOURCE \ -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -Wl,-znocombreloc \ -L/usr/X11R6/lib conftest.c -lungif -lX11 >&5 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11 /usr/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status configure:15484: $? = 1 On Red Hat and OpenSuSE AMD64 systems, the default world is 64-bit, and libraries reside in /usr/local/lib64; the companion /usr/local/lib holds only 32-bit libraries. Thus it is WRONG WRONG WRONG for configure to be sticking in -L/usr/X11R6/lib, overriding the correct settings supplied in LDFLAGS! The directory /usr/X11R6/lib has only 32-bit libraries, whereas /usr/X11R6/lib64 has the needed 64-bit ones, and because that directory is vendor supplied, it is already listed in the directories known to /sbin/ldconfig, and thus need NOT be supplied. I was able to get a successful build by putting /usr/local/bin at the front of PATH; the config.log file then shows correct configure-time tests like this: gcc -o conftest -O2 -D_BSD_SOURCE -Wl,-rpath,/usr/local/lib64 \ -L/usr/local/lib64 -Wl,-znocombreloc -L/usr/X11R6/lib64 \ conftest.c -lX11 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) 2010-04-21 3:55 emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) Nelson H. F. Beebe @ 2010-04-21 9:18 ` Andreas Schwab 2010-04-21 16:05 ` Neal Becker 1 sibling, 0 replies; 5+ messages in thread From: Andreas Schwab @ 2010-04-21 9:18 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: emacs-devel "Nelson H. F. Beebe" <beebe@math.utah.edu> writes: > On Red Hat and OpenSuSE AMD64 systems, the default world is 64-bit, > and libraries reside in /usr/local/lib64; the companion /usr/local/lib > holds only 32-bit libraries. Thus it is WRONG WRONG WRONG for > configure to be sticking in -L/usr/X11R6/lib, overriding the correct > settings supplied in LDFLAGS! Emacs is using autoconf's AC_PATH_X to locate the X libraries, so please report that to the autoconf mailing list. 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." ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) 2010-04-21 3:55 emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) Nelson H. F. Beebe 2010-04-21 9:18 ` Andreas Schwab @ 2010-04-21 16:05 ` Neal Becker 1 sibling, 0 replies; 5+ messages in thread From: Neal Becker @ 2010-04-21 16:05 UTC (permalink / raw) To: emacs-devel Nelson H. F. Beebe wrote: > A build of emacs-23.1.96 on GNU/Linux AMD64 (Red Hat 4.8) with > > % set path=(/bin /usr/bin) > % env LDFLAGS='-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64' ./configure > && make all check > > failed like this: > > configure:15477: gcc -o conftest -O2 -D_BSD_SOURCE \ > -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -Wl,-znocombreloc \ > -L/usr/X11R6/lib conftest.c -lungif -lX11 >&5 > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching > for -lX11 /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when > searching for -lX11 /usr/bin/ld: cannot find -lX11 > collect2: ld returned 1 exit status > configure:15484: $? = 1 > > On Red Hat and OpenSuSE AMD64 systems, the default world is 64-bit, > and libraries reside in /usr/local/lib64; the companion /usr/local/lib > holds only 32-bit libraries. Thus it is WRONG WRONG WRONG for > configure to be sticking in -L/usr/X11R6/lib, overriding the correct > settings supplied in LDFLAGS! Builds fine on fedora 12 x86_64 using a (slightly modified) version of the rawhide spec file. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <4BCEB200.6020903@swipnet.se>]
* Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) [not found] <4BCEB200.6020903@swipnet.se> @ 2010-04-23 0:01 ` Nelson H. F. Beebe 2010-04-23 6:10 ` Jan D. 0 siblings, 1 reply; 5+ messages in thread From: Nelson H. F. Beebe @ 2010-04-23 0:01 UTC (permalink / raw) To: Jan D., emacs-devel; +Cc: beebe From recent mail exchanges with "Jan D." <jan.h.d@swipnet.se>: >> ... >> Nelson H. F. Beebe wrote: >> >> > A build of emacs-23.1.96 on GNU/Linux AMD64 (Red Hat 4.8) with >> > >> > % set path=(/bin /usr/bin) >> > % env LDFLAGS='-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64' ./configure && make all check >> > >> > failed like this: >> > >> > configure:15477: gcc -o conftest -O2 -D_BSD_SOURCE \ >> > -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -Wl,-znocombreloc \ >> > -L/usr/X11R6/lib conftest.c -lungif -lX11 >&5 >> > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11 >> > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11 >> > /usr/bin/ld: cannot find -lX11 >> > collect2: ld returned 1 exit status >> > configure:15484: $? = 1 >> >> Your LDFLAGS doesn't tell configure where to find include files. >> Did you try these options to configure: >> >> X features: >> --x-includes=DIR X include files are in DIR >> --x-libraries=DIR X library files are in DIR >> ... Red Hat puts the X11 libraries and header files in standard places that configure knows about, so those options are not needed. From the build log, here is what the problems are: checking for X... libraries /usr/X11R6/lib, headers [OKAY: expected] checking for librsvg-2.0 >= 2.11.0... no Requested 'librsvg-2.0 >= 2.11.0' but version of librsvg is 2.8.1 checking for pkg-config... (cached) /usr/bin/pkg-config checking for gtk+-2.0 >= 2.6 glib-2.0 >= 2.6... no Requested 'gtk+-2.0 >= 2.6' but version of GTK+ is 2.4.13 checking for dbus-1 >= 1.0... no Requested 'dbus-1 >= 1.0' but version of dbus is 0.22 checking for gconf-2.0 >= 2.13... no Requested 'gconf-2.0 >= 2.13' but version of gconf is 2.8.1 checking for xaw3d... no checking for libXaw... no; do not use toolkit by default checking for xft >= 0.13.0... yes checking XFT_CFLAGS... -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/freetype2/config checking XFT_LIBS... -L/usr/X11R6/lib64 -lXft -lX11 -lfreetype -lXrender -lfontconfig checking for XRenderQueryExtension in -lXrender... no checking X11/xpm.h usability... yes checking X11/xpm.h presence... yes checking for X11/xpm.h... yes checking for XpmReadFileToPixmap in -lXpm... no checking for jerror.h... yes checking for jpeg_destroy_compress in -ljpeg... no checking for libpng/png.h... yes checking for png_get_channels in -lpng... no checking for tiffio.h... yes checking for TIFFGetVersion in -ltiff... no checking for EGifPutExtensionLast in -lgif... no checking for EGifPutExtensionLast in -lungif... no configure: error: The following required libraries were not found: libXpm libjpeg libpng libgif/libungif libtiff The final error message is decidely misleading, and it really should be revised. What is really happening is UNFORTUNATE VERSION DEPENDENCE on the GIF, JPEG, PNG, and TIFF libraries. I find it unwise that emacs-23.x is expecting recent versions of these libraries, instead of venerable stable ones that have been around for a decade or more. For many of us, emacs is as essential as sh, ls, tar, cc, make, and many other traditional Unix tools, and a system without emacs needs fixing pronto before it can be considered usable. Many GNU/Linux distros come up by default with such an unusable environment, so the first thing that I do is install those essential tools before turning the system loose for our general user community. It is therefore imperative that emacs retain wide portability, and not just be installable on bleeding-edge systems. On all of our systems, I have recent versions of all of the standard libraries, compilers, and GNU tool suites, and they can be exposed if I build with the /usr/local tree visible. However, as part of GNU software package testing, I always include test builds, such as the above one, done in an environment where only the vendor-provided programs and libraries are visible. As a result, I WAS able to build emacs-23.1.96 on this Red Hat 4.8 system, and I use that version of emacs daily with the intent that I, rather than one of our users, find problems first. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) 2010-04-23 0:01 ` Nelson H. F. Beebe @ 2010-04-23 6:10 ` Jan D. 0 siblings, 0 replies; 5+ messages in thread From: Jan D. @ 2010-04-23 6:10 UTC (permalink / raw) To: Nelson H. F. Beebe; +Cc: emacs-devel Nelson H. F. Beebe wrote: >>From recent mail exchanges with "Jan D." <jan.h.d@swipnet.se>: > >>> Did you try these options to configure: >>> >>> X features: >>> --x-includes=DIR X include files are in DIR >>> --x-libraries=DIR X library files are in DIR >>> ... > > Red Hat puts the X11 libraries and header files in standard places > that configure knows about, so those options are not needed. > Didn't you say libraries where in lib64? That is not a standard place. Anyway, this is a autconf problem. > What is really happening is UNFORTUNATE VERSION DEPENDENCE on the GIF, > JPEG, PNG, and TIFF libraries. I find it unwise that emacs-23.x is > expecting recent versions of these libraries, instead of venerable > stable ones that have been around for a decade or more. > AFAIK, there has been many bug fixes and security fixes for those libraries over the years. You can compile without them or install newer ones. They are free software so it is not a big deal. We don't support 10 year old Gtk+ for that matter. Jan D. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-04-23 6:10 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-21 3:55 emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8) Nelson H. F. Beebe 2010-04-21 9:18 ` Andreas Schwab 2010-04-21 16:05 ` Neal Becker [not found] <4BCEB200.6020903@swipnet.se> 2010-04-23 0:01 ` Nelson H. F. Beebe 2010-04-23 6:10 ` Jan D.
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.