Add a feature + cfg attribute to exclude GNU extension functions

[shravanrn]

Hi,
I was wondering if it would be possible to add a feature flag and the appropriate cfg calls to separate POSIX functions from the GNU specific extensions (usable when _GNU_SOURCE is defined).

My use case is as follows. I am using some packages (lucet) that have a dependency on the nix packages. While I'm using these packages in a Linux system, we are linking against libraries without the GNU extension functions... Thus the presence of calls to process_vm_writev, process_vm_readv and setns is causing problems. Additionally, it seems that the nix wrappers for these functions cannot be eliminated by dead code removal, and so persist in the final library, resulting in missing symbol errors.

Currently, it seems that these functions are protected only with #[cfg(any(target_os = "linux"))]. Thus the easiest workaround that comes to mind is to pretend that target_os is not linux, but this feels hacky at best... I was wondering if it would be possible to add a new feature flag which we can set at compile time, that would exclude these GNU specific functions...

(also, I apologize if I got some details wrong... I'm still quite new to rust :) )

Please let me know... If required, I am also happy to contribute a patch for the same...

[asomers]

What C library are you using? musl? newlib? something else? The correct solution would be to guard such functions with a #[cfg(target_env = ...)]

[shravanrn]

Thanks a bunch for the quick response! Oh, that's interesting... I just read up about target_env, that sounds like the right solution, and I believe should be sufficient for my needs. Let me know if this fix is something this will be addressed by you/one of the other nix devs, or something I should be contributing a patch for.

I am following up about the exact libc we use (I'm not overly familiar with that part of our build system and so am waiting to hear back from others about this. I will post here as soon as I find out)

[asomers]

Please submit a PR. Nix thrives on the contributions of our users.

[shravanrn]

Ah, so apparently we do use glibc, its just that we don't allow binaries that make calls to GNU_SOURCE functions... This actually means, that the target_env solution may not be enough to exclude the GNU specific functions.

While it would be ideal to add #[cfg(target_env = "gnu")] to functions like setns with and then exclude it via a suitable target triple, this doesn't quite work for us... The target triple we are forced to use is x86_64-unknown-linux-gnu, although in spirit what want is something like x86_64-unknown-linux-unknown (even though this doesn't exist)

Question - Would you be willing to accept a PR if I add both #[cfg(target_env = "gnu")] and a feature flag, so that we can control whether GNU functions are included through a build parameter?

[asomers]

I still don't understand exactly what your problem is. If the C library is missing a function that Nix wraps, that shouldn't be a problem. It happens all the time, in fact, because libc and Nix define functions newly added on recent OS versions, but still compile and test on older versions. I just checked, and it wasn't a problem to add a bogus extern "C" definition to Nix. It's only a problem if I try to call that function from a test. Can you show me exactly what error you're getting?

[shravanrn]

Ah, so sorry for the confusion... I think I finally got to the bottom of this. I believe you are completely right... I just did the same test of a bogus extern C and wrapping it. This results in a few undefined symbols in the resulting binary. While this is not an error by itself, we have additional build checks in our project that mark any missing symbols as an error causing build breaks on our side...

So definitely my bad with the earlier description... I think the amended description looks something like this - We are linking against a version of glibc without the GNU extension functions. Thus the presence of calls to process_vm_writev, process_vm_readv and setns results in undefined symbols in the binary. Part of our build infrastructure makes any missing symbols a build failure, which means including nix in our source causes our build infrastructure to complain.

Please let me know if this makes sense...

With regards to use of nix in our codebase, I think this sort of leaves us in the same place as before... I'm wondering if it would be reasonable to accept a feature flag to exclude such gnu source functions? This would allow us to use upstream nix as is, instead of a having to maintain a fork with this one extra patch.

[asomers]

No, we wouldn't accept such a patch. When using Rust with FFI, missing symbols are the norm. You need to fix your build infrastructure.

[shravanrn]

Alright, thanks for the info.

[froydnj]

Hi, I'd like to ask that this bug be reopened, possibly with the title modified.

No, we wouldn't accept such a patch. When using Rust with FFI, missing symbols are the norm. You need to fix your build infrastructure.

The issue runs thusly: the Firefox build infrastructure builds against an older version of glibc to ensure the broadest possible compatibility for official Firefox releases (GLIBC_2.12 symbol version). Symbols like process_vm_readv, which are the ones being modified by the proposed patch, come with a symbol version of GLIBC_2.15 and are therefore not available to link against. So when one transitively depends on nix-rust, even if you don't call process_vm_readv and friends, you still have to wind up linking against a glibc that supports those functions so your code will actually build. I suspect you don't see this on your CI because your older versions of glibc (I can't tell what comes with Ubuntu trusty, but I suspect it has GLIBC_2.15 symbol versions) are still newer than what we use.

Just because the target_env is gnu, that does not imply that all of the functions in the most recent revision of glibc are necessarily available.

You might say that lto = true should be set in Cargo.toml. And that works (I think) for release profiles, but it's not true by default in dev profiles and changing the dev profile to do LTO by default is not acceptable.

[asomers]

But as I explained earlier, I can add complete bogus extern "C" function definitions to Nix, and even call them from Rust functions, without a problem. The regular Rust tools have no problem with missing symbols. What are you doing differently? Even if we were to remove (or disable) those functions in Nix, they would still be defined in libc, which you must link against too.

[froydnj]

But as I explained earlier, I can add complete bogus extern "C" function definitions to Nix, and even call them from Rust functions, without a problem. The regular Rust tools have no problem with missing symbols. What are you doing differently?

Possibly compiling with -Wl,-z,defs, which requires all symbols to resolve to something at link time.

Even if we were to remove (or disable) those functions in Nix, they would still be defined in libc, which you must link against too.

They are not defined in the libc we are linking against, as I explained earlier.

[asomers]

But as I explained earlier, I can add complete bogus extern "C" function definitions to Nix, and even call them from Rust functions, without a problem. The regular Rust tools have no problem with missing symbols. What are you doing differently?

Possibly compiling with -Wl,-z,defs, which requires all symbols to resolve to something at link time.

Even if we were to remove (or disable) those functions in Nix, they would still be defined in libc, which you must link against too.

They are not defined in the libc we are linking against, as I explained earlier.

Sorry; there are two different things named "libc". I meant they would still be defined in rust-lang/libc, which you must link against too.