This report is moved from:
https://bugs.documentfoundation.org/show_bug.cgi?id=145791
Steps to Reproduce:
1. On a system without poppler-devel and without poppler-cpp, when I do
$./autogen.sh
it gives:
checking for POPPLER... no
configure: error: Package requirements (poppler >= 0.12.0 ) were not met:
Package 'poppler', required by 'virtual:world', not found
This is good, and is expected.
2. Now, if I install poppler-devel:
$ sudo dnf install poppler-devel
and then do:
./autogen.sh
now the autogen will pass, code is ready to compile.
3. However, if now you take a look at the config_host/config_poppler.h
file as generated by the autogen.sh script, you have the following:
#define HAVE_POPPLER_VERSION_H 0
which seems to indicate that you have an older poppler version installed
which does not provided a poppler-version.h header. This #define was set
by the configure.ac in line 11983:
if test "$ENABLE_PDFIMPORT" = "TRUE" -a "$ENABLE_POPPLER" = "TRUE"; then
dnl ===================================================================
dnl Check for system poppler
dnl ===================================================================
AC_MSG_CHECKING([which PDF import poppler to use])
if test "$with_system_poppler" = "yes"; then
AC_MSG_RESULT([external])
SYSTEM_POPPLER=TRUE
PKG_CHECK_MODULES( POPPLER, poppler >= 0.12.0 )
AC_LANG_PUSH([C++])
save_CXXFLAGS=$CXXFLAGS
save_CPPFLAGS=$CPPFLAGS
CXXFLAGS="$CXXFLAGS $POPPLER_CFLAGS"
CPPFLAGS="$CPPFLAGS $POPPLER_CFLAGS"
AC_CHECK_HEADER([cpp/poppler-version.h],
[AC_DEFINE([HAVE_POPPLER_VERSION_H], 1)],
[])
...
else
AC_MSG_RESULT([internal])
SYSTEM_POPPLER=
BUILD_TYPE="$BUILD_TYPE POPPLER"
AC_DEFINE([HAVE_POPPLER_VERSION_H], 1)
fi
AC_DEFINE([ENABLE_PDFIMPORT],1)
fi
...
The "test "$with_system_poppler"" block here is problematic. The
cpp/poppler-version.h is a header file in the "poppler-cpp" package, not
in the "poppler-devel" package (at least in my Fedora 34 system), so
there will never be a cpp/poppler-version.h if there is no "poppler-cpp"
package installed.
4. While it is fine that you can use an old poppler currently to build
LibreOffice, however if the poppler version is not detected correctly,
the build may fail, especially given that we the poppler internal has
changed a lot overtime and we have so many poppler-version check codes
in sdext/source/pdfimport.
For instance, based on step 3, since there is no configure error give,
now if you do
make
then you will get the following (with a 21.01.0 version of system poppler):
In file included from
/home/suokunlong/lo/source/core/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:20:
/home/suokunlong/lo/source/core/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:61:9:
warning: 'POPPLER_VERSION' macro redefined [-Wmacro-redefined]
#define POPPLER_VERSION "0.12.3"
^
/usr/include/poppler/poppler-config.h:39:9: note: previous definition is
here
#define POPPLER_VERSION "21.01.0"
^
In file included from
/home/suokunlong/lo/source/core/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:20:
/home/suokunlong/lo/source/core/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:136:13:
error: unknown type name 'GBool'
typedef GBool poppler_bool;
======
The solution either:
1. Add "poppler-cpp" as a dependency for --with-system-poppler. This
approach is not perfect, as we only the poppler-cpp for version check,
there is no actual poppler-cpp API code used in our libreoffice code
base as far as I know. or
2. Force the poppler version with a --with-system-poppler poppler
version to be the same as (or compatible with) the external_tarball
version of poppler used, and remove those poppler version checks in
sdext/source/pdfimport codes. (i.e. the same as how we handle 'orcus'
and 'mdds'). Dealing this poppler version changes is proven to be a
panic, as poppler's internal is changing in every release and we are not
using the stable C++ API codes of poppler.
