I think there should be a comment in the code with this link, and a mention which environments need this fix (I do not ask for making it optional — just for a bit more clarity and context)

Probably a bash comment

updated!

Do I understand correctly that the workaround is not really about malloc(0) but about the inferences drawn by Autoconf from this specific check?

@7c6f434c as I understand it, yes, ideally the code itself should be patched to be portable across different libcs

@illegalprime I think the comment is misleading then — it is not a problem of detection (malloc(0) is NULL), it is a problem of drawing wrong inferences (the actual features needed by the code are there)..

@matthewbauer I think it is libc-dependent, not cross-compilation-dependent? And apparently for non-glibc libcs we have this functionality is never useful.

@7c6f434c yeah that makes sense, should it be conditional on isGlibC or something?

We can also add musl to the list:

$ echo 'void main() { printf("%p\n", malloc(0)); }' | nix-shell -p musl --command 'musl-gcc -o main -xc -'
$ ./main
0x2118020

Then most cross-compiling use-cases should be covered.

hostPlatform.libc == "glibc" || hostPlatform.libc == "musl";

My point about inferences about other features was more about the comment than about exact condition — that it is not because we assume things about malloc(0) but because we assume the things code actually cares about to be present.

Also, doesn't this also apply to uClibc without cross-compilation?

@7c6f434c Yes it is libc-dependent. The only difference is, that in the non-crosscompiling builds, autotools can interfere the right value at buildtime. For now we could set this value for libc's where we tested the value.

… and autodetection for uClibc would still be formally correct but practically useless?

@7c6f434c Yeah. I don't think we would need to care about uclibc given that Musl support in nixpkgs and in general is better.

Ah, I misestimated the relevance of uClibc link in the comment

This is master right now:

$ git grep ac_cv_func_malloc_0_nonnull 
pkgs/development/libraries/geoip/default.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/libraries/ldns/default.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/libraries/libmodbus/default.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/libraries/libomxil-bellagio/default.nix:    stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ "ac_cv_func_malloc_0_nonnull=yes" ];
pkgs/development/libraries/opendkim/default.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/tools/parsing/flex/2.5.35.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/tools/parsing/flex/2.6.1.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/tools/parsing/flex/default.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/development/tools/profiling/EZTrace/default.nix:    export ac_cv_func_malloc_0_nonnull=yes
pkgs/os-specific/linux/lvm2/default.nix:    "ac_cv_func_malloc_0_nonnull=yes"
pkgs/os-specific/linux/procps-ng/default.nix:    [ "ac_cv_func_malloc_0_nonnull=yes"
pkgs/os-specific/linux/psmisc/default.nix:    export ac_cv_func_malloc_0_nonnull=yes
pkgs/tools/networking/autossh/default.nix:    export ac_cv_func_malloc_0_nonnull=yes

some of those are my fault, but should they all be changed or maybe moved into stdenv?

@Mic92 so what about putting this in stdenv under a isCross & isGlibc (isMusl) flag?

@illegalprime sounds fine to me to set this, if we have isCross set.

when I add those flags to stdenv some new things fail to compile zlib because it doesn't recognize those flags anymore:

builder for '/nix/store/sgjvsi1hlgkx6s51bm2nlsnh2an70690-zlib-1.2.11-armv7l-unknown-linux-gnueabihf.drv' failed with exit code 1; last 10 log lines:
  patching sources
  updateAutotoolsGnuConfigScriptsPhase
  configuring
  configure flags: --prefix=/nix/store/wr1j82qbys4khig6gzm8zm3l3cyhpngb-zlib-1.2.11-armv7l-unknown-linux-gnueabihf --shared ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes
  Using armv7l-unknown-linux-gnueabihf-ar
  Using armv7l-unknown-linux-gnueabihf-ranlib
  Using armv7l-unknown-linux-gnueabihf-nm
  unknown option: ac_cv_func_malloc_0_nonnull=yes
  ./configure --help for help
  ** ./configure aborting.
cannot build derivation '/nix/store/rfy7a17f9vps4l281y8id8902pakyadp-python-2.7.16-armv7l-unknown-linux-gnueabihf.drv': 1 dependencies couldn't be built

relevant commit: illegalprime@4e79d1d

maybe autotools has a way to set default flags even if they might not exist (cc @Mic92)

zlib is actually not using autotools at all, but a custom shell script that emulates autotools in some ways. To get around this, don't put the value in "configureFlags", but instead just set it in the environment. I believe autotools picks it up as well.

zlib is actually not using autotools at all, but a custom shell script that emulates autotools in some ways. To get around this, don't put the value in "configureFlags", but instead just set it in the environment. I believe autotools picks it up as well.

I also remember environment variables to work.

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

I marked this as stale due to inactivity. → More info

This has been merged in #106761