Closed ttsiodras closed 3 years ago
Hi @ttsiodras
Thanks, it looks like this was broken by https://github.com/0x09/hfsfuse/commit/8df0c23ffa111ffc0c4f5aed0d142fd8a8913530 which added libhfsuser (and others under lib/) to the include path in order to fix inconsistencies building with the bundled vs system utf8proc/ublio. But this also means that the couple of internal headers in those dirs are also added to the path, and since gcc/clang search locations added with -I
before system ones, the effect is that when sys/stat.h includes <features.h>
libhfsuser's features.h is being included instead.
Renaming the header isn't enough of a solution here because the project shouldn't really be organized in a way that requires the build system to do this. I think the correct thing here would be to just restructure libhfs and libhfsuser so that only their public headers (ones that would be installed with make install-lib
) are added to the search path and deal with ublio/utf8proc separately. I'll push up a fix a bit later.
I'll push up a fix a bit later.
Excellent. Ping me and I will test it.
@ttsiodras I decided to go with a much simpler solution of using -iquote
for these includes since this fits better with how the libs are being used internally. Confirmed https://github.com/0x09/hfsfuse/commit/32a77edb422443ed82a91f6d06e0f5966d221c7f resolves this specific issue on other systems with glibc, but should stop the issue of polluting the include path in general.
I just tested it - works great.
Thank you!
@ttsiodras great, thanks for reporting this.
Hi. Thank you for creating hfsfuse, it is really useful - but I wanted to share an issue I had and how I solved it, when I needed to compile the code under an ARM board (a Rock-PI-S running Armbian).
Using
make
led to this:...which looked weird - why does this code work in other platforms?
Looking things up, I realised I had to
#include
"features.h" - so I did......only to find that the compilation still fails with the same error. After some more head-scratching, and adding "-save-temps" to see exactly what happens during preprocessing, I realized why this patch failed...
There's a "features.h" in our own code - that somehow takes precedence! (even though I used angle brackets - that should prioritize the system-provided header instead of the one under
lib/libhfsuser/features.h
)So, as a quick hack, I changed the
#include
to ......and after doing this patch in one more place, everything worked perfectly.
I am not sure how this can be addressed. I thought of preparing a PR where I rename this code's "features.h" to a filename that doesn't clash with mainstream OSes default header files, but realised you may very well object to this - so I instead opened this issue. For completeness, these are the two patches I had to make for the code to compile: