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

Zack Weinberg <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.bugs
Message-ID <[email protected]>
URL:
  <https://savannah.gnu.org/support/?110345>

                 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

    _______________________________________________________

Details:

Reported by Ross Burton on the mailing list:

[Ross:]
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?

[Zack:]
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:

  <https://savannah.gnu.org/support/?110345>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.