[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sr #110345] AC_PATH_X and friends should not look in /usr/lib/<various>

From: Zack Weinberg
Subject: [sr #110345] AC_PATH_X and friends should not look in /usr/lib/<various>/include when cross compiling
Date: Fri, 30 Oct 2020 16:46:31 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0


                 Summary: AC_PATH_X and friends should not look in
/usr/lib/<various>/include when cross compiling
                 Project: Autoconf
            Submitted by: zackw
            Submitted on: Fri 30 Oct 2020 08:46:29 PM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: Confirmed
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None



Reported by Ross Burton on the mailing list:

AC_PATH_X and friends are unusual in autoconf in that they
*explicitly* look into /usr/ for files (see _AC_PATH_X_DIRECT).
Notable this is the *only* macro in autoconf that explicitly looks
into /usr.

To write the logic out in English: iterate through a long list of
paths in /usr for a X11/Xlib.h file, and if that exists try a compile
test.  Then iterate through the same set of paths after s/include/lib/
looking for anything with a library extension (.a .so .sl .dynlib .dll
.la) and if one is found try a link test.

The big failure case is in cross compilation situations using a
sysroot where the target is binary compatible with the host.  In this
case AC_PATH_X will happily look at /usr and say that yes, X is
available, even if the sysroot doesn't have X.

My preferred solution would be to delete AC_PATH_X and friends and get
everyone to use PKG_CHECK_MODULES(x11), but I can see that isn't a
realistic solution.  Because the failure case above is a real problem
for us, we just delete all of that code.  Does anyone have a better
solution that would continue to work but not be so dramatically
dependent on host assumptions?

The thing that comes immediately to mind, and which would be feasible
for 2.70, is to not run _AC_PATH_X_DIRECT when cross-compiling.  I
don't think it's unreasonable to require people who want to
cross-compile X11 programs to either have the headers and libraries on
the cross-compiler's default search path, or use the --x-includes and
--x-libraries command line switches.  It might also make sense for
_AC_PATH_X_XMKMF to look for ${ac_tool_prefix}-xmkmf rather than plain
xmkmf, except I don't know if that would break existing cross compile
build farms.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]