Created attachment 521542 [details] f2fs-tools-1.10.0:20180301-110943.log.gz sys-fs/f2fs-tools-1.6.1 build fine and sys-fs/f2fs-tools-1.9.0 was previously installed. version 1.10.0 fail at link phase, it cannot find major/minor used in fibmap.c void print_stat(struct stat *st) #endif { printf("--------------------------------------------\n"); printf("dev [%d:%d]\n", major(st->st_dev), minor(st->st_dev)); printf("ino [0x%8"PRIx64" : %"PRIu64"]\n", relevant error message (full log attached) x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/uuid -I../include -Wall -O3 -march=corei7 -pipe -grecord-gcc-switches -w -fpermissive -c -o fibmap.o fibmap.c /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -O3 -march=corei7 -pipe -grecord-gcc-switches -w -fpermissive -Wl,-O1,--sort-common,--hash-style=gnu -o fibmap.f2fs fibmap.o libtool: link: x86_64-pc-linux-gnu-gcc -Wall -O3 -march=corei7 -pipe -grecord-gcc-switches -w -fpermissive -Wl,-O1 -Wl,--sort-common -Wl,--hash-style=gnu -o fibmap.f2fs fibmap.o fibmap.o: In function `print_stat': fibmap.c:(.text+0x5b): undefined reference to `minor' fibmap.c:(.text+0x67): undefined reference to `major' fibmap.o: In function `main': fibmap.c:(.text.startup+0x9e): undefined reference to `minor' fibmap.c:(.text.startup+0xad): undefined reference to `major' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:455: fibmap.f2fs] Error 1 make[2]: Leaving directory '/var/tmp/portage/sys-fs/f2fs-tools-1.10.0/work/f2fs-tools-1.10.0/tools' make[1]: *** [Makefile:414: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-fs/f2fs-tools-1.10.0/work/f2fs-tools-1.10.0' make: *** [Makefile:346: all] Error 2 * ERROR: sys-fs/f2fs-tools-1.10.0::gentoo failed (compile phase):
Same here.
I believe this has happened before in other versions of f2fs-tools. See bug # 623660
Created attachment 521730 [details, diff] f2fs-tools-1.10.0-fibmap-include-config_h.patch There is a slightly different cause this time: tools/fibmap.c fails to #include "config.h". The attached patch fixes it. This should be pushed upstream.
(In reply to Matt Whitlock from comment #3) > Created attachment 521730 [details, diff] [details, diff] > f2fs-tools-1.10.0-fibmap-include-config_h.patch > > There is a slightly different cause this time: tools/fibmap.c fails to > #include "config.h". > > The attached patch fixes it. This should be pushed upstream. Nice, works here. Thanks
(In reply to Matt Whitlock from comment #3) > Created attachment 521730 [details, diff] [details, diff] > f2fs-tools-1.10.0-fibmap-include-config_h.patch > > There is a slightly different cause this time: tools/fibmap.c fails to > #include "config.h". > > The attached patch fixes it. This should be pushed upstream. Thank you very MUCH.
I had the same issue here, worked around it by removing the #ifdef statement for sysmacros.h from fibmap.c This was unelegant, but worked for my uneducated approach. Your patch fixes this in an elegant and proper way. THANK YOU VERY MUCH FOR THE GOOD WORK DONE!!!!
same problem, patch solved it, why wub woo <3
(In reply to Matt Whitlock from comment #3) > Created attachment 521730 [details, diff] [details, diff] > f2fs-tools-1.10.0-fibmap-include-config_h.patch > > There is a slightly different cause this time: tools/fibmap.c fails to > #include "config.h". > > The attached patch fixes it. This should be pushed upstream. Okay I added the patch. I'm not sure why I didn't hit this problem when I tested. Are you going to submit this upstream?
(In reply to Anthony Basile from comment #8) > Are you going to submit this upstream? Well, I would kind of hope that upstream notices and fixes this on their own. Their software can't even be built without this fix, so it should be immediately and painfully obvious to them what needs to be done. Kind of calls into question the quality control of their release engineering process. :/
(In reply to Matt Whitlock from comment #9) > (In reply to Anthony Basile from comment #8) > > Are you going to submit this upstream? > > Well, I would kind of hope that upstream notices and fixes this on their > own. Their software can't even be built without this fix, so it should be > immediately and painfully obvious to them what needs to be done. Kind of > calls into question the quality control of their release engineering > process. :/ We have not determined why it builds on some systems and not others. I just test built on a fresh stage3 and it worked without your patch. Nonetheless others are having problems and including that config.h fixes it for them and it is safe. So "I would kind of hope" is resting on the assumption that they will hit the same error upstream. Upstream bug reporting is pretty much non-existent, so you're right about the lack of QA. Still they should be made aware of this bug. I'll take your answer as a "no" you're not sending them anything and I'll email them.
