| Message ID | 1495013164-2939-1-git-send-email-Qiang.Yu@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Qiang Yu, On 17 May 2017 at 10:26, Qiang Yu <Qiang.Yu@amd.com> wrote: > error log: > xf86drm.c: In function 'parse_separate_sysfs_files': > xf86drm.c:3104:5: error: 'for' loop initial declarations are only allowed in C99 mode > for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) { > ^ > xf86drm.c:3104:5: note: use option -std=c99 or -std=gnu99 to compile your code > make[4]: *** [libdrm_la-xf86drm.lo] Error 1 > configure should error out if the compiler does not support C99. Are you explicitly patching that out? Why can't we use a C99 in 2017 - gcc and clang has supported it for 10+ years. Thanks Emil
Hi Emil, I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure pass but fail when compile. I think my gcc support c99 but needs adding "-std=c99" to enable it, and the configure script add it into CC variable. When just use "make", it's OK, but my build script uses "make CC=gcc". If you think current state is OK, I can change my build script for that. Regards, Qiang
On 17 May 2017 at 14:58, Yu, Qiang <Qiang.Yu@amd.com> wrote: > Hi Emil, > > I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure pass but > fail when compile. > > I think my gcc support c99 but needs adding "-std=c99" to enable it, and the configure > script add it into CC variable. When just use "make", it's OK, but my build script uses > "make CC=gcc". > > If you think current state is OK, I can change my build script for that. > Overrides shouldn't be used normally. If needed, one has to be very careful what they set them to. So the question is: why do you set CC - is there something broken on our end? Add "-std=c99" is fine, but I'd suggest dropping the override all together. Thanks Emil
2017-05-18 0:10 GMT+08:00 Emil Velikov <emil.l.velikov@gmail.com>: > On 17 May 2017 at 14:58, Yu, Qiang <Qiang.Yu@amd.com> wrote: >> Hi Emil, >> >> I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure pass but >> fail when compile. >> >> I think my gcc support c99 but needs adding "-std=c99" to enable it, and the configure >> script add it into CC variable. When just use "make", it's OK, but my build script uses >> "make CC=gcc". >> >> If you think current state is OK, I can change my build script for that. >> > Overrides shouldn't be used normally. If needed, one has to be very > careful what they set them to. > > So the question is: why do you set CC - is there something broken on our end? > Add "-std=c99" is fine, but I'd suggest dropping the override all together. Indeed it also causes building error on Android before and include 6.0. Adding "-std=c99" will result in more strange errors that I can't understand. So I have to make a similar change to avoid it.
On Wednesday, 2017-05-17 13:58:42 +0000, Yu, Qiang wrote: > Hi Emil, > > I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure pass but > fail when compile. > > I think my gcc support c99 but needs adding "-std=c99" to enable it, and the configure > script add it into CC variable. From the AC_PROG_CC_C99 docs: > If the C compiler is not in C99 mode by default, try to add an option > to output variable `CC` to make it so. Grrrr... Add that to the pile of reasons to move away from autotools, I suppose. > When just use "make", it's OK, but my build script uses > "make CC=gcc". > > If you think current state is OK, I can change my build script for that. Yes, I think you should change your build command. It's a shame that autotools has this bug, but we'd like to avoid changing our codebase to work around these, and in this case, it would mean dropping the C99 requirement and having to downgrade the whole codebase to something older. > > Regards, > Qiang > ________________________________________ > From: Emil Velikov <emil.l.velikov@gmail.com> > Sent: Wednesday, May 17, 2017 9:17:53 PM > To: Yu, Qiang > Cc: ML dri-devel > Subject: Re: [PATCH libdrm] xf86drm: fix compile error for declare i in for loop > > Hi Qiang Yu, > > On 17 May 2017 at 10:26, Qiang Yu <Qiang.Yu@amd.com> wrote: > > error log: > > xf86drm.c: In function 'parse_separate_sysfs_files': > > xf86drm.c:3104:5: error: 'for' loop initial declarations are only allowed in C99 mode > > for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) { > > ^ > > xf86drm.c:3104:5: note: use option -std=c99 or -std=gnu99 to compile your code > > make[4]: *** [libdrm_la-xf86drm.lo] Error 1 > > > configure should error out if the compiler does not support C99. Are > you explicitly patching that out? > Why can't we use a C99 in 2017 - gcc and clang has supported it for 10+ years. > > Thanks > Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 17 May 2017 at 19:16, Eric Engestrom <eric.engestrom@imgtec.com> wrote: > On Wednesday, 2017-05-17 13:58:42 +0000, Yu, Qiang wrote: >> Hi Emil, >> >> I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure pass but >> fail when compile. >> >> I think my gcc support c99 but needs adding "-std=c99" to enable it, and the configure >> script add it into CC variable. > > From the AC_PROG_CC_C99 docs: >> If the C compiler is not in C99 mode by default, try to add an option >> to output variable `CC` to make it so. > > Grrrr... Add that to the pile of reasons to move away from autotools, > I suppose. > You do realise that cmake, meson and others have similar helper/macros, right? >> When just use "make", it's OK, but my build script uses >> "make CC=gcc". >> >> If you think current state is OK, I can change my build script for that. > > Yes, I think you should change your build command. It's a shame that > autotools has this bug, but we'd like to avoid changing our codebase to > work around these, and in this case, it would mean dropping the C99 > requirement and having to downgrade the whole codebase to something > older. > Again you're miles off, I'm afraid. Overrides is a make thing, which allows you to use [normally temporary] clever things. For example: - increase/decrease warning levels of part A in your project - change optimisation level of components B At the same time, if you do stupid things you get to pick the pieces. -Emil
On Thursday, 2017-05-18 12:10:31 +0100, Emil Velikov wrote: > On 17 May 2017 at 19:16, Eric Engestrom <eric.engestrom@imgtec.com> wrote: > > On Wednesday, 2017-05-17 13:58:42 +0000, Yu, Qiang wrote: > >> Hi Emil, > >> > >> I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure pass but > >> fail when compile. > >> > >> I think my gcc support c99 but needs adding "-std=c99" to enable it, and the configure > >> script add it into CC variable. > > > > From the AC_PROG_CC_C99 docs: > >> If the C compiler is not in C99 mode by default, try to add an option > >> to output variable `CC` to make it so. > > > > Grrrr... Add that to the pile of reasons to move away from autotools, > > I suppose. > > > You do realise that cmake, meson and others have similar helper/macros, right? The macro isn't my issue, the fact that it puts its flags in $CC instead of $*FLAGS is. This, as well as the fact that setting $CC beforehand overrides it (the macro should append), is what I consider a bug in autotools. (Honestly, I don't remember if cmake/meson/others do the same thing) > > >> When just use "make", it's OK, but my build script uses > >> "make CC=gcc". > >> > >> If you think current state is OK, I can change my build script for that. > > > > Yes, I think you should change your build command. It's a shame that > > autotools has this bug, but we'd like to avoid changing our codebase to > > work around these, and in this case, it would mean dropping the C99 > > requirement and having to downgrade the whole codebase to something > > older. > > > Again you're miles off, I'm afraid. > > Overrides is a make thing, which allows you to use [normally > temporary] clever things. > For example: > - increase/decrease warning levels of part A in your project > - change optimisation level of components B I have no issue with any of this, as long as flags are in $*FLAGS :) > > At the same time, if you do stupid things you get to pick the pieces. > > -Emil
On 18 May 2017 at 13:47, Eric Engestrom <eric.engestrom@imgtec.com> wrote: >> > Yes, I think you should change your build command. It's a shame that >> > autotools has this bug, but we'd like to avoid changing our codebase to >> > work around these, and in this case, it would mean dropping the C99 >> > requirement and having to downgrade the whole codebase to something >> > older. >> > >> Again you're miles off, I'm afraid. >> >> Overrides is a make thing, which allows you to use [normally >> temporary] clever things. >> For example: >> - increase/decrease warning levels of part A in your project >> - change optimisation level of components B > > I have no issue with any of this, as long as flags are in $*FLAGS :) > AFAICT things such as -std=c99 belong to CC, since it implies the compiler itself. In a same way the "single-Unix-approved" /usr/bin/c99 does "exec gcc -std=c99 ${1+"$@"}" -Emil
On 18 May 2017 at 14:46, Emil Velikov <emil.l.velikov@gmail.com> wrote: > On 18 May 2017 at 13:47, Eric Engestrom <eric.engestrom@imgtec.com> wrote: > >>> > Yes, I think you should change your build command. It's a shame that >>> > autotools has this bug, but we'd like to avoid changing our codebase to >>> > work around these, and in this case, it would mean dropping the C99 >>> > requirement and having to downgrade the whole codebase to something >>> > older. >>> > >>> Again you're miles off, I'm afraid. >>> >>> Overrides is a make thing, which allows you to use [normally >>> temporary] clever things. >>> For example: >>> - increase/decrease warning levels of part A in your project >>> - change optimisation level of components B >> >> I have no issue with any of this, as long as flags are in $*FLAGS :) >> > AFAICT things such as -std=c99 belong to CC, since it implies the > compiler itself. > In a same way the "single-Unix-approved" /usr/bin/c99 does "exec gcc > -std=c99 ${1+"$@"}" > Final note, hope it's not getting too tedious. You really want to set the compiler/etc before configure stage. Changing anything at make time can and will fail. For example: a) configure adds -std=c99 to CFLAGS b) you change the compiler to sunpro/etc (uses -xc99/-c99/etc) c) boom. -Emil
diff --git a/xf86drm.c b/xf86drm.c index 728ac78..dc028cc 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -3100,8 +3100,9 @@ static int parse_separate_sysfs_files(int maj, int min, unsigned int data[ARRAY_SIZE(attrs)]; FILE *fp; int ret; + unsigned i; - for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) { + for (i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) { snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/%s", maj, min, attrs[i]); fp = fopen(path, "r");
error log: xf86drm.c: In function 'parse_separate_sysfs_files': xf86drm.c:3104:5: error: 'for' loop initial declarations are only allowed in C99 mode for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) { ^ xf86drm.c:3104:5: note: use option -std=c99 or -std=gnu99 to compile your code make[4]: *** [libdrm_la-xf86drm.lo] Error 1 Signed-off-by: Qiang Yu <Qiang.Yu@amd.com> --- xf86drm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)