Bug 74171 - Attempting to build recent version of e2fsprogs from git repo gives config.h missing
Summary: Attempting to build recent version of e2fsprogs from git repo gives config.h ...
Status: RESOLVED UNREPRODUCIBLE
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-16 10:27 UTC by George R. Goffe
Modified: 2014-04-17 21:31 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.13.9-100.fc19.x86_64
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description George R. Goffe 2014-04-16 10:27:44 UTC
This is my first time attempting to build e2fsprogs from the git repo. I'm getting a failure with config.h missing. Here's a sample of the error message. I have a complete build log available if needed.

../../../lib/uuid/unparse.c:35:20: fatal error: config.h: No such file or directory

This is a fedora 19 x86_64 system.
Comment 1 Theodore Tso 2014-04-17 14:47:05 UTC
The lib/config.h file is generated by the configure script.

Please take a look at the the instructions in the INSTALL file for how to build e2fsprogs.
Comment 2 George R. Goffe 2014-04-17 17:22:27 UTC
Theodore,

Thanks for your response and the time you spent formulating it.

I have found the problem.

By the way, I did read INSTALL and followed it's directives.

The problem is that when I build software I run make distclean then configure then make clean depend then make then make install.

The make clean in this case removes the config.h file, hence the failures. My thoughts about make clean are that this removes build products, object files, etc.

I've seen other software that has this problem as well and have no-oped the make clean in my build scripts.

My question to you is, "Should the config.h file and whatever configure generates be part of the clean target or should it be part of make distclean"?

Regards,

George...
Comment 3 George R. Goffe 2014-04-17 18:40:48 UTC
Theodore,

I disabled make clean for now.

Next error: 

gcc -I. -I../../lib -I../../../lib -g -O2 -checker -g -o checker/error_message.o -c ../../../lib/et/error_message.c
gcc: error: unrecognized command line option ‘-checker’

I get this with my Fedora 19 gcc version AND the experimental gcc from the gcc trunk. I have used the --enable-checker option in configure.


Commented out the checker option and now am getting:

../../../lib/ext2fs/ext2fs.h:573:3: warning: #warning "Compression support is experimental" [-Wcpp]
  #warning "Compression support is experimental"
   ^
../../../lib/ext2fs/crc32c.c:71:26: fatal error: crc32c_table.h: No such file or directory
 #include "crc32c_table.h"
                          ^
compilation terminated.
make[2]: *** [crc32c.o] Error 1
make[2]: Leaving directory `/sdc1/exphome/clipper/export/home/tools/e2fsprogs/e2fsprogs/build/lib/ext2fs'
make[1]: *** [all-libs-recursive] Error 1
make[1]: Leaving directory `/sdc1/exphome/clipper/export/home/tools/e2fsprogs/e2fsprogs/build'
make: *** [all] Error 2


It just keeps getting better doesn't it?


Regards,

George...
Comment 4 Theodore Tso 2014-04-17 21:31:04 UTC
> gcc: error: unrecognized command line option ‘-checker’

See: http://www.gnu.org/software/checker/   for an explanation.  It's something the gcc folks stopped supporting, and I never got around to getting rid of the configure option.

As far as the missing "crc32c_table.h", that looks like "make depend" is not working on your setup.   I'd recommend getting the original Makefile.in files from upstream, and not trying to run "make depend".   I run it before I do a release, but it's never something I've tried to make to be fully portable and bulletproof for every single possible VPATH setting, etc.   It's intended for use by developers, and not for random users who are trying to build e2fsprogs.

For similar reasons, that's why I also ship a generated configure script --- because I got tired of random breakages caused by people happening to use a different version of autoconf than what I happened to be developing against.  autoconf, automake, etc., are inherently fragile solutions.  You really should be using the version of configure and the Makefile.in files that I shipped.  If you try to regenerate them, you're just asking for trouble.

Why don't you follow the INSTALL directions exactly.  That will work.  Other things, well, feel free to send me patches.  :-)

Note You need to log in before you can comment on or make changes to this bug.