How does this relate to https://spack.readthedocs.io/en/latest/getting_started.html?highlight=binutils#binutils? Is this something that can be fixed by having a newer version of binutils in your PATH, or does this package actually directly depend on the binutils libraries?

Adding @lee218llnl -- I am not sure this is something we want to do. It's always a pain to remember the right way to add libiberty.

I take it for granted that libiberty is already installed on our systems. It would be nice if we could add libiberty as a conditional dependence in the case where it is not there. I guess libiberty could be made a virtual package, but then users who already have a system install would be burdened with defining it as an external package.

Binutils (or equivalent) has to be on the system, or else you can't
build anything. Libiberty almost certainly is on the system, but not
necessarily compiled with -fPIC. Both might be old.

Let me suggest another solution. I'd like to add a new package
'libiberty' that uses the binutils tarball and builds just libiberty.

That way, I could build libiberty static + fPIC, and link that into
dyninst. Problem solved, and it doesn't pull in binutils at all.
This is what we do for hpctoolkit.

The problem for dyninst is that you need libiberty built with -fPIC.
You can build it from binutils, but then you have to build all of
binutils with -fPIC, and maybe you don't want that. Libiberty is
tiny, so just build it special and take binutils out of the equation.

@mwkrentel: I actually really like that idea. Do you mind doing the PR?

One minor annoyance that you'll notice: if you do this, Spack will download the binutils tarball twice if you install both libiberty and binutils. We could avoid this by storing the tarballs by hash in mirrors (the var/spack/cache tarball cache is a mirror). But, we went for "easy to construct by hand" for some of our internal code teams who have lots of tarballs, and we cache tarballs in files with paths of the form <pkgname>/<pkgname>-<version>.<extension>.

Great! Exactly the answer I wanted to hear!

I already have a package.py file for this, at least one for my
(hpctoolkit) specific needs. I just need a couple minor adjustments
for a more general audience, check flake style, etc.

As for the multiple tar files, yes I've noticed that. I think there
are several natural solutions that would be wrong. You don't want to
put them all in one directory, that would become unwieldy.

You don't want to put then in a trie by the first few letters of the
hash, that would require a bunch more infrastructure just to find
anything.

You want to understand that this is an unusual case and that the other
99% works fine.

I suggest, create a per-package option that says, 'put my tar files
into this other package's directory.'

After we get the libiberty package committed, would you like me to
create an issue for this?

Sure.

I suggest, create a per-package option that says, 'put my tar files into this other package's directory.'

I think you can actually do better than this. Spack has (currently md5, soon sha256) checksums for all the downloads and could use them to set up that association without an option. It requires reading all the package.py files, but we do that already (for caching things like virtual dependency providers) in ~/.spack/misc. I think we could do something similar to check whether something's already been downloaded -- basically set up the hash index behind the scenes and refresh it when checksums fail, instead of imposing it on the mirror structure.

Ok, I've added PR #8912 for building libiberty solo from the binutils
tar file.

Libiberty always builds a static (.a) archive, but I added a variant
'fpic' to compile the code with -fPIC. With that option, it will link
into the Dyninst .so files.

I was able to edit the Dyninst recipe with just two things: add a
dependence on 'libiberty+fpic' and set -DIBERTY_LIBRARIES=%s to the
libiberty.a file (see below). With those edits, Dyninst built cleanly
for me. And I could tell from verbose output that it was picking up
my libiberty.a archive.

Actually, it built cleanly for me even without the patch. I guess my
Fedora 26 system comes with libiberty built with -fPIC, but that's not
something you can rely on.

Anyway, I believe this is a clean way of fixing your libiberty
problem. This is essentially what we've been doing to build Dyninst
for hpctoolkit for years (outside of spack). And, you don't have to
pull in binutils.

It also means that the libiberty code is built by spack, not from the
system. So, that removes one unclean piece.

Btw, any thoughts on possibly dropping support for Dyninst 8.x in
spack and drawing the line at a cmake build? I can tell things will
get more complicated in 10.x.

This was my patch. You'll want to think about a more complete patch.
For me, this was just the minimum I needed to test that all the pieces
fit together.

``--- a/var/spack/repos/builtin/packages/dyninst/package.py
+++ b/var/spack/repos/builtin/packages/dyninst/package.py
@@ -60,6 +60,8 @@ class Dyninst(Package):
depends_on("[email protected]:")
depends_on('cmake', type='build')

• depends_on('libiberty+fpic', type='link', when='@9.0.0:')
• patch('stat_dysect.patch', when='+stat_dysect')
  patch('stackanalysis_h.patch', when='@9.2.0')

@@ -77,6 +79,8 @@ class Dyninst(Package):

     with working_dir('spack-build', create=True):
         args = ['..',

•                '-DIBERTY_LIBRARIES=%s'     % join_path(
  

•                    spec['libiberty'].prefix.lib, 'libiberty.a'),
                 '-DBoost_INCLUDE_DIR=%s'    % spec['boost'].prefix.include,
                 '-DBoost_LIBRARY_DIR=%s'    % spec['boost'].prefix.lib,
                 '-DBoost_NO_SYSTEM_PATHS=TRUE',
  

I guess my attempt at 'code' formatting didn't work out too well.
The bullet points are actually '+' in diff for new lines added.
Well, you get the idea ....

And I should mention that I only tested the build for dyninst 'master'.
You should check if the cmake -D options for libiberty are different
in any of the earlier 9.x releases.

To prevent github from formatting you can surround a text block with three backticks "`" on either side:

```
+ Write anything you want here.
* The only exception is if it contains a lot of '`' characters
```

You can also format specific blocks by specifying diff after those 3 backticks:

  foo
+ bar
- baz

@sashanicolas,

My package for libiberty was merged this morning. This gives you a
simple solution for this PR. Redo your pull request with:

depends_on('libiberty+pic')

and then add -D... for the libiberty.a library. Note that libiberty
installs its library into lib64. (I think it's lib64 across all
platforms, but I'm not 100% on that.)

And you can probably close issue #8728 as a duplicate.

@sashanicolas @mwkrentel @adamjstewart @tgamblin @lee218llnl Just ran into this issue on a Power 9 system. Dyninst downloads a version of binutils that has a config.guess file from 2011 and configure can't figure out the build type for this newer platform. Adding:

depends_on('libiberty+pic')

to the dyninst/package.py got around the issue. Thanks for the work on this!

Can anyone accept or reject this?

If it were me, I would also add -DIBERTY_LIBRARIES=%s to the cmake
command because I like to be explicit about these things.

But I did test it with verbose mode and Dyninst does pick up the
spack-built libiberty over the system one, so it does seem to be
correct.

Merged! If you want to add @mwkrentel's suggestion later I'd be fine with that.