Adjust #includes to unbreak the build on FreeBSD

[danfe]

While the code already uses #if[n]def linux (although isn't __linux__ more correct?), some Linux-specific header files are included unconditionally, and some are missing.

• Missing #include <signal.h> in reader.c which calls signal(SIGALRM, ...); breaks the build on FreeBSD (apparently, GNU/Linux gets it via some pollution in headers elsewhere)
• unsquashfs.c header file block needs the following patch (the code itself is okay):

+#ifdef __linux__
 #include <sys/sysinfo.h>
 #include <sys/sysmacros.h>
+#endif
+#ifdef __FreeBSD__
+#include <sys/sysctl.h>
+#endif

[plougher]

I used BSD 4.1, 4.2, 4.3 and Unix version 7 back in the 1980s and early 1990s, on various machines including DEC PDP 11's, DEC VAX 11/780 and later various workstations (e.g. Sun). So please don't assume I know nothing about BSD.

I mostly stopped using BSD Unix in about 1992, when companies brought out so called "converged Unixes", where they switched from a BSD source to SVR4 (System V Release 4) with BSD extensions. Sun OS switched from BSD to SVR4 at this point.

At this time it became almost impossible to produce C source that would compile and run on the various diverged systems (the reality was they were more diverged than converged). In the department there was the VAX 11/780 running 4.3 BSD, a Sequent Symmetry (eight Intel 80386's running in parallel) running some weird BSD 4.2/SVR4 hybrid, that had mostly replaced the aging VAX, and various Sun and HP workstations. It was impossible to produce C source that would compile on all of them, due to lack of standardisation between the Unixes. What didn't help matters was Sun, HP, IBM, DEC all brought out non-standard "enhancements" which was the only way of doing certain things, and so you literally coded to the Unix on the machine you wanted the program to run.

What of this you may ask? It means the early 1990s was a nightmare of Unix incompatibility that I never particularly want to revisit. In most cases you spent a huge amount of time trying to get C source to work on different Unixes and it was a huge time sink.

Due to that previous experience when I wrote the initial version of Squashfs in 2001/2002, I decided to make it Linux only, and avoid any of the complexities of getting it working on anything else. I wasn't being an "asshole" here, Linux was the system it was written for, and I didn't develop or test it on anything else, and so I could only guarantee it compiled and worked on Linux. Moreover I didn't have the computer resources or time to add the extra burden of testing on non-Linux systems.

Fast forward 20 years, and I am increasingly being asked to add support for systems I don't develop on and I don't test on either. But, nothing at all has changed in respect to my computer resources or time.

So, basically why would I want to make the tools work on other Unixes, given that this is an extra burden of development and testing, and takes scarce resources away from elsewhere?

If you want the code to work on your non-supported version of Unix, then you have to do the work yourself. Because I'm not going to do it for you, and add to my development and testing burden.

The only way I would take patches or do work to help it work on other Unixes, is on a non-burdensome non-obligation basis. That is I do the work, if is not too much effort, but I don't even compile let alone test the changes on BSD. If it doesn't work it has not become my problem.

Given that, there are three modern descendants of BSD 4.x Unix, FreeBSD, NetBSD and OpenBSD. How similar are these in respect to C source changes. Are these changes that work for FreeBSD guaranteed to work for NetBSD and OpenBSD and their variants? Or will I go down the slippery slope of adding these changes for FreeBSD and then get asked to add changes for NetBSD and OpenBSD. So by beginning to agree to take changes to support other Unixes, I get back to the incompatibility nightmare of the early 1990s.

If there's any chance of that happening, it is usually best to say no to accepting these changes, and leaving it at that.

[danfe]

If you want the code to work on your non-supported version of Unix, then you have to do the work yourself.

Fair enough. It was just a report, I'm happy to keep the local patch if you don't like #ifdef __FreeBSD__ in your code. However, if #include <signal.h> is indeed missing, it would be nice to fix as it applies to GNU/Linux as well (one should not rely on implicit inclusion of headers).

[danfe]

However, if #include <signal.h> is indeed missing in the reader.c [...]

Yes, it's still missing in recently released version 4.5.1 (thanks for that BTW).