Nixpkgs: gnulib is broken on darwin

Created on 31 May 2016 · 20Comments · Source: NixOS/nixpkgs

See https://github.com/NixOS/nixpkgs/issues/15694 and the related man-db issues.

The underlying problem is that gnulib has a program_name extern that basically assumes glibc, and other platforms (including darwin) don't provide it. This patch is one approach to fixing it, by making program_name a #define to a magic darwin call. I don't think the literal patch will work though, because it's in a .c file instead of a .h file, and because I think the gnulib source has changed since then.

The other complication is that several packages (libpipeline and man-db) bundle gnulib in their source tarballs, so either we have to patch them to use our fixed gnulib or patch them all individually.

Once we fix this, I think we should also revert https://github.com/NixOS/nixpkgs/pull/15754, as I don't think it's the correct fix for this issue (program_name should in principle not be libpipeline, even though that will fix the linkage).

cc @gilligan @LnL7 @fpletz @matthewbauer @vcunat

In the short term, it might also just pay to switch man = man-old on darwin, since it was the switch to man-db that revealed this problem. Ultimately though we should minimize darwin-specific hackery of that sort and should stay as consistent as possible with the linux mainline, so I'd like to fix gnulib properly.

Things to do:

[ ] Revive this thread to get upstream to fix this issue
[ ] Meanwhile, patch man-db and libpipeline's bundled gnulib to use _NSGetArgv()
[x] If nobody has any time to deal with that stuff, we should at least switch man = man-old on darwin

Anyone want to volunteer for those tasks?

bug darwin

Source

copumpkin

👍2

Most helpful comment

TBC, I wouldn't consider this "fixed" until the proper patch is in, but I'd rather unblock hydra and the channel first, then figure out how to do it properly.

copumpkin on 31 May 2016

👍2

All 20 comments

We have a version of "gnulib" in all-packages.nix. Is there a way to force packages to use our version? I suppose we could just remove "/gnulib" and add a symlink to the all-packages.nix's gnulib. That would at least mean we wouldn't have to ask gnulib users to change anything.

matthewbauer on 31 May 2016

Sadly, the gnulib patch does not make man-db build:

CCLD     libmandb.la
Undefined symbols for architecture x86_64:
  "_database", referenced from:
      _gripe_corrupt_data in libmandb_la-db_lookup.o
      _gripe_replace_key in libmandb_la-db_lookup.o
      _split_content in libmandb_la-db_lookup.o
      _dblookup in libmandb_la-db_lookup.o
      _dblookup_pattern in libmandb_la-db_lookup.o
      _dbver_rd in libmandb_la-db_ver.o
      _dbver_wr in libmandb_la-db_ver.o
      ...
ld: symbol(s) not found for architecture x86_64
clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)

matthewbauer on 31 May 2016

I'll take a look if I have some time

LnL7 on 31 May 2016

@copumpkin thanks for bringing this up.

I just wrote to the gnulib-bug mailing list. I will link the email here as soon as it shows up on the archives page.

Once we fix this, I think we should also revert #15754, as I don't think it's the correct fix for this issue (program_name should in principle not be libpipeline, even though that will fix the linkage).

Yes, it isn't pretty. I would also like to see that go. At the time it was the best I could do to get rid of this rather big blocking issue (considering how man-db needs libpipleine)

I would be willing to help out but it is unlikely that I will manage to find time before next week.

gilligan on 31 May 2016

Here is the email to the mailing list: http://lists.gnu.org/archive/html/bug-gnulib/2016-05/msg00054.html

Seems like only the response ended up on the mailing list since I am not subscribed and hence not allowed to post. Meh.

gilligan on 31 May 2016

👍1

So in the shortest term, I think we should move man out of aliases back into all-packages, and then make it point to man-db only on Linux. @vcunat is that reasonable?

copumpkin on 31 May 2016

Oh he already said it was okay on the commit. I'll push the change

copumpkin on 31 May 2016

👍1

I would consider conditioning this !isDarwin instead of isLinux, but I have really little idea about other platforms; it's just that the old man seems abandoned in general.

vcunat on 31 May 2016

@vcunat I was going to do isLinux because it looks like gnulib assumes glibc, which is unlikely to work on anything but linux. I imagine we're only seeing pain from darwin users because there are more of us than cygwin/bsd?

I'm attaching a comment to the alias so I'm hoping it won't last for long, but until we can sort out the actual gnulib issue, it seems safer to assume only linux works.

copumpkin on 31 May 2016

OK. The fraction of users other than Linux+Darwin seems very low, so the importance of the decision seems also low.

We have a version of "gnulib" in all-packages.nix. Is there a way to force packages to use our version?

That's probably not going to work. AFAIK it's customary to bundle gnulib and depend internally on particular versions. It doesn't seem meant to be "shared" (meaning most users using the same version).

vcunat on 31 May 2016

@copumpkin shouldn't we at least give @LnL7 or me a chance to possibly patch man-db and gnulib as by your second checkbox item? The current situation is not optimal but nothing is broken right now. Are we in a hurry about this?

gilligan on 31 May 2016

@gilligan your fix didn't work for me beyond libpipeline. Were you able to compile git? I was still getting the same error in a different place on current master.

copumpkin on 31 May 2016

TBC, I wouldn't consider this "fixed" until the proper patch is in, but I'd rather unblock hydra and the channel first, then figure out how to do it properly.

copumpkin on 31 May 2016

👍2

Note that MACs on hydra are being migrated tomorrow so nothing will fix (build) until then.