On Mon, Apr 13, 2020 at 12:54 PM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
On Mon, Apr 13, 2020 at 10:09 AM Niels Möller nisse@lysator.liu.se wrote:
As far as I'm aware, that should fix BSDs and other systems disliking relative names in LD_LIRBARY_PATH. If you can verify the rc1 tarball on NetBSD (I only have FreeBSD nearby), that would be nice.
I'll have to take your word for it. I upgraded to NetBSD 9, and now iConv is broken. I can't get beyond its install recipe. A broken iConv or Gettext means I can't build the necessary dependencies to test Nettle.
Sounds a bit frustrating... Building the tarball shouldn't need more than a C compiler, GNU make and m4 (if you configure with --enable-mini-gmp, you can get reasonable test coverage without installing the GMP library).
It is Nettle's OpenSSL dependency that is causing the trouble. OpenSSL depends on Unistring and Unbound, and they bring in the extra gear.
Actually a lot of software works with SIP on OS X. Nearly all software I use and test works as expected, which is about 120 packages. The problem seems to be limited to Git, GMP and Nettle. I think you want to get on the other side of the fence with all the software that works as expected.
As I see it, it's a problem affecting a few of Nettle's test. Once installed, it should work fine. It might be a valid fix to just disable those tests.
Then maybe you can drop the unneeded test?
It is important that folks can do a 'make && make check' and have things "just work". I know some organizations that needs stuff to work, or it requires a management sign-off complete with change control entries. It is an administrative nightmare.
I mean, DYLD_LIBRARY_PATH is useful mainly for developers, and it's not unreasonable to configure the system differently on a developer machine than on a vanilla server or desktop. On GNU/Linux, e.g, I'd recommend developers to enable traditional core dumps and use a liberal setting for sysctl kernel.yama.ptrace_scope.
Is there any reason you refuse to fix things?
Just that (i) it's going to take me a few hours to test and fix this properly, and I don't want to allocate those hours before the release, and (ii) I generally give lower priority to supporting proprietary systems.
I don't think copy/paste is going to take several hours. And a good CI pipeline should handle the testing for you. If you need hours of testing, then that probably points to a defect in the engineering process. The process has gaps where CI testing should occur.
Apple is mostly open sourced. You can find the source code at opensource.apple.com. I believe that's how distros like Hackintosh make their stuff work. They start with Apple sources and massage them.
Jeff