Building a library inside fhs environment

Help
1

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 ?

2

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.

3

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.

4

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.

5

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

6

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

7

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.

8

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.