nilfs-utils: force malloc(0) realloc(0) to be valid #58056

illegalprime · 2019-03-21T15:32:58Z

Motivation for this change

configure is not sure whether the host system will have a malloc and realloc that returns a valid pointer when given 0 so it assumes no and fails, this forces configure to assume yes.

https://www.uclibc.org/FAQ.html#gnu_malloc
https://www.gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fFUNC_005fMALLOC-454

Things done

7c6f434c · 2019-03-21T19:40:33Z

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

illegalprime · 2019-03-25T18:16:35Z

updated!

7c6f434c · 2019-03-25T22:02:42Z

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

illegalprime · 2019-03-25T23:11:37Z

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

matthewbauer · 2019-03-26T02:03:17Z

pkgs/tools/filesystems/nilfs-utils/default.nix

+    # https://www.uclibc.org/FAQ.html#gnu_malloc
+    # https://www.gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fFUNC_005fMALLOC-454
+    # the upstream source should be patched to avoid needing this
+    "ac_cv_func_malloc_0_nonnull=yes"


Since this is a hack, we should make it conditional on cross compiling. Otherwise we might be overriding legitimate detection.

I wonder if it was possible to provide the correct information about the host in a more generic way to autotools, since I have seen this problem with ac_cv_func_malloc_0_nonnull in many places.

7c6f434c · 2019-03-26T05:38:00Z

@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.

illegalprime · 2019-03-26T16:05:11Z

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

Mic92 · 2019-03-26T16:12:14Z

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";

7c6f434c · 2019-03-26T18:50:03Z

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?

Mic92 · 2019-03-27T08:31:07Z

@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.

7c6f434c · 2019-03-27T08:40:43Z

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

Mic92 · 2019-03-27T08:43:28Z

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

7c6f434c · 2019-03-27T08:47:33Z

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

illegalprime · 2019-04-04T17:51:08Z

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?

illegalprime · 2019-09-15T11:25:15Z

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

Mic92 · 2019-09-21T06:50:53Z

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

illegalprime · 2019-09-26T16:55:21Z

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)

matthewbauer · 2019-09-27T00:52:44Z

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.

Mic92 · 2019-10-02T08:55:57Z

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.

stale · 2020-06-01T08:22:57Z

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:

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

stale · 2021-04-07T02:54:07Z

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

rapenne-s · 2022-09-30T16:18:26Z

This has been merged in #106761

GrahamcOfBorg requested a review from 7c6f434c March 21, 2019 15:49

GrahamcOfBorg added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild 10.rebuild-linux: 11-100 labels Mar 21, 2019

nilfs-utils: force malloc(0) realloc(0) to be valid

4266bff

illegalprime force-pushed the nilfs-utils-cross branch from 6d7e8ee to 4266bff Compare March 25, 2019 18:16

matthewbauer reviewed Mar 26, 2019

View reviewed changes

7c6f434c added the 2.status: merge conflict This PR has merge conflicts with the target branch label Apr 16, 2019

stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 1, 2020

ryantm added 2.status: merge conflict This PR has merge conflicts with the target branch and removed 2.status: merge conflict This PR has merge conflicts with the target branch labels Oct 3, 2020

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Oct 3, 2020

ryantm added 2.status: merge conflict This PR has merge conflicts with the target branch and removed 2.status: merge conflict This PR has merge conflicts with the target branch labels Oct 3, 2020

stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 7, 2021

rapenne-s closed this Sep 30, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

nilfs-utils: force malloc(0) realloc(0) to be valid #58056

nilfs-utils: force malloc(0) realloc(0) to be valid #58056

illegalprime commented Mar 21, 2019

7c6f434c commented Mar 21, 2019

illegalprime commented Mar 25, 2019

7c6f434c commented Mar 25, 2019

illegalprime commented Mar 25, 2019

matthewbauer Mar 26, 2019

Mic92 Mar 26, 2019

7c6f434c commented Mar 26, 2019

illegalprime commented Mar 26, 2019

Mic92 commented Mar 26, 2019 •

edited

Loading

7c6f434c commented Mar 26, 2019

Mic92 commented Mar 27, 2019 •

edited

Loading

7c6f434c commented Mar 27, 2019

Mic92 commented Mar 27, 2019

7c6f434c commented Mar 27, 2019

illegalprime commented Apr 4, 2019

illegalprime commented Sep 15, 2019 •

edited

Loading

Mic92 commented Sep 21, 2019 •

edited

Loading

illegalprime commented Sep 26, 2019 •

edited

Loading

matthewbauer commented Sep 27, 2019

Mic92 commented Oct 2, 2019

stale bot commented Jun 1, 2020

stale bot commented Apr 7, 2021

rapenne-s commented Sep 30, 2022

nilfs-utils: force malloc(0) realloc(0) to be valid #58056

nilfs-utils: force malloc(0) realloc(0) to be valid #58056

Conversation

illegalprime commented Mar 21, 2019

Motivation for this change

Things done

7c6f434c commented Mar 21, 2019

illegalprime commented Mar 25, 2019

7c6f434c commented Mar 25, 2019

illegalprime commented Mar 25, 2019

matthewbauer Mar 26, 2019

Choose a reason for hiding this comment

Mic92 Mar 26, 2019

Choose a reason for hiding this comment

7c6f434c commented Mar 26, 2019

illegalprime commented Mar 26, 2019

Mic92 commented Mar 26, 2019 • edited Loading

7c6f434c commented Mar 26, 2019

Mic92 commented Mar 27, 2019 • edited Loading

7c6f434c commented Mar 27, 2019

Mic92 commented Mar 27, 2019

7c6f434c commented Mar 27, 2019

illegalprime commented Apr 4, 2019

illegalprime commented Sep 15, 2019 • edited Loading

Mic92 commented Sep 21, 2019 • edited Loading

illegalprime commented Sep 26, 2019 • edited Loading

matthewbauer commented Sep 27, 2019

Mic92 commented Oct 2, 2019

stale bot commented Jun 1, 2020

stale bot commented Apr 7, 2021

rapenne-s commented Sep 30, 2022

Mic92 commented Mar 26, 2019 •

edited

Loading

Mic92 commented Mar 27, 2019 •

edited

Loading

illegalprime commented Sep 15, 2019 •

edited

Loading

Mic92 commented Sep 21, 2019 •

edited

Loading

illegalprime commented Sep 26, 2019 •

edited

Loading