Re: pkg/50173: devel/libelf BUILDLINK_INCDIRS.libelf?= include/libelf

[David Shao <davshao%gmail.com@localhost>]

The following reply was made to PR pkg/50173; it has been noted by GNATS.

From: David Shao <davshao%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/50173: devel/libelf BUILDLINK_INCDIRS.libelf?= include/libelf
Date: Sat, 5 Sep 2015 19:37:10 -0700

 On Sat, Sep 5, 2015 at 6:20 PM, David Holland <dholland-pbugs%netbsd.org@localhost> wrote:
 > The following reply was made to PR pkg/50173; it has been noted by GNATS.
 >
 > From: David Holland <dholland-pbugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: pkg/50173: devel/libelf BUILDLINK_INCDIRS.libelf?= include/libelf
 > Date: Sun, 6 Sep 2015 01:19:36 +0000
 >
 >  On Wed, Aug 26, 2015 at 07:10:01AM +0000, davshao%gmail.com@localhost wrote:
 >   > Similar to x11/libdrm, devel/libelf in its buildlink3.mk could use
 >   >
 >   > BUILDLINK_INCDIRS.libelf?=  include/libelf
 >   >
 >   > This problem was not seen in MesaLib until adding various options
 >   > to build glamor etc. exposed a file that had an include of the form
 >   >
 >   > #include <gelf>
 >   >
 >   >   CC       radeon_elf_util.lo
 >   > radeon_elf_util.c:32:18: fatal error: gelf.h: No such file or directory
 >   > compilation terminated.
 >
 >  Is this the officially intended API of the package, or should MesaLib
 >  be patched to use <libelf/gelf.h> instead?
 >
 >  --
 >  David A. Holland
 >  dholland%netbsd.org@localhost
 >
 
 From /usr/pkg/lib/pkgconfig/libelf.pc:
 
 prefix=/usr/pkg
 exec_prefix=${prefix}
 libdir=${exec_prefix}/lib
 includedir=${prefix}/include
 
 Name: libelf
 Description: ELF object file access library
 Version: 0.8.13
 Requires:
 Conflicts:
 Libs: -Wl,-R${libdir} -L${libdir} -lelf
 Cflags: -I${includedir}/libelf -I${includedir}
 
 Therefore I conclude that the proper API indeed uses
 #include <gelf.h>
 
 Where MesaLib might need to be patched somewhere is that for libelf it
 is using a manually crafted test for libelf support in configure:
 
 if ${ac_cv_lib_elf_elf_memory+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
 LIBS="-lelf  $LIBS"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
 /* Override any GCC internal prototype to avoid an error.
    Use char because int might match the return type of a GCC
    builtin and then its argument prototype would still apply.  */
 #ifdef __cplusplus
 extern "C"
 #endif
 char elf_memory ();
 int
 main ()
 {
 return elf_memory ();
   ;
   return 0;
 }
 _ACEOF
 if ac_fn_c_try_link "$LINENO"; then :
   ac_cv_lib_elf_elf_memory=yes
 else
   ac_cv_lib_elf_elf_memory=no
 fi
 rm -f core conftest.err conftest.$ac_objext \
     conftest$ac_exeext conftest.$ac_ext
 LIBS=$ac_check_lib_save_LIBS
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_elf_elf_memory" >&5
 $as_echo "$ac_cv_lib_elf_elf_memory" >&6; }
 if test "x$ac_cv_lib_elf_elf_memory" = xyes; then :
   have_libelf=yes;ELF_LIB=-lelf
 fi
 
 But I do not know whether it is more accepted to search or not search
 for the pkg-config libelf.pc.
 
 The major customer of libelf, devel/glib2, already has a pkg-config
 check in configure:
 
 if test -n "$LIBELF_CFLAGS"; then
     pkg_cv_LIBELF_CFLAGS="$LIBELF_CFLAGS"
  elif test -n "$PKG_CONFIG"; then
     if test -n "$PKG_CONFIG" && \
     { { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists
 --print-errors \"libelf >= 0.8.12\""; } >&5
   ($PKG_CONFIG --exists --print-errors "libelf >= 0.8.12") 2>&5
   ac_status=$?
   $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
   test $ac_status = 0; }; then
   pkg_cv_LIBELF_CFLAGS=`$PKG_CONFIG --cflags "libelf >= 0.8.12" 2>/dev/null`
               test "x$?" != "x0" && pkg_failed=yes