Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8)

Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8)

[Nelson H. F. 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/ -
-------------------------------------------------------------------------------

Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8)

[Jan D.]

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.

emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8)

[Nelson H. F. 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/ -
-------------------------------------------------------------------------------

Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8)

[Andreas Schwab]

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

Re: emacs-23.1.96: problem on GNU/Linux AMD64 (Red Hat 4.8)

[Neal Becker]

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.