Building a library inside fhs environment

I’m trying to compile a library that needs to be compiled inside an FHS environment.
the problem is if I put my compiling/linking steps inside extraBuildCommands, targetPkgs are not yet installed. and if I use runScript I can’t move the compiled code back to the FHS environment (because it is read-only system).
any help ?

the build directory is still writable… I would try to patch the assumptions it makes to something more reasonable, like TMPDIR.

It would help if you expanded on what aspects of a FHS are required.

I’m trying to build ‘kaldi’.
it has some steps like configure, make, sed something like that.
it depends so hard on /bin/bash inside its makefiles . it even generate makfiles that needs /bin/bash.
so I decided to build it inside fhs environment, and I succeded but I can’t put the built directory back to the environment itself.

I’m trying to build a Singularity (Apptainer) image with the --fakeroot option, but have encountered an issue about the (seemingly hard-coded) PATH variable.

Considering that the product is an image to be used on an HPC grid, and that I don’t want to hack the singularity derivation just for building it. It would be great if there’s an option to build things in an FHS environment.

In that case it is better to use patchShebangs on the generated makefiles after configuring and/or patch the configure scripts.

If the PATH is hard-coded, try to patch it. Things like these are usually simple string substitutions (substituteInPlace).

The Apptainer --fakeroot issue is more complex than a line of hard-coded PATH. Ideally, it should be solved upstream.

I acknowledge that packages for Nixpkgs should not be built in such a manner. However, when trying to build, say, an image to be run on FHS-compliant platforms, such kind of setup would make development and testing faster.

IMO, if the program is to be merged into NixOS/nixpkgs, it should be patched and the result should be independent from /bin and /usr/bin. Otherwise, the same problems will occur when being run by users.

If it heavily relies on /bin/bash, it would be better to send a patch upstream.

Nevertheless, an FHS builder would still be a cheaper / more convenient alternative to vmTools.runInLinuxVM for local run / tests.