Discussion:
compiler error on macOS Siera with GCC@6.2.1
(too old to reply)
Eric Blake
2016-09-23 17:51:39 UTC
Permalink
Raw Message
[adding gnulib]
Dear developers,
./sched.h:42:8: error: redefinition of 'struct sched_param'
struct sched_param
^~~~~~~~~~~
In file included from ./sched.h:27:0,
from ./spawn.h:37,
/usr/include/sched.h:35:8: note: originally defined here
struct sched_param { int sched_priority; char __opaque[__SCHED_PARAM_SIZE__]; };
^~~~~~~~~~~
Thanks for the report.

Can you look in config.log, and see why configure seems to think that
HAVE_STRUCT_SCHED_PARAM was set to 0 on your platform (since it is
obvious from the error message that your platform DOES have struct
sched_param after all)? Is this a case of you doing incremental
compilation, where the cache variables are from one run on an earlier
version of macOS, and not updated for the change in headers when you
moved to Sierra? If so, does a fresh build change things? Can you work
around the issue by setting appropriate cache variables during the
configure run?

It may be that something in the new macOS Sierra headers is causing
gnulib's configure probe to misbehave at detecting whether sched_param
is defined, and that gnulib needs to be taught how to work with the
updated headers. Once gnulib is working, then m4 needs to update to a
newer version of gnulib.

Sadly, I don't have access to macOS myself (I'm not a fan of paying for
an operating system when free software does the job just as well), so it
will have to be a patch submitted and tested by someone else.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Denis Davydov
2016-09-23 18:19:17 UTC
Permalink
Raw Message
Hi Eric,

Thanks for the swift reply.
Post by Eric Blake
[adding gnulib]
Dear developers,
./sched.h:42:8: error: redefinition of 'struct sched_param'
struct sched_param
^~~~~~~~~~~
In file included from ./sched.h:27:0,
from ./spawn.h:37,
/usr/include/sched.h:35:8: note: originally defined here
struct sched_param { int sched_priority; char __opaque[__SCHED_PARAM_SIZE__]; };
^~~~~~~~~~~
Thanks for the report.
Can you look in config.log, and see why configure seems to think that
HAVE_STRUCT_SCHED_PARAM was set to 0 on your platform (since it is
it is indeed set to 0. Searching for HAVE_STRUCT_SCHED_PARAM in config.log
reveals a single line only, so i don’t know where it is set and why.
Config log is attached.
Post by Eric Blake
obvious from the error message that your platform DOES have struct
sched_param after all)? Is this a case of you doing incremental
compilation, where the cache variables are from one run on an earlier
version of macOS, and not updated for the change in headers when you
moved to Sierra? If so, does a fresh build change things? Can you work
no, it’s not incremental build. It is a build within Spack package manager with a fresh
build folder, see https://github.com/LLNL/spack/issues/1838
Post by Eric Blake
around the issue by setting appropriate cache variables during the
configure run?
I tried adding

HAVE_STRUCT_SCHED_PARAM=1

to ./configure but it does not change anything. How do I do that?

Regards,
Denis.
Denis Davydov
2016-09-23 18:37:23 UTC
Permalink
Raw Message
Hi Eric,
Post by Denis Davydov
Post by Eric Blake
Can you look in config.log, and see why configure seems to think that
HAVE_STRUCT_SCHED_PARAM was set to 0 on your platform (since it is
it is indeed set to 0. Searching for HAVE_STRUCT_SCHED_PARAM in config.log
reveals a single line only, so i don’t know where it is set and why.
I think here’s a relevant part of the log:

configure:28741: /Users/davydden/spack/lib/spack/env/gcc/gcc -c -g -O2 -I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include conftest.c >&5
In file included from /usr/include/sched.h:27:0,
from conftest.c:274:
/usr/include/pthread_impl.h:32:18: error: missing binary operator before token "("
#if __has_feature(assume_nonnull)
^
/usr/include/pthread_impl.h:62:18: error: missing binary operator before token "("
#if __has_feature(assume_nonnull)
^
conftest.c:277:8: error: unknown type name 'pid_t'
pid_t t1;
^~~~~
configure:28741: $? = 1

configure:28828: checking for struct sched_param
configure:28828: /Users/davydden/spack/lib/spack/env/gcc/gcc -c -g -O2 -I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include conftest.c >&5
In file included from /usr/include/sched.h:27:0,
from conftest.c:273:
/usr/include/pthread_impl.h:32:18: error: missing binary operator before token "("
#if __has_feature(assume_nonnull)
^
/usr/include/pthread_impl.h:62:18: error: missing binary operator before token "("
#if __has_feature(assume_nonnull)
^
configure:28828: $? = 1


p.s. Not sure if config should actually use anything from `/usr/include/sched.h` as I compile with GCC, not Clang. M4 compiles fine with apple's Clang.

Regards,
Denis.
Paul Eggert
2016-09-23 19:11:30 UTC
Permalink
Raw Message
Post by Denis Davydov
/usr/include/pthread_impl.h:32:18: error: missing binary operator before token "("
#if __has_feature(assume_nonnull)
My guess is that sched.h isn't including sys/cdefs.h as it should on
Darwin. The Darwin guys are not that big on supporting GCC, I'm afraid.

Does the attached gnulib patch work around the Darwin bug for you?
errno.h is just a way to get cdefs.h included.
Denis Davydov
2016-09-23 20:16:29 UTC
Permalink
Raw Message
Hi Paul,

I adjusted your patch for 1.4.17 but I now have

m4-1.4.17/build-aux/missing: line 81: aclocal-1.14: command not found

It could be that have errors in my version of the patch. Would you please send the patch which applies to 1.4.17
or check the one I have attached?

Regards,
Denis.
Post by Denis Davydov
/usr/include/pthread_impl.h:32:18: error: missing binary operator before token "("
#if __has_feature(assume_nonnull)
My guess is that sched.h isn't including sys/cdefs.h as it should on Darwin. The Darwin guys are not that big on supporting GCC, I'm afraid.
Does the attached gnulib patch work around the Darwin bug for you? errno.h is just a way to get cdefs.h included.
<sched.diff>
Denis Davydov
2016-09-23 20:35:53 UTC
Permalink
Raw Message
Yes, this patch also fix the problem.
It looks like your guess about the source of the problem is correct.
I probably should find a way how to report it to Apple...

p.s. attached is a p1 version
Post by Denis Davydov
Would you please send the patch which applies to 1.4.17
Something like the attached, perhaps?
<configure.patch>
Eric Blake
2016-09-23 20:25:29 UTC
Permalink
Raw Message
Post by Denis Davydov
Hi Paul,
I adjusted your patch for 1.4.17 but I now have
m4-1.4.17/build-aux/missing: line 81: aclocal-1.14: command not found
Do you have autotools installed on your machine? If so, 'autoreconf
-vfi' should clear up that issue.

But your patch to the m4 sources look like the workaround that Paul
proposed testing. (Ideally, the real gnulib patch will be to provide a
replacement sched.h on affected systems that pre-includes the missing
setup, so that clients don't have to find and adjust all places where
<sched.h> is included; but right now, we're trying to establish whether
that will even be a viable approach for gnulib to take)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Paul Eggert
2016-09-25 04:16:48 UTC
Permalink
Raw Message
I attempted to fix the problem by installing the attached patch into gnulib
master. I can't easily test this, though, as I don't have macOS. Can you please
try running the following shell commands on a macOS host, and see whether the
last one succeeds? You'll need the autotools installed. Thanks.

git clone git://git.savannah.gnu.org/gnulib.git
cd gnulib
./gnulib-tool --test sched
Tom G. Christensen
2016-10-17 14:38:46 UTC
Permalink
Raw Message
Post by Paul Eggert
I attempted to fix the problem by installing the attached patch into
gnulib master. I can't easily test this, though, as I don't have macOS.
The patch did not include the substitution of HAVE_SYS_CDEFS_H needed
when creating sched.h.

Below is from a CentOS 5 host:

make[4]: Entering directory
`/home/tgc/tmp/daily_build/gnulib/000-gnulib-simple-59aa69f/gllib'
depbase=`echo glthread/cond.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\"
-DNO_XMALLOC -DEXEEXT=\"\" -I. -I.. -DGNULIB_STRICT_CHECKING=1
-fvisibility=hidden -g -O2 -MT glthread/cond.o -MD -MP -MF $depbase.Tpo
-c -o glthread/cond.o glthread/cond.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/pthread.h:24,
from ./glthread/lock.h:90,
from ./glthread/cond.h:56,
from glthread/cond.c:23:
./sched.h:27:6: error: token "@" is not valid in preprocessor expressions

$ sed -n '27p' gllib/sched.h
# if @HAVE_SYS_CDEFS_H@

-tgc
Tom G. Christensen
2016-10-20 06:23:42 UTC
Permalink
Raw Message
Post by Tom G. Christensen
Post by Paul Eggert
I attempted to fix the problem by installing the attached patch into
gnulib master. I can't easily test this, though, as I don't have macOS.
The patch did not include the substitution of HAVE_SYS_CDEFS_H needed
when creating sched.h.
make[4]: Entering directory
`/home/tgc/tmp/daily_build/gnulib/000-gnulib-simple-59aa69f/gllib'
depbase=`echo glthread/cond.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\"
-DNO_XMALLOC -DEXEEXT=\"\" -I. -I.. -DGNULIB_STRICT_CHECKING=1
-fvisibility=hidden -g -O2 -MT glthread/cond.o -MD -MP -MF $depbase.Tpo
-c -o glthread/cond.o glthread/cond.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/pthread.h:24,
from ./glthread/lock.h:90,
from ./glthread/cond.h:56,
$ sed -n '27p' gllib/sched.h
I'm still seeing this error on CentOS 3, 4 and 5.

-tgc
Paul Eggert
2016-10-20 06:47:31 UTC
Permalink
Raw Message
The patch did not include the substitution of HAVE_SYS_CDEFS_H needed when
creating sched.h.
Thanks, I missed that. I installed the attached patch; does it fix things for you?
Tom G. Christensen
2016-10-20 14:21:11 UTC
Permalink
Raw Message
Post by Paul Eggert
The patch did not include the substitution of HAVE_SYS_CDEFS_H needed when
creating sched.h.
Thanks, I missed that. I installed the attached patch; does it fix things for you?
It does. Thank you!

-tgc

Eric Blake
2016-09-23 18:43:03 UTC
Permalink
Raw Message
Post by Denis Davydov
Hi Eric,
Thanks for the swift reply.
Post by Eric Blake
Can you look in config.log, and see why configure seems to think that
HAVE_STRUCT_SCHED_PARAM was set to 0 on your platform (since it is
it is indeed set to 0. Searching for HAVE_STRUCT_SCHED_PARAM in config.log
reveals a single line only, so i don’t know where it is set and why.
Config log is attached.
Thanks. The log includes:

configure:28741: /Users/davydden/spack/lib/spack/env/gcc/gcc -c -g -O2
-I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include
conftest.c >&5
In file included from /usr/include/sched.h:27:0,
from conftest.c:274:
/usr/include/pthread_impl.h:32:18: error: missing binary operator before
token "("
#if __has_feature(assume_nonnull)
^
/usr/include/pthread_impl.h:62:18: error: missing binary operator before
token "("
#if __has_feature(assume_nonnull)
^
conftest.c:277:8: error: unknown type name 'pid_t'
pid_t t1;
^~~~~
configure:28741: $? = 1
configure: failed program was:
...

| /* end confdefs.h. */
|
| #include <sched.h>
| struct sched_param a;
| int b[] = { SCHED_FIFO, SCHED_RR, SCHED_OTHER };
| pid_t t1;
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:28828: checking for struct sched_param
configure:28828: /Users/davydden/spack/lib/spack/env/gcc/gcc -c -g -O2
-I/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/gcc-6.2.0/libsigsegv-2.10-dduf3ib2khihptbot54hgma7ow2f3zcx/include
conftest.c >&5
In file included from /usr/include/sched.h:27:0,
from conftest.c:273:
/usr/include/pthread_impl.h:32:18: error: missing binary operator before
token "("
#if __has_feature(assume_nonnull)
^
/usr/include/pthread_impl.h:62:18: error: missing binary operator before
token "("
#if __has_feature(assume_nonnull)
^
configure:28828: $? = 1
configure: failed program was:
...

and it looks like the test program tried a bunch of #define followed by
an #include <sched.h> as its first header.

So something about your system is causing the inclusion of <sched.h> in
isolation to be treated as a syntax error when it calls out to
/usr/include/pthread_impl.h. I don't know what is supposed to be
happening with the __has_feature() stuff, or if including some other
header prior to <sched.h> will avoid the compilation error; but the
reason your compilation failed is because configure was unable to probe
for the presence of sched_param due to the unrelated compilation failure.

Is that something you can figure out where things are going wrong, or if
an additional header included before <sched.h> fixes things?
Post by Denis Davydov
Post by Eric Blake
around the issue by setting appropriate cache variables during the
configure run?
I tried adding
HAVE_STRUCT_SCHED_PARAM=1
to ./configure but it does not change anything. How do I do that?
./configure ac_cv_type_struct_sched_param=yes

If that works, it is basically telling configure the desired answer to
the probe (the answer that is not happening due to the unrelated syntax
error).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Denis Davydov
2016-09-23 18:49:14 UTC
Permalink
Raw Message
Post by Eric Blake
./configure ac_cv_type_struct_sched_param=yes
If that works, it is basically telling configure the desired answer to
the probe (the answer that is not happening due to the unrelated syntax
error).
this worked. Thanks for the help!

p.s. I also don’t know why those tests failed.

Regards,
Denis.
Loading...