I'm porting over a large, old system that was known to work, onto Ubuntu 64-bit Linux. The system uses FLTK, upgrading to 1.3.2, and I'm using NetBeans. A file includes basic universal /FL/Fl.H as its first line. This includes the newer unicode enabler /FL/fl_utf8.h. This includes system file <sys/stat.h>, which then includes system file <bits/stat.h>. When wiring this up, and -I including various different directories, all of a sudden the system files break at compile time with:
In file included from /usr/include/sys/stat.h:107,
/usr/include/bits/stat.h:88: error: field ‘st_atim’ has incomplete type
/usr/include/bits/stat.h:89: error: field ‘st_mtim’ has incomplete type
/usr/include/bits/stat.h:90: error: field ‘st_ctim’ has incomplete type
/usr/include/bits/stat.h:149: error: field ‘st_atim’ has incomplete type
/usr/include/bits/stat.h:150: error: field ‘st_mtim’ has incomplete type
/usr/include/bits/stat.h:151: error: field ‘st_ctim’ has incomplete type
Is the latest FLTK not working? Allergic to 64 bits? Internet suggests bug in a system header file? glibc is incompatible? Add _GNU_SOURCE? Don't USE_MISC? Lots of flailing in the blogs, what's going on here?
The short answer: Someone, somewhere, has created a random file entitled "time.h". Your include path has included the directory this is in. This is short-circuiting the system in a non-obvious way. The file doesn't even have to be used, it could be a random test scratch file that one of the programmers put together on the side, not incorporated in. It simply has to exist, and be reachable in your greater include path. This will be enough to hose you. Not a FLTK problem at all.
The longer answer: stat.h got upgraded from based on __time_t st_atime etc. to being based on struct timespec st_atim etc. [note missing e on end] for handling nanosecond resolution timestamps. But timespec is defined in the system's time.h. If you include a random time.h somewhere in your path, this shadows the include, wiping out the definition of struct timespec.
Apparently this same issue is also a problem with FFMpeg v1.0 and /include/libavutil.
Bottom line: Insist no one ever makes a file called "time.h".
There is actually a pretty solid quick fix I used when I was having this problem in Centos 6.5. Thought I would share in case anyone else stumbles across this thread. There is a repository made and maintained by https://github.com/tony2001 that fixes this issue with time.h files conflicting.
Follow the below to fix it:
git clone https://github.com/tony2001/ffmpeg-php.git
cd ffmpeg-php
phpize
./configure
make && make install
I realize this question is old, but I will post my experience since I am just going through the book right now and this happened to me. I was able to fix the issue by restarting the virtual computer I am running the disk on.
What I think happened for me was that I was running the virtual machine by mounting the disk image to one of my computer's virtual drives. When I was done with working for the day, I would save my virtual machines state and then load the state and keep working on it later on. However, I would sometimes restart my physical computer which unmounts the cd image from my drive, but I didn't notice this because the virtual machine would start up with no problems since I was just reloading the save state, until your issue happened to me.
Remounting the disk image and then restarting the virtual machine solved the issue for me, and it might for others who are running the livecd image through a virtual machine. The only other thing I can think that would explain this is that some of the book's programs might mess up some of includes and restarting just reverts the machine back into its original, working state.
If you are running the disk physically, this probably won't help you, but restarting your computer might be a good thing to try. As a side note, I was originally running the cd physically on my old laptop and all the book's programs worked fine. This was frustrating since the virtual machine was giving me problems that I didn't originally have running the actual disk, physically.
