X11 detection fails with recent X.org

[eric]

Posted originally by Dirk Mitt <mdirk@…> on Crystal Space forum: CS-forum:1286

I have Kanotix 2006-01-RC4, with gcc 4.1 , on which I've never gotten Crystal Space to compile fully. I also have Windows XP Home, on which your Demos run fine. And I did install the required libraries, of which many were already installed on RC4.

On my Linux Box, one problem that I seem to encounter, is that Jam can't detect the presence of X11. Kanotix 2006-01 uses an Xorg-7.1 -based X-server, and my guess would be that this new one's folders are organized differently. So when your configuring system looks for X11/Intrinsic.h [or whatever it is,] forget it. My X11 is installed at /usr/X11R6... And my X11 include folder only has subdirectories, no header files directly in ...X11/

Since it would make no sense to try to build CS with no X-server at all, might it not just be a better idea to skip checking for it? Who's going to build it entirely on a command-line terminal?

Dirk

[eric]

Indeed, X11R7 changes things quite a bit from a developer/client perspective. The old X11 check in Autoconf 2.59 does not account for these changes. Among the important changes, paths of installed resources have moved, but X.org now ships .pkgconfig files, which means that the CS configure script can use the "standard" CS_CHECK_LIB_WITH() macro to detect newer installations of X.org. A more complete list of X.org changes is reproduced below. It is an excerpt from:  http://fedora.redhat.com/docs/release-notes/fc5/#sn-Xorg

---

21.3. X.org X11R7 Developer Overview

The following list includes some of the more visible changes for developers in X11R7:

The entire buildsystem has changed from imake to the GNU autotools collection.

Libraries now install pkgconfig *.pc files, which should now always be used by software that depends on these libraries, instead of hard coding paths to them in /usr/X11 R6/lib or elsewhere.

Everything is now installed directly into /usr instead of /usr/X11 R6. All software that hard codes paths to anything in /usr/X11 R6 must now be changed, preferably to dynamically detect the proper location of the object. Developers are strongly advised against hard-coding the new X11R7 default paths.

Every library has its own private source RPM package, which creates a runtime binary subpackage and a -devel subpackage.

21.4. X.org X11R7 Developer Notes

This section includes a summary of issues of note for developers and packagers, and suggestions on how to fix them where possible.

21.4.1. The /usr/X11R6/ Directory Hierarchy

X11R7 files install into /usr directly now, and no longer use the /usr/X11 R6/ hierarchy. Applications that rely on files being present at fixed paths under /usr/X11 R6/, either at compile time or run time, must be updated. They should now use the system PATH, or some other mechanism to dynamically determine where the files reside, or alternatively to hard code the new locations, possibly with fallbacks.

21.4.2. Imake

The imake utility is no longer used to build the X Window System, and is now officially deprecated. X11R7 includes imake, xmkmf, and other build utilities previously supplied by the X Window System. X.Org highly recommends, however, that people migrate from imake to use GNU autotools and pkg-config. Support for imake may be removed in a future X Window System release, so developers are strongly encouraged to transition away from it, and not use it for any new software projects.

21.4.3. The Systemwide app-defaults/ Directory

The system app-defaults/ directory for X resources is now %{_datadir}/X11/app-defaults, which expands to /usr/share/X11/app-defaults/ on Fedora Core 5 and for future Red Hat Enterprise Linux systems.

21.4.4. Correct Package Dependencies

Any software package that previously used Build Requires: (XFree86-devel|xorg-x11-devel) to satisfy build dependencies must now individually list each library dependency. The preferred and recommended method is to use virtual build dependencies instead of hard coding the library package names of the xorg implementation. This means you should use Build Requires: libXft-devel instead of Build Requires: xorg-x11-Xft-devel. If your software truly does depend on the X.Org X11 implementation of a specific library, and there is no other clean or safe way to state the dependency, then use the xorg-x11-devel form. If you use the virtual provides/requires mechanism, you will avoid inconvenience if the libraries move to another location in the future.

21.4.5. xft-config

Modular X now uses GNU autotools and pkg-config for its buildsystem configuration and execution. The xft-config utility has been deprecated for some time, and pkgconfig *.pc files have been provided for most of this time. Applications that previously used xft-config to obtain the Cflags or libs build options must now be updated to use pkg-config.

[dirkmitt]

I originated the ticket. Thank you for your reply.

Based on this ticket, I first installed libx11-dev. Then I installed libxt-dev not libXft-devel , both using KPackage. Now the CS ./configure command reports that X is in its usual folders and libraries, because

1) libx11-dev left numerous header files in /usr/include/X11 that weren't there before, EXcluding Intrinsic.h

2) libxt-dev left Intrinsic.h additionally.

Now I have to see, whether Crystal Space will also compile fully on my system.

Dirk

[dirkmitt]

I've learned that by installing these packages, I have created an old-style software interface that might not be entirely correct, but which does allow me to compile Crystal Space.

For which reason I'm seeing Demo Levels run on my Linux Box for the first time, that previously only ran on my Windows XP computer.

Dirk

[eric]

Dirk Mitt wrote:

I've learned that by installing these packages, I have created an old-style software interface that might not be entirely correct, but which does allow me to compile Crystal Space.

Right. This is not necessarily the best approach, but may work for the moment, at least until CS configure can be fixed. I would guess that we haven't heard more reports of this problem yet since most people probably "upgrade" their X installations rather than installating anew, thus leaving legacy gunk in the old X directories.

By taking advantage of the CS_CHECK_LIBRARY_WITH() Autoconf macro which I wrote for Crystal Space, we should be able to detect these newer X.org installations pretty easily since CS_CHECK_LIBRARY_WITH() automatically consults pkgconfig .pc files (among other things). Therefore, the CS configure script should be updated first to check for newer X.org installations via CS_CHECK_LIBRARY_WITH(), and then fall back to the older Autoconf 2.59 built-in X11 check if CS_CHECK_LIBRARY_WITH() fails to detect a newer installation.

-- ES

[res]

Use CS_CHECK_LIB_WITH to detect X11

[res]

Eric, could you perhaps review the patch? Thanks.

[fossi]

assigned to eric

[eric]

Some initial observations about the patch:

• The initial CS_CHECK_LIB_WITH([x11]) check seems a bit fragile as a means to detect new vs. old installation. While it is true that it "should" fail on old installations where the library name is actually X11 (not case difference), not all filesystems are case-sensitive (i.e. Cygwin, HFS+). A more robust way to detect new vs. old installations would be to augment the CS_CHECK_LIB_WITH([x11]) check to detect an API function/symbol which exist only in newer installations.

• The setting of X_CFLAGS, X_LFLAGS, and X_LIBS should occur outside of the "xext" conditional since those variables must be set even if the optional xext was not detected.

[eric]

Ignore the second comment in the last response. I was misreading the code.

[eric]

Other than the somewhat fragile detection of new vs. old installations (based upon case-sensitivity), the patch looks like it should work.

[anonymous]

It might be worth considering using CS_EMIT_BUILD_RESULTS() for all of the libraries -- x11, xext, xxf86vm, and xaw -- rather than emitting CFLAGS and LFLAGS variables manually. This would allow for more idiomatic `LinkWith X11 XEXT ...' usage in the Jamfiles. (I think the only reason the ugly manual approach was used in the past was because we needed to support the old GNU Makefile system which has since been retired.)

Anyhow, this is something which can be done but is not actually required for this patch.

[res]

Replying to eric:

Other than the somewhat fragile detection of new vs. old installations (based upon case-sensitivity), the patch looks like it should work.

Hmm, what may go wrong if an old installation is mistaken for a new one? Couldn't success of the initial x11 test mean that the other ones possibly succeed, too? Or do I miss something?

[eric]

Replying to res:

Hmm, what may go wrong if an old installation is mistaken for a new one? Couldn't success of the initial x11 test mean that the other ones possibly succeed, too? Or do I miss something?

An "accidental" detection of an older X11 installation with the new CS_CHECK_LIB_WITH() test probably would not hurt anything, so worrying about this slight fragility might be overkill.

[res]

Merged into trunk with r25691.

[vknecht@…]

With CS r25738, XOrg 6.8.2, autoconf 2.59, I get those errors at './configure' step:
checking for IceConnectionNumber in -lICE... yes
./configure: line 29443: X_LIBS: command not found
./configure: line 29443: X_EXTRA_LIBS: command not found
./configure: line 29443: X_PRE_LIBS: command not found
./configure: line 29443: -lXext: command not found
checking if pkg-config recognizes xxf86vm... no


Changing that line in configure.ac (then regenerating configure) fixes it:
X_LFLAGS=$(X_PRE_LIBS) $(X_LIBS) -lXext -lX11 $(X_EXTRA_LIBS)])
to
X_LFLAGS="$X_PRE_LIBS $X_LIBS -lXext -lX11 $X_EXTRA_LIBS"])

[eric]

Replying to vknecht@club-internet.fr:

With CS r25738, XOrg 6.8.2, autoconf 2.59, I get those errors at './configure' step: ./configure: line 29443: X_LIBS: command not found ./configure: line 29443: X_EXTRA_LIBS: command not found ./configure: line 29443: X_PRE_LIBS: command not found ./configure: line 29443: -lXext: command not found

Fixed in r25745.

[eric]

Merged into 1.0 branch as r25748.