can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert]

[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