On Mon, 15 Oct 2018 14:40:12 -0500
rhubarbpieguy via blfs-support <[email protected]> wrote:
> Poppler 0.67 compiles without error using
> poppler_fix_cmake_gtk3_include_dir.patch.
:)
Good! OK, there is a problem in the poppler build system. However, there
is *also* something unusual with your system - well, at least, your
system does differ somehow from Bruce's (and presumably from Ken's). It
is not a gcc system problem, but rather something else, some environment
variable that is being set, etc.
FWIW, poppler uses the cmake build system, not autotools/automake.
cmake takes the place of ./configure, setting options and
detecting/locating packages, etc. After cmake sets things up, make can
then be run to start the build.
Now, when the poppler developers made the 0.63 change, in
test/CMakeLists.txt they changed
if (GTK_FOUND)
add_definitions(${GTK3_CFLAGS})
to this:
if (GTK_FOUND)
include_directories(
SYSTEM
${GTK3_INCLUDE_DIRS})
where SYSTEM specifies an -isystem option (rather than the default -I)
to gcc. The problem is that GTK3_INCLUDE_DIRS is never initialized to
anything by the poppler cmake GTK detection/setup module! They forgot
to define it before they used it.
cmake/modules/FindGTK.cmake has:
pkg_check_modules(GTK3 "gtk+-3.0>=3.8" "gdk-pixbuf-2.0")
find_package_handle_standard_args(GTK DEFAULT_MSG GTK3_LIBRARIES GTK3_CFLAGS)
where find_package_handle_standard_args initializes/defines the listed
variables for the given package (the package name is the first in the list).
Note that GTK3_INCLUDE_DIRS is not listed, but the old 0.62 GTK3_CFLAGS
still is!
My poppler_fix_cmake_gtk3_include_dir.patch changes that to:
find_package_handle_standard_args(GTK DEFAULT_MSG GTK3_LIBRARIES
GTK3_INCLUDE_DIRS GTK3_CFLAGS)
after which it builds just fine on rhubarbpieguy's system.
Now, note that even under the old 0.62 build system, which does work
on rhubarbpieguy's system, (using the two
patches with 0.67 - poppler_revert_gtk3_include_dirs.patch and
poppler_gtk-test_force_build_fail.patch the latter of which is just to
halt the build at the right place) there is still an anomaly in the
calling of gcc on rhubarbpieguy's system:
> -I//usr/include
Even though that anomaly alone does not cause a build failure, it is
not right. With the 0.63 and later build system and without fixing
the undefined GTK3_INCLUDE_DIRS, this anomaly becomes:
-isystem //usr/include
which does error out with gcc 8.x - it takes *two* wrongs here for a
build failure to result.
Note that Bruce's system does not have any mention of any include
for /usr/include, let alone //usr/include.
I think the reason that the build does not fail on Bruce's system
even though poppler fails to define GTK3_INCLUDE_DIRS is that the
build system declares the GTK3 includes more than once - and the
first one alone still allows it to build even though the second
declaration, from FindGTK.cmake, is incomplete.
In summary, I think there are two problems: a mistake in poppler's
GTK cmake code and something wrong/different with rhubarbpieguy's
system. It is not a gcc problem, but rather it has to do with how
gcc is being called.
I will look more into how poppler cmake sets up its gcc calls and
try to see how a -I//usr/include could come about.
In the meantime, Bruce and rhubarbpieguy, what version of cmake are
each of you running?
cmake --version
rhubarbpieguy, can you try a 0.67 build with the two patches:
patch -p1 -i ../poppler_fix_cmake_gtk3_include_dir.patch
patch -p1 -i ../poppler_gtk-test_force_build_fail.patch
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
make VERBOSE=1
and show me the c++ line that fails? This way, I can see how gcc is
being called on your system after the poppler GTK cmake code bug is
fixed.
Also, please verify for me again that none of the include variables
are being set:
echo $CPLUS_INCLUDE_PATH
echo $C_INCLUDE_PATH
echo $CPATH
echo $GTK3_INCLUDE_DIRS
echo $GTK3_INCLUDE_DIR
rhubarbpieguy, do your recall doing/setting anything else with regard to
/usr/include in your /etc/profile, bashrc, anything in /etc/profile.d
including xorg.sh, or your .bashrc, .bash_profile, etc. ?
You can scan your entire /etc for all mentions of /usr/include by
running
find /etc -type f -print|sort|xargs grep /usr/include
as root. What does it show?
Mike
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
