[blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[rhubarbpieguy via blfs-support]

I receive the following error with the make and 'make install' Poppler
commands.  Poppler-data installs without error.

/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
make[2]: *** [test/CMakeFiles/gtk-test.dir/build.make:63:
test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:803:
test/CMakeFiles/gtk-test.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

I have an ASCII text /usr/include/c++/8.2.0/cstdlib (-rw-r--r-- 6325).

[rhubarbpieguy via blfs-support]

Post by rhubarbpieguy via blfs-support
I receive the following error with the make and 'make install' Poppler
commands.  Poppler-data installs without error.
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
test/CMakeFiles/gtk-test.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
I have an ASCII text /usr/include/c++/8.2.0/cstdlib (-rw-r--r-- 6325).

I tried other Poppler versions and found poppler-0.62.0 from BLFS 8.2
compiled without error.  I first tried poppler-0.69.0, thinking a newer
version might work, but it produced the same error as poppler-0.62.0.

Perhaps I made an error compiling LFS 8.3, but gcc compiled without
error and I ran the tests.  In addition, LFS/BLFS 8.3 seems to be
running quite well and Poppler is the only package that has given me grief.

[Michael Shell via blfs-support]

On Mon, 1 Oct 2018 19:18:40 -0500

Post by rhubarbpieguy via blfs-support
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~

Perhaps the first link below is the most helpful:

https://github.com/Martchus/tageditor/issues/22
https://github.com/OxfordSKA/OSKAR/issues/10
https://stackoverflow.com/questions/45245923/mingw-include-c-cstdlib-stdlib-h-no-such-file-or-directory
https://bugreports.qt.io/browse/QTBUG-53367

It seems gcc was changed in way that the use of -isystem now alters
the include directory search order which breaks some packages.

One suggested solution seems to be to simply remove the use of the gcc -isystem
option (perphaps in a cmake/XX.cmake file). Another suggestion is
to change the order of the c++ search path:

export CPLUS_INCLUDE_PATH=/usr/local/include/c++/8.2.0:/usr/local/include:/usr/include:$CPLUS_INCLUDE_PATH

Yet another solution suggests changing the
#include_next
to
#include

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936

However, I don't see any reference to -isystem in the poppler-0.69.0
source tree:

find . -type f -print|sort|xargs grep isystem

Nor did I find a reference to CPLUS_INCLUDE_PATH.

I did find a reference to CMAKE_SYSTEM_INCLUDE_PATH in
cmake/modules/PopplerMacros.cmake

You have to do a:

make VERBOSE=1

to get the actual gcc command that fails, then we can see how gcc
was called. You can then try modifying things (either in the source
tree or in that command line) until you get past the problem.

If you get it to work, I would report the problem to the poppler folks.


Cheers,

Mike

[Michael Shell via blfs-support]

It seems another BLFS user has encountered this issue (but with
applications other than poppler):

http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-October/080407.html

I also found this:

https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/

Check what the environment variable CPLUS_INCLUDE_PATH is being
set to and where it is being set:

echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*

Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH


Cheers,

Mike

[rhubarbpieguy via blfs-support]

Post by Michael Shell via blfs-support
It seems another BLFS user has encountered this issue (but with
http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-October/080407.html
https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/
Check what the environment variable CPLUS_INCLUDE_PATH is being
echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*
Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH
Cheers,
Mike

Perhaps CPLUS_INCLUDE_PATH is the problem as I have no such variable. 
However, I'm confused, as the only reference I see in the documentation
refers to installing X outside the standard prefix.  I install X using
/usr, which I understood as the standard prefix.

What have I missed?  Is there another area where I'm to set
CPLUS_INCLUDE_PATH?

[Ken Moffat via blfs-support]

Post by rhubarbpieguy via blfs-support

Post by Michael Shell via blfs-support
It seems another BLFS user has encountered this issue (but with
http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-October/080407.html
https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/
Check what the environment variable CPLUS_INCLUDE_PATH is being
echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*
Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH
Cheers,
Mike

Perhaps CPLUS_INCLUDE_PATH is the problem as I have no such variable. 
However, I'm confused, as the only reference I see in the documentation
refers to installing X outside the standard prefix.  I install X using /usr,
which I understood as the standard prefix.
What have I missed?  Is there another area where I'm to set
CPLUS_INCLUDE_PATH?

No, that is the only place, and only people who build Xorg in
somewhere other than /usr are known to need it. But maybe setting
it will work for you when building poppler - if so, we would all be
_slightly_ closer to understanding what is going wrong for you.

Alternatively, it might not help. But it seems worth trying since
we don't have any other suggestions (I guess my suggestion that you
maybe used the old CMMI instead of cmake didn't fit).

We have seen a number of settings which are only needed by some
people, e.g. when building rustc, setting RUSTFLAGS to link to
libffi, but if needed they do no harm.

ĸen

[Michael Shell via blfs-support]

On Thu, 4 Oct 2018 18:33:07 -0500

Post by rhubarbpieguy via blfs-support
What have I missed?  Is there another area where I'm to set
CPLUS_INCLUDE_PATH?

See my recent reply to Alex who has a similar problem in the BLFS thread
"Compilation failures - missing header files".

On your system, run these commands:

unset CPLUS_INCLUDE_PATH
`gcc -print-prog-name=cc1plus` -v

to show the g++ include paths irrespective of what CPLUS_INCLUDE_PATH
was set to. Be sure to use the correct type of quotes in the above
command. Both of the quotes are ` which is on the same key as the tilde ~
on most keyboards. And it seems one has to press ctl-C to get back to
the command prompt after "End of search list." is displayed.

Show us what your gcc spits out from the above and then we all can
compare notes.


Cheers,

Mike

[Michael Shell via blfs-support]

On Thu, 4 Oct 2018 22:03:45 -0400
After helping Alex some more, these commands reveal info we need from
your system:


echo $CPLUS_INCLUDE_PATH
echo $C_INCLUDE_PATH
echo $CPATH
`gcc -print-prog-name=cc1plus` -v
`gcc -print-prog-name=cc1` -v
find /usr -name "stdlib.h"


You will have to press ctrl-C after the gcc lines to regain the
command prompt.


Cheers,

Mike

[rhubarbpieguy via blfs-support]

Post by Michael Shell via blfs-support
On Thu, 4 Oct 2018 22:03:45 -0400
After helping Alex some more, these commands reveal info we need from
echo $CPLUS_INCLUDE_PATH
echo $C_INCLUDE_PATH
echo $CPATH
`gcc -print-prog-name=cc1plus` -v
`gcc -print-prog-name=cc1` -v
find /usr -name "stdlib.h"
You will have to press ctrl-C after the gcc lines to regain the
command prompt.
Cheers,
Mike

It appears setting the new variables didn't fix the problem.  I hope
I've followed your and Ken's guidance correctly. Again, I should mention
Poppler was the only problem package and the older version works well,
but it would be nice to know what I've done wrong.  So ...

echo $CPLUS_INCLUDE_PATH - /usr/include
echo $C_INCLUDE_PATH - /usr/include
echo $CPATH - nothing returned

------------------------------

`gcc -print-prog-name-cc1plus` -v

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
-----------------------------------------------------

`gcc -print-prog-name=cc1` -v

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
-----------------------------------------------------

find /usr -name "stdlib.h

/usr/include/bits/stdlib.h
/usr/include/c++/8.2.0/stdlib.h
/usr/include/c++/8.2.0/tr1/stdlib.h
/usr/include/stdlib.h
---------------------

[Michael Shell via blfs-support]

On Sat, 6 Oct 2018 08:52:26 -0500

Post by rhubarbpieguy via blfs-support
It appears setting the new variables didn't fix the problem.  I hope
I've followed your and Ken's guidance correctly. Again, I should mention
Poppler was the only problem package and the older version works well,
but it would be nice to know what I've done wrong.  So ...
echo $CPLUS_INCLUDE_PATH - /usr/include
echo $C_INCLUDE_PATH - /usr/include
echo $CPATH - nothing returned

Wait, we have to do one thing at a time. Did you set the above
$CPLUS_INCLUDE_PATH and $C_INCLUDE_PATH? If so, don't do that yet -
we need to see the gcc paths without these variables being set.
If you didn't set them, do you have any idea where and why they
are being set?

Post by rhubarbpieguy via blfs-support
`gcc -print-prog-name-cc1plus` -v

I think you meant

`gcc -print-prog-name=cc1plus` -v

OK, so, do a:

unset CPLUS_INCLUDE_PATH
unset C_INCLUDE_PATH
unset CPATH
`gcc -print-prog-name=cc1plus` -v
`gcc -print-prog-name=cc1` -v

and show us the result.

Now, what Alex did to overcome his problem was this:

export CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include

So, it wasn't just /usr/include

If you use Alex's longer CPLUS_INCLUDE_PATH definition, can you build
poppler 0.69?

Without any CPLUS_INCLUDE_PATH etc. variables set, can you build poppler
0.62 on the gcc 8.2.0 system?

If so, but poppler 0.69 fails, can you narrow it down to which release
first shows the problem?

https://poppler.freedesktop.org/releases.html

You don't have to try to build these different releases right now, at least
not until after the questions above are answered. But, I notice that for
the 0.65 release changes there is the item:

"Fix compilation with libc++"

which might actually mean "break the libc++ build on rhubarbpieguy's system"
LOL!

Post by rhubarbpieguy via blfs-support
find /usr -name "stdlib.h"
/usr/include/bits/stdlib.h
/usr/include/c++/8.2.0/stdlib.h
/usr/include/c++/8.2.0/tr1/stdlib.h
/usr/include/stdlib.h

All this looks OK to me.



Mike

[rhubarbpieguy via blfs-support]

Wait, we have to do one thing at a time. Did you set the above
$CPLUS_INCLUDE_PATH and $C_INCLUDE_PATH? If so, don't do that yet -


Yes, I changed /etc/profile.d/xorg.sh according to Introduction to
Xorg-7.  So without that change I see the following:

---------------------------------
`gcc -print-prog-name=cc1plus` -v

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include

-----------------------------
`gcc -print-prog-name=cc1` -v

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include
-------------

And yes, Poppler 0.62 compiled on BLFS 8.2. I've compiled Poppler for several releases as I need it for EpdfView.

[Michael Shell via blfs-support]

On Sun, 7 Oct 2018 07:28:34 -0500

Post by rhubarbpieguy via blfs-support
Yes, I changed /etc/profile.d/xorg.sh according to Introduction to

OK, the include search paths look OK to me for both your g++/gcc 8.2.0 and
7.3.0 systems - that is for the example you gave *without*
$CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH being set.

Can you compile Poppler-0.67.0 on your gcc 8.2.0 system *if*
$CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH are *not* set (don't have
any pathappend lines in /etc/profile.d/xorg.sh, unset/clear
C_INCLUDE_PATH CPLUS_INCLUDE_PATH, and restart x) and thus your gcc's search
paths are as you stated (quoted at the end of this post)?

If yes, then I sure don't think you should be setting $CPLUS_INCLUDE_PATH
et al. Note that in the Xorg-7 instructions:

http://www.linuxfromscratch.org/blfs/view/svn/x/xorg7.html

it is stated:

"Note: If you've decided to use the standard /usr prefix, you can omit
the remainder of this page and continue at util-macros-1.19.2.
If you've decided to not use the standard prefix, be sure to add
$XORG_PREFIX/bin to your PATH environment variable, and
$XORG_PREFIX/lib/pkgconfig and $XORG_PREFIX/share/pkgconfig to
your PKG_CONFIG_PATH variable. It is also helpful to specify
additional search paths for gcc and an include directory for the
aclocal program. Issue the following commands as the root user:
"

that is ONLY if the standard prefix /usr is *not* being used.

Post by rhubarbpieguy via blfs-support
echo $CPLUS_INCLUDE_PATH - /usr/include
echo $C_INCLUDE_PATH - /usr/include

You should not be setting $CPLUS_INCLUDE_PATH, $C_INCLUDE_PATH
is the include paths gcc/g++ is using already "includes the includes
of Xorg", which is the case for /usr/include.


If you still can't compile poppler-0.67.0 with your gcc 8.2.0 system
being sure $CPLUS_INCLUDE_PATH and $C_INCLUDE_PATH are not set, then
you will have to begin with poppler-0.62 and advance the version number
until the build fails. My guess is the trouble starts with version 0.65.


Cheers,

Mike


For reference, the gcc search paths that look OK to me are as you gave

Post by rhubarbpieguy via blfs-support
---------------------------------
`gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include
-----------------------------
`gcc -print-prog-name=cc1` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include
-------------

So, IMHO, that is what you want to have and what matches most everyone
else's systems.

[rhubarbpieguy via blfs-support]

Post by Michael Shell via blfs-support
Can you compile Poppler-0.67.0 on your gcc 8.2.0 system *if*
$CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH are *not* set (don't have
any pathappend lines in /etc/profile.d/xorg.sh, unset/clear
C_INCLUDE_PATH CPLUS_INCLUDE_PATH, and restart x) and thus your gcc's search
paths are as you stated (quoted at the end of this post)?
If yes, then I sure don't think you should be setting $CPLUS_INCLUDE_PATH

I think I may have been unclear through my numerous posts.  I've never
set $CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH as I compile X in /usr. 
My original (and current) problem is Poppler-0.67.0 won't compile and
those variables are not set.  I only set them as I thought you wanted
that as a test.

Unfortunately, Poppler-0.63.0 fails the same as Poppler-0.67.0.
Poppler-0.62.0 compiles successfully on my BLFS 8.3 build but any
version above that fails.  I'm still surprised Poppler-0.67.0 compiles
successfully on my BLFS 8.2 build, 'pdfdetach --version' shows 0.67.0.

If you've other thoughts I'm happy to test.  However, again, I'm by no
means dead in the water.  EpdfView works quite well with poppler-0.62.0
and nothing else seems affected by whatever I've done to affect
Poppler.  Your help is always appreciated but don't knock yourself out.

[Michael Shell via blfs-support]

On Tue, 9 Oct 2018 18:32:08 -0500

I've never set $CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH as I compile
X in /usr. My original (and current) problem is Poppler-0.67.0 won't
compile and those variables are not set. I only set them as I thought
you wanted that as a test.

Well, I asked you if you had set the variables, and so what did you

Yes, I changed /etc/profile.d/xorg.sh according to Introduction to
Xorg-7.

Anyway, in all that follows, I'm assuming the $CPLUS_INCLUDE_PATH and/or
$C_INCLUDE_PATH variables are *not* set.

Poppler-0.62.0 compiles successfully on my BLFS 8.3 build but any
version above that fails.

OK, good, so we now know the problem starts with 0.63.0

I looked through the changes from 0.62.0 to 0.63.0. The most likely
suspect is an automated script (clang-tidy) change made to the file
test/CMakeLists.txt. It is the only change I can see that affects
the include files. This change was made to please clang, not gcc:

https://github.com/freedesktop/poppler/commits/master/test/CMakeLists.txt
https://github.com/freedesktop/poppler/commit/e428033c2d7efbbbf89bb2f84c8998521ac7ef8e#diff-15547c54d3d4898a882b4ab7b3cee381

The attached patch reverts what I think is your trouble maker. Apply
it to 0.63.0 and later (it should work with 0.69.0 as well) using:

patch -p1 -i ../poppler_revert_gtk3_include_dirs.patch

And let us know if you can build 0.63.0 and later after applying
the patch.


Cheers,

Mike

[rhubarbpieguy via blfs-support]

Post by Michael Shell via blfs-support
The attached patch reverts what I think is your trouble maker. Apply
patch -p1 -i ../poppler_revert_gtk3_include_dirs.patch
And let us know if you can build 0.63.0 and later after applying
the patch.
Cheers,
Mike

Good news.  I applied the patch to poppler-0.63.0 and poppler-0.67.0. 
Both compiled successfully.

[Michael Shell via blfs-support]

On Wed, 10 Oct 2018 16:47:49 -0500

Post by rhubarbpieguy via blfs-support
I applied the patch to poppler-0.63.0 and poppler-0.67.0. 
Both compiled successfully.

The changeset between 0.63 and 0.64 is tens of thousands of lines long.
Tis much like finding a needle in haystack on the first try. Yay!

However, we still don't know exactly what is going wrong and why others
haven't encountered this problem.

However, given that the offending change was made/suggested by a clang
script, I think it is likely that it is a bug (in poppler 0.63-on).

First of all, GTK3 must be installed for gtk-test.cc to be built.
So, the problem won't occur on systems without GTK3.

Now, on your gcc 8.2.0 system (the newer one where the build fails),
do a fresh unpack of poppler 0.63. Do not apply any patches to it.

Verify that your gcc/g++ path variables are indeed not set to
anything:

echo $CPLUS_INCLUDE_PATH
echo $C_INCLUDE_PATH

They are both unset/blank, right?

Now, attempt to build poppler 0.63, but invoke the verbose
option with make to see the actual gcc/g++ command that fails:

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
make VERBOSE=1


Could you paste the gcc/g++ commands just before and after the
build failure occurred so we can see what command line options
gcc/g++ was invoked with when attempting to build gtk-test.cc?


Cheers,

Mike

[rhubarbpieguy via blfs-support]

Post by Michael Shell via blfs-support
Could you paste the gcc/g++ commands just before and after the
build failure occurred so we can see what command line options
gcc/g++ was invoked with when attempting to build gtk-test.cc?

I see two batches of Error 2 errors.  I hope this is what you want:

------------------------------------------------------------------------

In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from /sources/poppler-0.67.0/goo/GooString.h:42,
from /sources/poppler-0.67.0/poppler/Object.h:45,
from /sources/poppler-0.67.0/poppler/GfxState.h:43,
from /sources/poppler-0.67.0/splash/SplashBitmap.h:39,
from /sources/poppler-0.67.0/test/gtk-test.cc:9:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
make[2]: *** [test/CMakeFiles/gtk-test.dir/build.make:63: test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
make[2]: Leaving directory '/sources/poppler-0.67.0/build'
make[1]: *** [CMakeFiles/Makefile2:803: test/CMakeFiles/gtk-test.dir/all] Error 2
make[1]: Leaving directory '/sources/poppler-0.67.0/build'
make: *** [Makefile:141: all] Error 2

------------------------------------------------------------------------------------------------------------------------------------------

[ 89%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
from /usr/include/c++/8.2.0/string:52,
from /sources/poppler-0.67.0/goo/GooString.h:42,
from /sources/poppler-0.67.0/poppler/Object.h:45,
from /sources/poppler-0.67.0/poppler/GfxState.h:43,
from /sources/poppler-0.67.0/splash/SplashBitmap.h:39,
from /sources/poppler-0.67.0/test/gtk-test.cc:9:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
make[2]: *** [test/CMakeFiles/gtk-test.dir/build.make:63: test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:803: test/CMakeFiles/gtk-test.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

[Michael Shell via blfs-support]

On Thu, 11 Oct 2018 17:58:44 -0500
We want to see not just the error message, but the actual g++ command
line that caused the error.

When you build via:

make VERBOSE=1

you should be able to see all the gcc/g++ commands as they are being
executed, long lines like:

/usr/bin/c++ -DUSE_OPENJPEG2 -Dpoppler_EXPORTS -I....

Do you see all that? The one that tries to compile gtk-test.cc
just before the error message is the one we are interested in.


Cheers,

Mike

[Bruce Dubbs via blfs-support]

Post by Michael Shell via blfs-support
On Thu, 11 Oct 2018 17:58:44 -0500
We want to see not just the error message, but the actual g++ command
line that caused the error.
make VERBOSE=1
you should be able to see all the gcc/g++ commands as they are being
/usr/bin/c++ -DUSE_OPENJPEG2 -Dpoppler_EXPORTS -I....
Do you see all that? The one that tries to compile gtk-test.cc
just before the error message is the one we are interested in.

Why are we trying to solve problems with poppler-0.67 when the current
version of poppler is 0.69?

-- Bruce

[Pierre Labastie via blfs-support]

Post by Bruce Dubbs via blfs-support

Post by Michael Shell via blfs-support
On Thu, 11 Oct 2018 17:58:44 -0500
rhubarbpieguy via blfs-support
We want to see not just the error message, but the actual g++ command
line that caused the error.
make VERBOSE=1
you should be able to see all the gcc/g++ commands as they are being
/usr/bin/c++  -DUSE_OPENJPEG2 -Dpoppler_EXPORTS -I....
Do you see all that? The one that tries to compile gtk-test.cc
just before the error message is the one we are interested in.

Why are we trying to solve problems with poppler-0.67 when the current
version of poppler is 0.69?

Because the piece of code (lines 18 to 23 intest/CMakeLists.txt) which
generates
the error seems to not have been changed in 0.69? But, maybe it is
upstream job to
try to debug this...

Pierre

[Michael Shell via blfs-support]

On Fri, 12 Oct 2018 14:33:35 +0200

Post by Pierre Labastie via blfs-support
Because the piece of code (lines 18 to 23 intest/CMakeLists.txt) which
generates the error seems to not have been changed in 0.69? But, maybe it
is upstream job to try to debug this...

Yeah, the problematic code is the same from 0.63 to 0.69. However, IMHO,
we don't yet have enough info to file a report upstream. Once I see how
g++ is being called differently between 0.62 and 0.63 then I can get a
better idea of what exactly is going wrong - mostly likely a duplication
in the include paths.

I then plan to report this issue upstream. The main unresolved problem is
that I still don't see what is different about rhubarbpieguy's system - why
does he run into this problem while no one else seems to? The mostly likely
candidiate here was the setting of $CPLUS_INCLUDE_PATH, but it seems that
is not the case.


Mike

[rhubarbpieguy via blfs-support]

"Without any CPLUS_INCLUDE_PATH etc. variables set, can you build
poppler 0.62 on the gcc 8.2.0 system?"

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

I misread your above question as I saw 8.2 and thought you meant BLFS
8.2.  I reported running Poppler 0.62 on my BLFS 8.3/gcc 8.2.0 system
previously.  I'm using EpdfView with Poppler 0.62 currently.

However, (what the heck), I thought I'd attempt compiling Poppler 0.67
(BLFS 8.3 version) on my BLFS 8.2 build.  To my surprise, It compiled
successfully.  So, I can compile Poppler 0.67 on BLFS 8.2/gcc 7.3 but
not on BLFS 8.3/gcc 8.2.  I've apparently done something wrong with BLFS
8.3 but am a loss as why it affects only Poppler.

I also ran your commands on my BLFS 8.2/gcc 7.3 build.

---------------------------------
`gcc -print-prog-name=cc1plus` -v

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed
/usr/include

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include

-----------------------------
`gcc -print-prog-name=cc1` -v

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed
/usr/include

ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include

----------------------------------------------------------------------------------------------------------

Ken raised the cmake question earlier.  I used the cmake commands from
the documentation and OpenJPEG (which compiled successfully) uses
cmake.  I know little of cmake but want to make certain there's not
something in his post I didn't understand.

[Ken Moffat via blfs-support]

Ken raised the cmake question earlier.  I used the cmake commands from the
documentation and OpenJPEG (which compiled successfully) uses cmake.  I know
little of cmake but want to make certain there's not something in his post I
didn't understand.

I don't think there was anything other than making sure you had used
cmake.

I only asked because my log had the progress markers from cmake, and
what you posted seemed to omit them. Probably, 0.67 had already
dropped the option to use configure.

All I can add about cmake is that with the build of OpenJPEG in
BLFS-8.3, poppler-0.68 will use the static lib (noticed because I go
out of my way to prevent static libs getting accidentally
pulled-in). For 0.67 that is not an issue, and anyway it is
unrelated to whatever is breaking your build.

ĸen

[Bruce Dubbs via blfs-support]

Post by Ken Moffat via blfs-support

Ken raised the cmake question earlier.  I used the cmake commands from the
documentation and OpenJPEG (which compiled successfully) uses cmake.  I know
little of cmake but want to make certain there's not something in his post I
didn't understand.

I don't think there was anything other than making sure you had used
cmake.
I only asked because my log had the progress markers from cmake, and
what you posted seemed to omit them. Probably, 0.67 had already
dropped the option to use configure.
All I can add about cmake is that with the build of OpenJPEG in
BLFS-8.3, poppler-0.68 will use the static lib (noticed because I go
out of my way to prevent static libs getting accidentally
pulled-in). For 0.67 that is not an issue, and anyway it is
unrelated to whatever is breaking your build.

Let me add that the current version of poppler is 0.69.0. It is not in
the book yet, but it builds fine on my BLFS 8.3 system (as did
poppler-0.68.0).

I did miss some -support messages, so I don't know what the original
problem was other than poppler would not build.

-- Bruce

[Ken Moffat via blfs-support]

Again, I should mention Poppler
was the only problem package and the older version works well, but it would
be nice to know what I've done wrong.

(replying to this particular post because I could not see anywhere
obvious to put this) -

I'm starting to wonder if you built extra (qt) packages before
poppler in 8.3. One of google's matches for the include_next problem
noted that a .pro file from something had a line

INCLUDEPATH += /usr/include

and removing that line allowed the affected package (not poppler) to
build.

So, find what '*.pro' files you have, and edit any INCLUDEPATH lines
like that (or, better, copy the file(s) to something.pro.bak and
then change the .pro).

ĸen

[rhubarbpieguy via blfs-support]

Post by Ken Moffat via blfs-support

Again, I should mention Poppler
was the only problem package and the older version works well, but it would
be nice to know what I've done wrong.

(replying to this particular post because I could not see anywhere
obvious to put this) -
I'm starting to wonder if you built extra (qt) packages before
poppler in 8.3. One of google's matches for the include_next problem
noted that a .pro file from something had a line
INCLUDEPATH += /usr/include
and removing that line allowed the affected package (not poppler) to
build.
So, find what '*.pro' files you have, and edit any INCLUDEPATH lines
like that (or, better, copy the file(s) to something.pro.bak and
then change the .pro).
ĸen

I've compiled no qt packages to my knowledge.  I have no *.pro files if
I understand the question correctly.

[Ken Moffat via blfs-support]

Post by rhubarbpieguy via blfs-support
I receive the following error with the make and 'make install' Poppler
commands.  Poppler-data installs without error.
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
test/CMakeFiles/gtk-test.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
I have an ASCII text /usr/include/c++/8.2.0/cstdlib (-rw-r--r-- 6325).

As when you originally posted this, I do not recall seeing the
problem.

But I've now looked at one of my logs from building 0.67.0 (created
by adding ' >mylog 2>&1' or '>>...' after each command) and the one
thing that jumps out is that mine has the "progress markers" generated
by cmake, whereas yours looks more like the old CMMI although it is
referencing test/CMakeFiles/

[ 89%] Built target poppler-glib
Scanning dependencies of target gir-typelibs
Scanning dependencies of target pdf-inspector
Scanning dependencies of target gtk-test

and

[ 92%] Building C object glib/demo/CMakeFiles/poppler-glib-demo.dir/fonts.c.o
[ 91%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
[ 92%] Generating Poppler-0.18.typelib

Other than that, no ideas. 0.67.0 worked for me on 8.3, 0.68.0
built ok on svn from a week and a half ago - but I have not built
texlive from source, nor poppler-for-qt5. For PDF viewers and
inkscape, 0.68.0 seems to be working fine.

And if missing the change to cmake was the problem - join the club!
(in my case, one package moved to meson/ninja although it still
built and installed with CMMI and I only noticed the change in
responding to a different problem elsewhere.)

But if you did use cmake, I guess you'll have to follow Michael's
recommendations to debug it. In that case, good luck, particularly
if you need to raise it upstream.

ĸen

[rhubarbpieguy via blfs-support]

On 10/11/18 9:57 PM, Michael Shell via blfs-support wrote:

On Thu, 11 Oct 2018 17:58:44 -0500
We want to see not just the error message, but the actual g++ command
line that caused the error.

When you build via:

make VERBOSE=1

you should be able to see all the gcc/g++ commands as they are being
executed, long lines like:

/usr/bin/c++  -DUSE_OPENJPEG2 -Dpoppler_EXPORTS -I....

Do you see all that? The one that tries to compile gtk-test.cc
just before the error message is the one we are interested in.


   Cheers,

   Mike


That's clearer; I hope this is what you want.  I earlier referred to two
batches of Error 2 errors, but I included the make install output by
accident.


[ 89%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
cd /sources/poppler-0.67.0/build/test && /usr/bin/c++ -DUSE_OPENJPEG2
-I/sources/poppler-0.67.0 -I/sources/poppler-0.67.0/fofi
-I/sources/poppler-0.67.0/goo -I/sources/poppler-0.67.0/poppler
-I/sources/poppler-0.67.0/build -I/sources/poppler-0.67.0/build/poppler
-I/sources/poppler-0.67.0/glib -I/sources/poppler-0.67.0/build/glib
-I/usr/include/openjpeg-2.3 -isystem /usr/include/freetype2 -isystem
/usr/include/gtk-3.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem
/usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem
/usr/lib/dbus-1.0/include -isystem /usr/include/gio-unix-2.0 -isystem
/usr/include/cairo -isystem /usr/include/libdrm -isystem
/usr/include/pango-1.0 -isystem /usr/include/fribidi -isystem
/usr/include/atk-1.0 -isystem /usr/include/pixman-1 -isystem
/usr/include/uuid -isystem /usr/include/harfbuzz -isystem
/usr/include/libpng16 -isystem /usr/include/gdk-pixbuf-2.0 -isystem
/usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem
//usr/include  -Wall -Wextra -Wpedantic -Wno-unused-parameter
-Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op
-Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual
-Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant
-Wsuggest-override -fno-exceptions -fno-check-new -fno-common
-D_DEFAULT_SOURCE -O2 -DNDEBUG -I/usr/include/nss -I/usr/include/nspr
-pthread -std=c++11 -o CMakeFiles/gtk-test.dir/gtk-test.cc.o -c
/sources/poppler-0.67.0/test/gtk-test.cc
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from /sources/poppler-0.67.0/goo/GooString.h:42,
                 from /sources/poppler-0.67.0/poppler/Object.h:45,
                 from /sources/poppler-0.67.0/poppler/GfxState.h:43,
                 from /sources/poppler-0.67.0/splash/SplashBitmap.h:39,
                 from /sources/poppler-0.67.0/test/gtk-test.cc:9:
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
make[2]: *** [test/CMakeFiles/gtk-test.dir/build.make:63:
test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
make[2]: Leaving directory '/sources/poppler-0.67.0/build'
make[1]: *** [CMakeFiles/Makefile2:803:
test/CMakeFiles/gtk-test.dir/all] Error 2
make[1]: Leaving directory '/sources/poppler-0.67.0/build'
make: *** [Makefile:141: all] Error 2


The first occurrence I see of Dpoppler prior to the error is as follows:

[ 79%] Building CXX object
glib/CMakeFiles/poppler-glib.dir/__/poppler/CairoRescaleBox.cc.o
cd /sources/poppler-0.67.0/build/glib && /usr/bin/c++
-DG_LOG_DOMAIN=\"Poppler\" -DUSE_OPENJPEG2 -Dpoppler_glib_EXPORTS
-I/sources/poppler-0.67.0 -I/sources/poppler-0.67.0/fofi
-I/sources/poppler-0.67.0/goo -I/sources/poppler-0.67.0/poppler
-I/sources/poppler-0.67.0/build -I/sources/poppler-0.67.0/build/poppler
-I/sources/poppler-0.67.0/glib -I/sources/poppler-0.67.0/build/glib
-I/usr/include/freetype2 -I/usr/include/openjpeg-2.3 -isystem
/usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem
/usr/include/cairo -Wall -Wextra -Wpedantic -Wno-unused-parameter
-Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op
-Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual
-Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant
-Wsuggest-override -fno-exceptions -fno-check-new -fno-common
-D_DEFAULT_SOURCE -O2 -DNDEBUG  -fPIC   -I/usr/include/nss
-I/usr/include/nspr -pthread  -DG_DISABLE_DEPRECATED
-DG_DISABLE_SINGLE_INCLUDES -pthread -std=c++11 -o
CMakeFiles/poppler-glib.dir/__/poppler/CairoRescaleBox.cc.o -c
/sources/poppler-0.67.0/poppler/CairoRescaleBox.cc

[Bruce Dubbs via blfs-support]

Post by rhubarbpieguy via blfs-support
In file included from /usr/include/c++/8.2.0/ext/string_conversions.h:41,
                 from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                 from /usr/include/c++/8.2.0/string:52,
                 from /sources/poppler-0.67.0/goo/GooString.h:42,
                 from /sources/poppler-0.67.0/poppler/Object.h:45,
                 from /sources/poppler-0.67.0/poppler/GfxState.h:43,
                 from /sources/poppler-0.67.0/splash/SplashBitmap.h:39,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.

I have seen this before, but in LFS. This type of error seems to be an
issue with the glibc or gcc build from LFS Chapter 6. I have never been
able to pin down exactly what build error causes this, but my solution
for students is to go back and restart Chapter 6.

I know you do not want to hear this, but you have a problem with your
tool chain. At a minimum, you should have:

/usr/include/bits/stdlib.h
/usr/include/c++/8.2.0/tr1/stdlib.h
/usr/include/c++/8.2.0/stdlib.h
/usr/include/stdlib.h

-- Bruce

[rhubarbpieguy via blfs-support]

Post by rhubarbpieguy via blfs-support
In file included from
/usr/include/c++/8.2.0/ext/string_conversions.h:41,
                  from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                  from /usr/include/c++/8.2.0/string:52,
                  from /sources/poppler-0.67.0/goo/GooString.h:42,
                  from /sources/poppler-0.67.0/poppler/Object.h:45,
                  from /sources/poppler-0.67.0/poppler/GfxState.h:43,
                  from /sources/poppler-0.67.0/splash/SplashBitmap.h:39,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
  #include_next <stdlib.h>
                ^~~~~~~~~~
compilation terminated.

I have seen this before, but in LFS.  This type of error seems to be
an issue with the glibc or gcc build from LFS Chapter 6.  I have never
been able to pin down exactly what build error causes this, but my
solution for students is to go back and restart Chapter 6.
I know you do not want to hear this, but you have a problem with your
/usr/include/bits/stdlib.h
/usr/include/c++/8.2.0/tr1/stdlib.h
/usr/include/c++/8.2.0/stdlib.h
/usr/include/stdlib.h
  -- Bruce

OK, it's not that big a deal to redo LFS 8.3.  I've nuked all my log
files but don't remember a problem with the output of "Adjusting the
Toolchain."  Regardless, I'll go again and save that output.  I'll
repost either way to this topic with the outcome.

[Bruce Dubbs via blfs-support]

Post by rhubarbpieguy via blfs-support

Post by rhubarbpieguy via blfs-support
In file included from
/usr/include/c++/8.2.0/ext/string_conversions.h:41,
                  from /usr/include/c++/8.2.0/bits/basic_string.h:6391,
                  from /usr/include/c++/8.2.0/string:52,
                  from /sources/poppler-0.67.0/goo/GooString.h:42,
                  from /sources/poppler-0.67.0/poppler/Object.h:45,
                  from /sources/poppler-0.67.0/poppler/GfxState.h:43,
                  from /sources/poppler-0.67.0/splash/SplashBitmap.h:39,
/usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such
file or directory
  #include_next <stdlib.h>
                ^~~~~~~~~~
compilation terminated.

I have seen this before, but in LFS.  This type of error seems to be
an issue with the glibc or gcc build from LFS Chapter 6.  I have never
been able to pin down exactly what build error causes this, but my
solution for students is to go back and restart Chapter 6.
I know you do not want to hear this, but you have a problem with your
/usr/include/bits/stdlib.h
/usr/include/c++/8.2.0/tr1/stdlib.h
/usr/include/c++/8.2.0/stdlib.h
/usr/include/stdlib.h

OK, it's not that big a deal to redo LFS 8.3.  I've nuked all my log
files but don't remember a problem with the output of "Adjusting the
Toolchain."  Regardless, I'll go again and save that output.  I'll
repost either way to this topic with the outcome.

Also, take a look at
http://anduin.linuxfromscratch.org/~bdubbs/sanity.html. If you are
using the -dev book (or systemd), there are probably differences, but
they should be very few if checking after gcc in Chapter 6.

-- Bruce

[Michael Shell via blfs-support]

On Sun, 14 Oct 2018 21:23:06 -0500

Post by rhubarbpieguy via blfs-support
OK, it's not that big a deal to redo LFS 8.3.  I've nuked all my log
files but don't remember a problem with the output of "Adjusting the
Toolchain."  Regardless, I'll go again and save that output.  I'll
repost either way to this topic with the outcome.

Wait on that. At this point, I do not think it is a problem with your
system. You have already indicated that your system has all the include
files Bruce asked about.

I believe I see a mistake in the poppler source code. Try my latest poppler
patch tests first and then we'll go from that.


Bruce, Ken: have you tried compiling poppler 0.63 or later on a system with:

1. GTK3 v3.8 or later
<and>
2. gcc 8.2

Did you build poppler *before* GTK3 is installed, or are you using a gcc prior
to 8.2?


Cheers,

Mike

[Bruce Dubbs via blfs-support]

Post by Michael Shell via blfs-support
On Sun, 14 Oct 2018 21:23:06 -0500

Post by rhubarbpieguy via blfs-support
OK, it's not that big a deal to redo LFS 8.3.  I've nuked all my log
files but don't remember a problem with the output of "Adjusting the
Toolchain."  Regardless, I'll go again and save that output.  I'll
repost either way to this topic with the outcome.

Wait on that. At this point, I do not think it is a problem with your
system. You have already indicated that your system has all the include
files Bruce asked about.
I believe I see a mistake in the poppler source code. Try my latest poppler
patch tests first and then we'll go from that.
1. GTK3 v3.8 or later
<and>
2. gcc 8.2

Yes.

Sun Aug 19 16:59:53 CDT 2018 /usr/src/gtk3/gtk+-3.22.30.tar.xz
gcc (GCC) 8.2.0 (LFS 8,3)

Post by Michael Shell via blfs-support
Did you build poppler *before* GTK3 is installed, or are you using a gcc prior
to 8.2?

Tue Aug 21 12:21:47 CDT 2018 /usr/src/poppler/poppler-0.67.0.tar.xz
Sat Sep 8 22:20:00 CDT 2018 /usr/src/poppler/poppler-0.68.0.tar.xz
Sun Oct 7 22:54:36 CDT 2018 /usr/src/poppler/poppler-0.69.0.tar.xz

I have had no problems when building poppler using the instructions in BLFS.

-- Bruce

[Michael Shell via blfs-support]

On Mon, 15 Oct 2018 00:31:15 -0500

Yes.

Bruce,

OK, could run the following build test on poppler 0.67 applying the
attached poppler_gtk-test_force_build_fail.patch (and no other patches):


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


The build should fail at gtk-test.cc. Show us the c++ command line
for gtk-test.cc. Then we can compare how your c++ is being invoked to
build gtk-test.cc to that of rhubarbpieguy.

If the build does *not* fail, can you explain why there is no build
attempt for test/gtk-test.cc on your system (e.g., GTK3 not detected,
etc.)?


Cheers,

Mike

[Bruce Dubbs via blfs-support]

Post by Michael Shell via blfs-support
On Mon, 15 Oct 2018 00:31:15 -0500

Yes.

Bruce,
OK, could run the following build test on poppler 0.67 applying the
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
The build should fail at gtk-test.cc. Show us the c++ command line
for gtk-test.cc.

[ 54%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
cd /usr/src/poppler/poppler-0.67.0/build/test && /usr/bin/c++
-DUSE_OPENJPEG2 -I/usr/src/poppler/poppler-0.67.0
-I/usr/src/poppler/poppler-0.67.0/fofi
-I/usr/src/poppler/poppler-0.67.0/goo
-I/usr/src/poppler/poppler-0.67.0/poppler
-I/usr/src/poppler/poppler-0.67.0/build
-I/usr/src/poppler/poppler-0.67.0/build/poppler
-I/usr/src/poppler/poppler-0.67.0/glib
-I/usr/src/poppler/poppler-0.67.0/build/glib -I/usr/include/openjpeg-2.3
-isystem /usr/include/freetype2 -isystem /opt/xorg/include/libdrm
-isystem /usr/include/gtk-3.0 -isystem /usr/include/at-spi2-atk/2.0
-isystem /usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem
/usr/lib/dbus-1.0/include -isystem /usr/include/gio-unix-2.0 -isystem
/usr/include/cairo -isystem /usr/include/pango-1.0 -isystem
/usr/include/fribidi -isystem /usr/include/atk-1.0 -isystem
/usr/include/pixman-1 -isystem /usr/include/harfbuzz -isystem
/usr/include/libpng16 -isystem /usr/include/libmount -isystem
/usr/include/blkid -isystem /usr/include/uuid -isystem
/usr/include/gdk-pixbuf-2.0 -isystem /usr/include/glib-2.0 -isystem
/usr/lib/glib-2.0/include -Wall -Wextra -Wpedantic
-Wno-unused-parameter -Wcast-align -Wformat-security
-Wframe-larger-than=65536 -Wlogical-op -Wmissing-format-attribute
-Wnon-virtual-dtor -Woverloaded-virtual -Wmissing-declarations -Wundef
-Wzero-as-null-pointer-constant -Wsuggest-override -fno-exceptions
-fno-check-new -fno-common -D_DEFAULT_SOURCE -O2 -DNDEBUG
-I/usr/include/nss -I/usr/include/nspr -pthread -std=c++11 -o
CMakeFiles/gtk-test.dir/gtk-test.cc.o -c
/usr/src/poppler/poppler-0.67.0/test/gtk-test.cc
/usr/src/poppler/poppler-0.67.0/test/gtk-test.cc:24:10: fatal error:
thisdoesnotexist.h: No such file or directory
#include <thisdoesnotexist.h>
^~~~~~~~~~~~~~~~~~~~
compilation terminated.

Let me make that a bit more readable:

/usr/bin/c++
-DUSE_OPENJPEG2
-I/usr/src/poppler/poppler-0.67.0
-I/usr/src/poppler/poppler-0.67.0/fofi
-I/usr/src/poppler/poppler-0.67.0/goo
-I/usr/src/poppler/poppler-0.67.0/poppler
-I/usr/src/poppler/poppler-0.67.0/build
-I/usr/src/poppler/poppler-0.67.0/build/poppler
-I/usr/src/poppler/poppler-0.67.0/glib
-I/usr/src/poppler/poppler-0.67.0/build/glib
-I/usr/include/openjpeg-2.3
-isystem /usr/include/freetype2
-isystem /opt/xorg/include/libdrm
-isystem /usr/include/gtk-3.0
-isystem /usr/include/at-spi2-atk/2.0
-isystem /usr/include/at-spi-2.0
-isystem /usr/include/dbus-1.0
-isystem /usr/lib/dbus-1.0/include
-isystem /usr/include/gio-unix-2.0
-isystem /usr/include/cairo
-isystem /usr/include/pango-1.0
-isystem /usr/include/fribidi
-isystem /usr/include/atk-1.0
-isystem /usr/include/pixman-1
-isystem /usr/include/harfbuzz
-isystem /usr/include/libpng16
-isystem /usr/include/libmount
-isystem /usr/include/blkid
-isystem /usr/include/uuid
-isystem /usr/include/gdk-pixbuf-2.0
-isystem /usr/include/glib-2.0
-isystem /usr/lib/glib-2.0/include
-Wall -Wextra -Wpedantic -Wno-unused-parameter
-Wcast-align -Wformat-security -Wframe-larger-than=65536
-Wlogical-op -Wmissing-format-attribute -Wnon-virtual-dtor
-Woverloaded-virtual -Wmissing-declarations -Wundef
-Wzero-as-null-pointer-constant -Wsuggest-override
-fno-exceptions -fno-check-new -fno-common
-D_DEFAULT_SOURCE -O2 -DNDEBUG
-I/usr/include/nss
-I/usr/include/nspr
-pthread -std=c++11
-o CMakeFiles/gtk-test.dir/gtk-test.cc.o -c
/usr/src/poppler/poppler-0.67.0/test/gtk-test.cc

-- Bruce

[Ken Moffat via blfs-support]

Post by Michael Shell via blfs-support
1. GTK3 v3.8 or later
<and>
2. gcc 8.2
Did you build poppler *before* GTK3 is installed, or are you using a gcc prior
to 8.2?

For all my 8.3 desktop builds:

gcc-8.2.0
gtk+-3.22.30
poppler-0.67.0

built in that order.

ĸen

[Michael Shell via blfs-support]

On Sun, 14 Oct 2018 14:28:01 -0500

Post by rhubarbpieguy via blfs-support
[ 89%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
..
/usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem
//usr/include  -Wall -Wextra -Wpedantic -Wno-unused-parameter
..

Good! Note the strange/suspicious include construct:

-isystem //usr/include


Now, for the next test, try the following two attached patches on poppler
0.67 (should work on any version 0.63 or later) without using any other
patches (starting with a fresh poppler 0.67 unpack):

patch -p1 -i ../poppler_revert_gtk3_include_dirs.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


The build will fail, but in a different way (as is intended so you can
easily locate the same c++ command line). Show us the c++ command line
that failed (but it would have worked had it not been for
poppler_gtk-test_force_build_fail.patch) so we can compare it to the
previous failure.


Then, test the new attached poppler_fix_cmake_gtk3_include_dir.patch on
poppler 0.67 (should work on any version 0.63 or later) *without* using
any other patches (starting with a fresh poppler 0.67 unpack):

patch -p1 -i ../poppler_fix_cmake_gtk3_include_dir.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 let us know if it compiles OK and, if not, show us the c++ command
line that failed.


Mike

[rhubarbpieguy via blfs-support]

Post by Michael Shell via blfs-support
On Sun, 14 Oct 2018 14:28:01 -0500

Post by rhubarbpieguy via blfs-support
[ 89%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
..
/usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem
//usr/include  -Wall -Wextra -Wpedantic -Wno-unused-parameter
..

-isystem //usr/include
Now, for the next test, try the following two attached patches on poppler
0.67 (should work on any version 0.63 or later) without using any other
patch -p1 -i ../poppler_revert_gtk3_include_dirs.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
The build will fail, but in a different way (as is intended so you can
easily locate the same c++ command line). Show us the c++ command line
that failed (but it would have worked had it not been for
poppler_gtk-test_force_build_fail.patch) so we can compare it to the
previous failure.
Then, test the new attached poppler_fix_cmake_gtk3_include_dir.patch on
poppler 0.67 (should work on any version 0.63 or later) *without* using
patch -p1 -i ../poppler_fix_cmake_gtk3_include_dir.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 let us know if it compiles OK and, if not, show us the c++ command
line that failed.
Mike

Poppler 0.67 compiles without error using
poppler_fix_cmake_gtk3_include_dir.patch.

The error messages using the other two patches are:

[ 89%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
cd /sources/Poppler/poppler-0.67.0/build/test && /usr/bin/c++ -DUSE_OPENJPEG2 -I/sources/Poppler/poppler-0.67.0 -I/sources/Poppler/poppler-0.67.0/fofi -I/sources/Poppler/poppler-0.67.0/goo -I/sources/Poppler/poppler-0.67.0/poppler -I/sources/Poppler/poppler-0.67.0/build -I/sources/Poppler/poppler-0.67.0/build/poppler -I/sources/Poppler/poppler-0.67.0/glib -I/sources/Poppler/poppler-0.67.0/build/glib -I/usr/include/freetype2 -I/usr/include/openjpeg-2.3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -Wcast-align -Wformat-security -Wframe-larger-than=65536 -Wlogical-op -Wmissing-format-attribute -Wnon-virtual-dtor -Woverloaded-virtual -Wmissing-declarations -Wundef -Wzero-as-null-pointer-constant -Wsuggest-override -fno-exceptions -fno-check-new -fno-common -D_DEFAULT_SOURCE -O2 -DNDEBUG -I/usr/include/nss -I/usr/include/nspr -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/libdrm -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I//usr/include -pthread -std=c++11 -o CMakeFiles/gtk-test.dir/gtk-test.cc.o -c /sources/Poppler/poppler-0.67.0/test/gtk-test.cc
/sources/Poppler/poppler-0.67.0/test/gtk-test.cc:24:10: fatal error: thisdoesnotexist.h: No such file or directory
#include <thisdoesnotexist.h>
^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [test/CMakeFiles/gtk-test.dir/build.make:63: test/CMakeFiles/gtk-test.dir/gtk-test.cc.o] Error 1
make[2]: Leaving directory '/sources/Poppler/poppler-0.67.0/build'
make[1]: *** [CMakeFiles/Makefile2:803: test/CMakeFiles/gtk-test.dir/all] Error 2
make[1]: Leaving directory '/sources/Poppler/poppler-0.67.0/build'
make: *** [Makefile:141: all] Error 2

[Michael Shell via blfs-support]

On Mon, 15 Oct 2018 14:40:12 -0500

Post by rhubarbpieguy via blfs-support
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

Post by rhubarbpieguy via blfs-support
-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

[Bruce Dubbs via blfs-support]

Post by Michael Shell via blfs-support
In the meantime, Bruce and rhubarbpieguy, what version of cmake are
each of you running?
cmake --version

From my log:

Tue Aug 14 20:50:28 CDT 2018 /usr/src/cmake/cmake-3.12.1.tar.gz
Tue Aug 21 12:21:47 CDT 2018 /usr/src/poppler/poppler-0.67.0.tar.xz
Sat Sep 8 22:20:00 CDT 2018 /usr/src/poppler/poppler-0.68.0.tar.xz
Sun Sep 9 14:32:40 CDT 2018 /usr/src/cmake/cmake-3.12.2.tar.gz
Sun Oct 7 22:54:36 CDT 2018 /usr/src/poppler/poppler-0.69.0.tar.xz
Tue Oct 9 13:43:46 CDT 2018 /usr/src/cmake/cmake-3.12.3.tar.gz

And the partial test today.

Note that I have not had any problem with any of the above.

-- Bruce

[rhubarbpieguy via blfs-support]

This post might be inappropriate. Click to display it.

[Michael Shell via blfs-support]

On Mon, 15 Oct 2018 21:31:36 -0500

Post by rhubarbpieguy via blfs-support
-I//usr/include

Again that is there. Where is this strange path coming from?

Post by rhubarbpieguy via blfs-support
/etc/udev/hwdb.d/60-keyboard.hwdb:# ZZZZ is the bus-id (see /usr/include/linux/input.h BUS_*), YYYY, XXXX and
/etc/udev/hwdb.d/70-pointingstick.hwdb:# ZZZZ is the bus-id (see /usr/include/linux/input.h BUS_*), YYYY, XXXX and

This looks OK to me. All of your files in /etc are free of /usr/include .

Here's a working theory - in your BLFS build scripts, could there be a
mistake whereby --prefix=/usr is incorrectly set to --prefix=//usr
possibly with regard to the GTK3 package. Something like /$PREFIX in
a script (where $PREFIX=/usr) could do it.

You can scan all your /usr pkgconfig files for any mention of //usr via:

find /usr/lib/pkgconfig -type f -name "*.pc" -print|sort|xargs grep //usr

Can you see/find anything like that?


Mike

[Michael Shell via blfs-support]

rhubarbpieguy,

For a 0.67 poppler release after the cmake command has been run (I don't
think it matters if the make step was later run and whether or not the
build was actually successful, but you have to do the

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..

step) take a look at the resulting build/CMakeCache.txt file.

Do you see any //usr directories mentioned in there? Can you post your
CMakeCache.txt for us to look at, or email it to me, if you wish.

Another thing to try (as above, do this after cmake was run, but you
don't have to do the make step), after changing to the build dir
(cd build), do a:

find . -type f -print|sort|xargs grep //usr

to search for all instances of //usr in files within the build directory.


Mike