On 8/30/20 3:04 PM, Pierre Labastie via blfs-support wrote:
On Sat, 2020-08-29 at 20:20 -0400, Chris Gorman via blfs-support wrote:
Hello Again,
I believe I have found the culprit for my 'broken' search path for
gcc
and g++. In 'Introduction to Xorg-7' we are told to run the
following
if we are using a directory other than /usr as our $XORG_PREFIX. ...
cat >> /etc/profile.d/xorg.sh << "EOF"
pathappend $XORG_PREFIX/bin PATH
pathappend $XORG_PREFIX/lib/pkgconfig PKG_CONFIG_PATH
pathappend $XORG_PREFIX/share/pkgconfig PKG_CONFIG_PATH
pathappend $XORG_PREFIX/lib LIBRARY_PATH
pathappend $XORG_PREFIX/include C_INCLUDE_PATH
pathappend $XORG_PREFIX/include CPLUS_INCLUDE_PATH
ACLOCAL="aclocal -I $XORG_PREFIX/share/aclocal"
export PATH PKG_CONFIG_PATH ACLOCAL LIBRARY_PATH C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
EOF
The setting of C_INCLUDE_PATH and CPLUS_INCLUDE_PATH here cause a gcc
and g++ to change their search order, to put /usr/include at the
beginning of their search path. This breaks some builds like mesa.
To be clear, this was my fault as the note before this states to skip
these instructions if I am using /usr as my $XORG_PREFIX, which I am.
Hope this helps someone else.
Thanks a lot for the investigation and the finding. You are not the
first to run instructions for $XORG_PREFIX != /usr while setting
XORG_PREFIX=/usr... This generates several hard to debug failures. I
think we should explicitly have an if...fi pair around those
instructions (that would help jhalfs too :).
I think that's overkill. We have a note:
"If you've decided to use the standard /usr prefix, you can omit the
remainder of this page..."
I'm OK with changing the note to "Important".
Perhaps also change can change "can" to "must" with a bold must.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
