Question about std=gnu99
ofajardo opened this issue · 2 comments
Hi
I am building my project pyreadr using multibuild here. This project wraps a C library librdata.
The project has been building the wheels fine for about a year. There was a change in the librdata code recently that triggered an error when compiling on linux (mac and windows still fine):
pyreadr/libs/librdata/src/rdata_read.c:1110:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i=0; i<vals[0]; i++) {
^
pyreadr/libs/librdata/src/rdata_read.c:1110:9: note: use option -std=c99 or -std=gnu99 to compile your cod
which was a bit strange already because I see these kind of declarations everywhere in the old code that was working.
Anyway, I went ahead and did a env_vars.sh passing std=c99. That make the thing compile fine and pass the tests (strange also because on my dev computer that make tests to fail), but when installing the wheels on any other linux machine a segmentation fault comes. Mac and Windows are fine (why?).
Changing to std=gnu99 fixes everything. It compiles on every platform and the wheels are usable (have to test windows still).
So it seems that's the solution, but I would like to understand a bit better what is happening:
1- Is multibuild using centos under the hood? I see some yums here and there in the code. I assume that gcc on centos is old (4.8 or so) so the default standard is c90 and therefore I need std=gnu99, while on ubuntu 18.04 (the image declared on my
.travis.yml and on my dev machine) it is gcc 7.5 where the standard should be c11 and that's why on my local machine I don't need std=c99?
2- Is The content of the env_vars.sh used for all of linux, mac and windows? I am surprised that now every system is happy while I was expecting that mac and windows would fail ... (altough on windows I am compiling right now with mingw so maybe that's why, but in the future I will migrate to MSVC, so I would like to know what's happening here). Is it safer to declare the std=gnu99 on my setup.py for linux only instead of env_vars?
thanks!
Yes, the manylinux images are on CentOS. In particular manylinux1 is on CentOS 5 - so very old - although the gcc is a little more recent. I wonder whether it's time to upgrade to manylinux2010 or manylinux2014?
Yes, env_vars.sh
gets used on Linux and Mac, but not Windows.
I have no idea about the segfault - but it would be very very useful if you'd consider posting an issue at https://github.com/pypa/manylinux
Does that help?
yep! that clarifies it. I'll file an issue about the segfault in manylinux as you suggest. Thanks!