cannot build on opensuse

[olesenm]

Issue reported offline to @gllort, but added here for completeness and to provide an issue number.

Building the extrae-4.0.6 release on openSUSE 15.4 fails since it is unable to properly test/find some binutils libraries, even when the corresponding devel package has been installed.

In the openSUSE install, binutils package includes these files:

/usr/lib64/libbfd-2.41.0.20230908-150100.7.46.so
/usr/lib64/libsframe.so.1.0.0
/usr/lib64/libsframe.so.1  -> /usr/lib64/libsframe.so.1.0.0

The binutils-devel package includes these further files:

/usr/lib64/libiberty.a
/usr/lib64/libsframe.a
/usr/lib64/libsframe.so  -> /usr/lib64/libsframe.so.1.0.0

The configure script only respects the --with-binutils= option, not the --with-binutils-libs option etc, so there is only a moderate chance to guide things.

Taking a deep dig into the config scripts. The AX_PROG_BINUTILS macro defined in the config/macros.m4 file does actually go the extra distance to find odd library names:

        dnl Try something more automatic using find command
        libbfd_lib=""

        if test -d ${binutils_home_dir}/lib${BITS} ; then
           nlibbfd=`find ${binutils_home_dir}/lib${BITS} -name libbfd\*.so | wc -l`
           if test ${nlibbfd} -ge 1 ; then
              libbfd_lib=`find ${binutils_home_dir}/lib${BITS} -name libbfd\*.so | head -1`
           fi
        fi

However, this is only used to establish initial success and the directory location:

            if test "${libbfd_lib}" != "" ; then
               BFD_LIBSDIR=`dirname ${libbfd_lib}`
            fi

Linking further on will still attempt to link against libbfd.so and then fail miserably.

[gllort]

Dear @olesenm, we are in the process of removing support for binutils entirely due to licensing conflicts. We are currently evaluating elfutils as a replacement, but the call has yet to be made. Considering that binutils has to go imminently, we won't be releasing a new public version with this patch. However, I can suggest a couple of quick workarounds to get you going temporarily. On one hand, you can add an argument in the AX_PROG_BINUTILS macro to pass a custom bfd library name, something like:

AC_ARG_WITH(bfd-lib-name,
AC_HELP_STRING(
[--with-bfd-lib-name@<:@=library name@:>@],
[specify the name of the GNU Binutils BFD library]
),
[bfd_lib_name=${withval}],
[bfd_lib_name="not_set"]
)

Then change the several references in this macro to libbfd.so / libbfd.a / -lbfd into the value of the variable ${bfd_lib_name}.

And configure with the extra arg: --with-bfd-lib-name=bfd-2.41.0.20230908-150100.7.46

Alternatively, to avoid tweaking the sources, you could simply create a local temporary folder with softlinks to the files installed by the binutils package, following the directory structure and library naming that Extrae is expecting, for example:

mkdir -p proxy-binutils/lib
ln -s /usr/lib64/libbfd-2.41.0.20230908-150100.7.46.so proxy-binutils/lib/libbfd.so

Then configure with --with-binutils=./proxy-binutils. With this alternative, you probably need to softlink a couple of libraries (libbfd & libiberty) and headers (bfd.h), in your proxy-binutils folder:

ln -s /usr/lib64/libiberty.a proxy-binutils/lib/
mkdir -p proxy-binutils/include
ln -s <path-to-bfd.h> proxy-binutils/include/

Would this trick work for you?

[olesenm]

Dear @olesenm, we are in the process of removing support for binutils entirely due to licensing conflicts. We are currently evaluating elfutils as a replacement, but the call has yet to be made. Considering that binutils has to go imminently, we won't be releasing a new public version with this patch.

I will take a look at the workaround, but the timing is now a bit unfortunate at the moment (which means it won't be for a few weeks). Changing to elfutils sounds like an interesting plan - I hope that this will reduce some of the dependency and configuration problems. Please let me know (email would be best) if you have a first beta-test with elfutils that I should try to compile on my system.