Re: Build fails with "--with-system-poppler"
Am 24.11.21 um 11:03 schrieb Kevin Suo: ... [snip problem description] ... 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 I've implemented this in https://gerrit.libreoffice.org/c/core/+/125778 From the commit message: > Seems the first poppler including poppler-cpp.pc.in and also > cpp/poppler-version.h.in was 0.14.0. > > So this also increases the minimal system poppler dependency from > * poppler 0.12.0 (Wed Sep 9, 2009) > to > * poppler 0.14.0 (Tue Jun 8, 2010) That should be fine ;-) 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.
Re: Build fails with "--with-system-poppler"
Prior to: commit 697804f48f4217dab145d96175c6cddf560ec614 Date: Thu Apr 16 10:13:06 2015 +0200 Make cpp/poppler-version.h header optional we errored out if --with-system-poppler was used and there was no cpp/poppler-version.h That was 6 years ago, so it's possible that restoring that error on not seeing cpp/poppler-version.h and changing the min version of poppler to whichever one introduced cpp/poppler-version.h would work nowadays without controversy and avoid the loophole you tripped up in.
Build fails with "--with-system-poppler"
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.
[Libreoffice-bugs] [Bug 145791] Build fails with "--with-system-poppler"
https://bugs.documentfoundation.org/show_bug.cgi?id=145791 Xisco Faulí changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED CC||xiscofa...@libreoffice.org --- Comment #2 from Xisco Faulí --- Hello Kevin, Could you please send an email to the mailing list instead < https://wiki.documentfoundation.org/Development/Mailing_List >? For build issues, it's better than bugzilla. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 145791] Build fails with "--with-system-poppler"
https://bugs.documentfoundation.org/show_bug.cgi?id=145791 --- Comment #1 from Michael Warner --- So, for reference, on my Linux Mint 20 system, the relevant package is named libpoppler-cpp-dev. I don't know much about GNU autotools, but should we really be checking for specific packages installed by the package manager? What if I downloaded poppler outside of the package system? It seems like configure should just check for the presence of the poppler-version.h file itself, not that a particular package is installed. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 145791] New: Build fails with "--with-system-poppler"
https://bugs.documentfoundation.org/show_bug.cgi?id=145791 Bug ID: 145791 Summary: Build fails with "--with-system-poppler" Product: LibreOffice Version: 7.3.0.0 alpha0+ Master Hardware: All OS: Linux (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: LibreOffice Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: suokunl...@126.com 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. -- You are receiving this mail because: You are the assignee for the bug.
