[Compilation/Build] Building the package require more than 4GB!

[tokiclover]

Just failing to build the package because of... not enough space on the device which has 4GB free space! This is ridiculous because the cupirit is mksquashfs command.

mksquashfs "/var/tmp/portage/sys-fs/vdev-9999/work/vdev-9999-abi_x86_64.amd64/build/lib/vdev/hwdb/hwdb.squashfs.dir" "/var/tmp/portage/sys-fs/vdev-9999/work/vdev-9999-abi_x86_64.amd64/build/lib/vdev/hwdb/hwdb.squashfs" -force-uid 0 -force-gid 0
Could not create destination file: No space left on device
Makefile:14: recipe for target '/var/tmp/portage/sys-fs/vdev-9999/work/vdev-9999-abi_x86_64.amd64/build/lib/vdev/hwdb/hwdb.squashfs' failed
make[1]: *** [/var/tmp/portage/sys-fs/vdev-9999/work/vdev-9999-abi_x86_64.amd64/build/lib/vdev/hwdb/hwdb.squashfs] Error 1
make[1]: Leaving directory '/var/tmp/portage/sys-fs/vdev-9999/work/vdev-9999-abi_x86_64.amd64/hwdb'
Makefile:5: recipe for target 'all' failed
make: *** [all] Error 2

There is really a enormous list which is not included in the above exerpt.

Please fix!

And I don't understand this squashfs step at all.... I guess udev rules are squashed here for futur usage, right? But why so many packages of them?

[jcnelson]

Hi tokiclover,

Thank you for your interest in vdev.

The squashfs image replaces udev's hwdb.bin file. Like the hwdb.bin file, it contains a trie of prefixes used to resolve a modalias string to a set of attributes encoded as key/value pairs. Unlike the hwdb.bin file, the database is encoded as a filesystem image (instead of a udev-specific trie data structure, which udev mmap()'s into itself), where each leaf node in the trie is a file with a newline-separated list of attributes.

Constructing the hwdb squashfs image is a time- and inode-intensive process, because there are over 72,000 modalias strings to consider, and thus even more files and directories to create. You probably ran out of inodes, not space (try df -i to confirm).

I include a ready-made hwdb.squashfs file in hwdb/ so users can avoid his step, but if you want to compile your own, the best way to go about it is to create a temporary filesystem (i.e. tmpfs or a loopback filesystem on a flat file), ensure it has enough inodes, mount it somewhere, and run the gen_database.sh script with the mounted temporary filesystem as its destination directory (i.e. gen_database.sh -o /path/to/temporary/fs ...).

Hope this helps,
Jude

[tokiclover]

I did not really want to build it by hand; it's just that when running make ... install generate that file.
Actually, it would best to write a configure script for this kind of set up along with setting up the OS, {C,LD,CXX,CPP}FLAGS instead of using the makefile for this. Otherwise, the build system would get too many noise of the configuration phase.

I do not know much of vdev, so I cannot help much at the moment. I wanted to help al little on the makefile to no avail because of the split up which makes the makefile usable to sub-dir. Only two tiny patch of DESTDIR corrections made so far for fskit and libpstat which are not submitted for now. Well, crossing another issue here.

[jcnelson]

Generating the hwdb.squashfs file is already handled by the automated build process. I consider handling the case where the host can run out of inodes (or any resource for that matter) while building vdev to be beyond the scope of the build system to address. The same thing can happen when building the Linux kernel, for example.

What I can do is as follows:

• Add a warning to the documentation that building the hwdb will consume a lot of inodes.
• Describe the workaround above in more detail, for creating a high-inode temporary filesystem to host the hwdb as it is being generated (I don't think this can be safely automated, since it requires elevated privileges).
• Ship a pre-compiled hwdb.squashfs image that will satisfy the hwdb build target.
• Add an option in the buildconf.mk to disable building the hwdb.
• Add an option in the buildconf.mk to forcibly rebuild the hwdb, even if the pre-compiled one is present.

The hwdb does not need to be rebuilt frequently, for that matter. It only needs to be regenerated whenever I sync up with systemd's hwdb files (which will be timed with each systemd release--once every few months), and I already avoid this issue in most cases simply by building the hwdb.squashfs on behalf of downstream packagers.

The point of having a buildconf.mk is to make it easier for downstream packagers to tweak the build system so vdev can build on their distros of choice. I am willing to tweak the default buildconf.mk to make this easier in ways that help everyone (such as with #40 ), and to host a curated set of known-good distro-specific buildconf.mk files in a "distro/" directory. However, I'm really trying to avoid doing anything more complex than this (and I'm especially trying to avoid using GNU autotools).