[redirected from the main Cygwin ML]
Hi Corinna,
Corinna Vinschen via Cygwin wrote:
On Aug 25 22:50, Mark Geisert via Cygwin wrote:
Hi Corinna,
Corinna Vinschen via Cygwin wrote:
On Aug 24 14:39, Mark Geisert via Cygwin wrote:
Denis Excoffier via Cygwin wrote:
Hello,
When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following
error messages (see below).
There seems to be a kind of loop in the hierarchy of #includes.
It is not a loop.
Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i
removethe 2 #includes from /usr/include/sys/cpuset.h,
this is also ok.
This is an important clue.
Regards,
Denis Excoffier.
[...compilation log excerpt elided here...]
Usually it's easily fixable. There's typically no loop because
of the guards, e.g.
#ifndef _SYS_CPUSET_H_
#define _SYS_CPUSET_H_
but some guarding can have side effects.
However, somebody needs to come up *at least* with a simple reproducer.
It can be reproduced by running 'cygport coreutils.cygport build' in a
prep'd coreutils source directory e.g. /usr/src/coreutils-9.0-1.src .
Excerpt follows:
This is not what I meant. A simple reproducer is ideally a piece of
C code which shows ;the problem with a minimum of code. In this case,
a pice of C code with the #includes required to reproduce the compiler
failing is what I'm looking for.
I've always been supportive of the notion of STCs, but for this issue it would
mean duplicating a bunch of coreutils-build-built include files (in its lib
directory) and I decided, why not just cut the coreutils build process back to the
first compilation that exhibits the error?
So I modified coreutils.cygport to change "cygmake" to "cygmake --trace" and ran
'cygport build' to see all gcc commands as they're executed. I then extracted the
gcc command that compiles chroot.c to a new STC shell script where I could modify
gcc options at will. I changed "-c" to "-E" to see the sequence of include file
usage and where #defines actually happen.
From this I discovered that pthread_attr_t and pthread_t defs are missing because
sys/_pthreadtypes.h includes sys/cpuset.h which starts a whole include chain
ending up in sys/signal.h where the defs are needed. Note they are defined in
sys/_pthreadtypes.h where we started, but haven't been seen yet because
sys/cpuset.h has gone off on this detour.
Similarly, the timestruc_t def is missing because sys/_pthreadtypes.h again starts
an include chain that ends up in sys/stat.h where the def is needed. Note
timestruc_t is defined in machine/types.h, which is included (by sys/types.h)
after sys/_pthreadtypes.h, so the def hasn't been seen yet because of a similar
detour.
The fix I'm considering is to
(1) move sys/_pthreadtypes.h's "#include sys/cpuset.h" to just before its final
#endif, and
(2) exchange the positions of "#include <sys/_pthreadtypes.h>" and "#include
<machine/types.h>" within sys/types.h.
I could submit for review a patch to do these things.
An alternative would be to somehow massage the coreutils build
include-file-wrapping to accomplish the same end. I personally don't have the
time or skills to figure that out.
I hope this info is usable in one form or another.
Regards,
..mark
