public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mark Geisert <mark@maxrnd.com>
To: cygwin@cygwin.com
Subject: Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8
Date: Tue, 29 Aug 2023 22:36:03 -0700	[thread overview]
Message-ID: <09b77b09-ea43-15b3-1552-c924d502d2f9@maxrnd.com> (raw)
In-Reply-To: <ZOoFxp0yvqK3ZWxX@calimero.vinschen.de>

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.
>>>>> Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove the 2 #includes from /usr/include/sys/cpuset.h,
>>>>> this is also ok.
>>>>>
>>>>> 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 guess it's the include search order that has ./lib/stdlib.h being included
>> from sys/cpuset.h rather than the "<stdlib.h>" coded there.
> 
> That should break including any other header file, too, which includes
> <stdlib.h>.  Why does it only break sys/cpuset.h?
> 
>> I'm not familiar with building coreutils.  But it seems something about the
>> new #includes added to sys/cpuset.h have upset coreutils' build magic.  My
>> offer to replace the two problematic #includes with two explicit extern
>> statements still stands ;-).
> 
> Sorry, but this is not the right thing to do to fix such an issue.

Agreed.  Also, given the locus of this issue, coding an STC is problematic.  I'm 
taking this coreutils build issue to the cygwin-apps ML for further discussion.

..mark

      reply	other threads:[~2023-08-30  5:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24 17:44 Denis Excoffier
2023-08-24 21:39 ` Mark Geisert
2023-08-25  9:38   ` Corinna Vinschen
2023-08-26  5:50     ` Mark Geisert
2023-08-26 14:01       ` Corinna Vinschen
2023-08-30  5:36         ` Mark Geisert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=09b77b09-ea43-15b3-1552-c924d502d2f9@maxrnd.com \
    --to=mark@maxrnd.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).