AF_LOCAL not available when building derivation

Development
1

I am managing my Erlang installations via Nix, but there is problem - Erlang build on non-NixOS machines (tested on macOS, Alpine (Docker image), and Fedora) returns information that local sockets aren’t available. The check for this is simple compile-time check if AF_LOCAL macro exists which for some reason do not exists in Nix derivation. Could someone point me where to look how to solve that?

2

I guess AF_LOCAL is the address family and therefor networking.
Nix builds are usually sandboxed. There simply is no network available during the build and thus networking cannot be accessed.
There are three ways to get around that:

  1. Turn the derivation into a fixed-output derivation by providing a checksum of the output. Fixed-output derivations do have network access to download e.g. source tarballs. This will probably fail as any updates to dependencies will cause the checksum to change.
  2. Patch the source code to skip that check and either just assume that it’s available or skip the check of opening a socket. Maybe try to upstream that patch, if possible. This is probably the most common option.
  3. Turn of the build sandbox on your system by changing nix.useSandbox option in configuration.nix. This is usually a bad solution and breaks the reproducability of Nix as you now depend on a specific configuration of the host system.
3

Upstream do not open any socket, it just check if AF_LOCAL is defined at all. It is literally:

static
ERL_NIF_TERM esock_supports_local(ErlNifEnv* env)
{
    ERL_NIF_TERM supports;

#if defined(AF_LOCAL)
    supports = esock_atom_true;
#else
    supports = esock_atom_false;
#endif

    return supports;
}

AKA return true if AF_LOCAL is defined.

I do not build it in the sandbox as then it fails on building lz4 or pc, I cannot find which one is problematic.

So it seems like it is only about lack of AF_LOCAL macro defined in sys/socket.h.

4

Then I’m afraid I cannot provide any help and hope that someone else has an idea.

1 Like
5

Do you have a derivation that we can try out?
Does it work if you use the nix-shell just for the dependencies and run the build steps manually?
Are you sure you have declared your dependencies properly? Or can it find them properly?

6

You can test it by yourself by running

nix-shell -p erlangR22 --run "erl -eval 'io:format(\"~p~n\",[socket:supports(local)]),init:stop().'"

It returns:

Eshell V10.4.3  (abort with ^G)
false
1>

Which mean that the local sockets aren’t supported. I haven’t introduced any changes, and when I run that command within official nixos/nix Docker image then the result is the same, so it doesn’t seem like problem with my particular environment.

7

I don’t know… AF_LOCAL seems to work fine for me. I’ve been maintaining a nix package that uses it for years, and it does not do anything special to get the C macro, etc.

8

A quick try:

$ nix-shell --pure -Q
$ cc -E -
       #include <sys/socket.h>
       #include <sys/un.h>

AF_LOCAL

and watch that it gets expanded at the end – to value 1. EDIT: actually it works for me even without the second include, but man 7 unix specifies both so I tend to use both to be sure.

9

Ok, then for whatever reason the Erlang build is broken, and it can be repeatedly reproduced with different installations. I am trying to find the problem, but for now I do not see anything that could cause such problems.

10

Ok, NVM I have found the problem. Erlang OTP 22.1 is the earliest one that supports socket:supports(local). and Nixpkgs version is 22.0.4