Recent

wildwizard · 05-16-2014, 07:07 PM

Recently I noticed that libelf was changed to symlink some headers around, this sort of thing always strikes me as a bit of a hack so I decided to have a closer look.

According to libelf's README file

Quote:

Note to distribution makers: You can install libelf in a separate root hierarchy by using the command ``make instroot=/my/root install''. You should also use the ``--enable-compat'' configure option in that case, or run ``make instroot=/my/root install-compat'' manually, to install all the required header files.

And from the Slackbuild

Code:

  --disable-compat \
make instroot=$PKG install || exit 1

Well we have the wrong options for a valid install and thus are missing the required headers resulting in programs failing to compile.

mancha · 05-16-2014, 07:52 PM

Would this change address the Mesa issue Robby Workman raised which prompted the symlinking to begin with?

Code:

--- a/libelf.SlackBuild
+++ b/libelf.SlackBuild
@@ -78,7 +78,7 @@ CFLAGS="$SLKCFLAGS" \
   --libdir=/usr/lib${LIBDIRSUFFIX} \
   --mandir=/usr/man \
   --infodir=/usr/info \
-  --disable-compat \
+  --enable-compat \
   --build=$ARCH-slackware-linux
 
 # Build:
@@ -87,11 +87,6 @@ make $NUMJOBS || make || exit 1
 # Install:
 make instroot=$PKG install || exit 1
 
-# Symlink headers to toplevel /usr/include:
-for header in $PKG/usr/include/libelf/* ; do
-  ln -s libelf/$(basename $header) $PKG/usr/include/$(basename $header)
-done
-
 # Strip binaries:
 ( cd $PKG
   find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

--mancha

wildwizard · 05-16-2014, 08:21 PM

It should as the problem as mentioned by Pat was that it couldn't see the headers, the option copies the headers into usr/include/* as well as usr/include/libelf/* with the exception of the 2 private headers.

If Mesa is trying to include the private headers then a bug should be raised against the Mesa project for it as both private headers have explicit warnings not to directly include them.

rworkman · 05-17-2014, 01:54 PM

Yeah, I think it will. Mesa 10.0.x and 10.1.x couldn't find gelf.h or libelf.h, even though both were installed on the system. It looks like the --enable-compat option will fix that, as it puts both of those headers in toplevel /usr/include/, and mesa would have found them there. Mesa should have checked pkg-config for the header location, which would have told it to look in both /usr/include/ and /usr/include/libelf/, so I still think it's a *minor* bug in Mesa (currently Mesa assumes that the --enable-compat option was passed to libelf *and* that libelf is installed in /usr

Anyway, I just kicked off a rebuild of mesa-10.1.3 to make sure all is well with it after changing libelf's build.