[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs HEAD broken with XPM option in 1b492fa
From: |
Eli Zaretskii |
Subject: |
Re: Emacs HEAD broken with XPM option in 1b492fa |
Date: |
Mon, 04 Sep 2017 21:30:13 +0300 |
> From: Paul Eggert <address@hidden>
> Date: Mon, 4 Sep 2017 10:50:37 -0700
> Cc: Noam Postavsky <address@hidden>
>
> > It seems like in e88bbd22[2], author (cc'ed) typo-ed (s/X11/noX/):
>
> A comment before that line says:
>
> ### The Cygwin-w32 build uses <noX/xpm.h> instead of <X11/xpm.h>, so
> ### we need to set LDFLAGS accordingly.
>
> so presumably the noX is intentional. Perhaps this depends on Cygwin
> versions?
> Sorry, I can't be of much help here since I don't use Cygwin.
The OP was evidently compiling for FreeBSD, so I wonder how that
compilation ends up in a Cygwin-specific part of the configure
script. I guess some configure-time logic misfires on FreeBSD?
The relevant part of config.log is this:
configure:14996: checking X11/xpm.h presence
configure:14996: cpp -I/usr/local/include conftest.c
configure:14996: $? = 0
configure:14996: result: yes
configure:14996: checking for X11/xpm.h
configure:14996: result: yes
configure:14998: checking for XpmReadFileToPixmap in -lXpm
configure:15023: cc -o conftest -I/usr/local/include -O2 -g -fstack-protector
-fno-strict-aliasing -I/usr/local/include/librsvg-2.0
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
-I/usr/local/include -I/usr/local/include/gdk-pixbuf-2.0
-I/usr/local/include/libpng16 -I/usr/local/include/cairo
-I/usr/local/include/pixman-1 -I/usr/local/include/freetype2
-I/usr/local/include/libdrm -D_THREAD_SAFE -pthread -I/usr/local/include
-Wl,-rpath=/usr/local/lib -fstack-protector -L/usr/local/lib conftest.c -lXpm
-lX11 -lX11 -lutil >&5
configure:15023: $? = 0
configure:15032: result: yes
configure:15042: checking for XpmReturnAllocPixels preprocessor define
conftest.c:152:10: fatal error: 'noX/xpm.h' file not found
#include "noX/xpm.h"
^~~~~~~~~~~
1 error generated.
configure:15064: result: no