The problem is an unfortunate incompatibility of licenses: perf is GPLv2, not GPLv2+, and libbfd is GPLv3+
That’s really stupid. Wait, why do people think that license compatibility matters for dynamic linking again? Isn’t it completely nuts to think that linking things dynamically creates a derivative work? Who does the “derivation” exactly? rtld in memory? By that line of thinking, running a GPLed program on Windows would imply that Windows needs to comply with the GPL.
(Also, regardless of that, why don’t the maintainers of these projects see this and think, “I’ll add the + or at least a special exception to fix this”?)
It’s only a problem for distros that only let privileged developers submit binary packages, because of redistribution problems. I’m currently on NixOS and my version of perf is linked with libbfd.
If a distro only uses ports trees, then distributing binaries is an optimization rather than an essential part of software delivery. Ports trees generally work around composition issues because end users are allowed to run nearly any combination of software on their personal computers.
I see, that definitely makes sense when you explain it that way.
Yet it still feels weird to me, as I can easily download the deb src package to build and install manually. Even though it’a different from a ports tree in structure (deb src packages are tools for making the binary distribution, ports packages are optimizations of a source distribution), from an end user perspective it’s just different ergonomics.
The key difference is probably how options are specified. As I understand it, a deb src package contains a recipe for building a .deb binary package. In contrast, a port typically contains a recipe for building a set of binary packages. Some of these may permit binary redistribution, others don’t. When the FreeBSD package build infrastructure runs, it will not build configurations that don’t allow binary distribution, but if you run poudriere locally then you can enable these options.
Of course, perf could just link to LLVM’s Symbolizer library and get this functionality without any problems, but that’s probably a hard sell at Red Hat, which employs most of the GNU toolchain developers.
Since it’s only one operation that perf needs and they likely don’t need to support esoteric formats, maybe addr2line could be reimplemented without too much hassle?
That’s really stupid. Wait, why do people think that license compatibility matters for dynamic linking again? Isn’t it completely nuts to think that linking things dynamically creates a derivative work? Who does the “derivation” exactly?
rtldin memory? By that line of thinking, running a GPLed program on Windows would imply that Windows needs to comply with the GPL.(Also, regardless of that, why don’t the maintainers of these projects see this and think, “I’ll add the + or at least a special exception to fix this”?)
The real question is why isn’t libbfd LGPL?
libbfd isn’t intended for use by third-parties; it’s a holding place for code shared between binutils, gdb, and gcc.
It’s only a problem for distros that only let privileged developers submit binary packages, because of redistribution problems. I’m currently on NixOS and my version of
perfis linked withlibbfd.Could you elaborate on this? How does a privileged group of developers relate to distribution problems?
If a distro only uses ports trees, then distributing binaries is an optimization rather than an essential part of software delivery. Ports trees generally work around composition issues because end users are allowed to run nearly any combination of software on their personal computers.
I see, that definitely makes sense when you explain it that way.
Yet it still feels weird to me, as I can easily download the deb src package to build and install manually. Even though it’a different from a ports tree in structure (deb src packages are tools for making the binary distribution, ports packages are optimizations of a source distribution), from an end user perspective it’s just different ergonomics.
The key difference is probably how options are specified. As I understand it, a deb src package contains a recipe for building a .deb binary package. In contrast, a port typically contains a recipe for building a set of binary packages. Some of these may permit binary redistribution, others don’t. When the FreeBSD package build infrastructure runs, it will not build configurations that don’t allow binary distribution, but if you run poudriere locally then you can enable these options.
Of course, perf could just link to LLVM’s Symbolizer library and get this functionality without any problems, but that’s probably a hard sell at Red Hat, which employs most of the GNU toolchain developers.
Since it’s only one operation that perf needs and they likely don’t need to support esoteric formats, maybe addr2line could be reimplemented without too much hassle?