On Tue, Sep 29, 2015 at 6:39 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >> Been trying to install/compile different R and Python packages, and >> I've been running into issues where multiple included header files >> contain the same symbols. An example could be found here >> https://github.com/Rdatatable/data.table/issues/1351, where we >> ultimately fixed the compilation error by changing the symbol names. >> >> Trying to compile numpy and other packages, and am also getting >> similar errors. When googling 'gcc aix previous declaration >> conflicting types', I see that many packages run into this problem. > > The Python Pyconfig.h header is very rude and should not be redefining > that feature-test macro, but lots of people have complained about that > for many years and the Python devs won't do anything about it. > >> My question is why does this happen only in AIX? Is there any way to >> fix this? My guess is that GCC on other OS takes the symbol from the >> first header it encounters for the particular file, and ignores the >> rest. Can one specify this behavior in AIX as well? > > No, GCC doesn't do anything like that. > > I think it's just that on other targets the types in the function > declarations do not change when _XOPEN_SOURCE=700 is defined, so the > naughty Python header causes a warning about redefining the macro, but > doesn't cause errors about conflicting function definitions. Thank you for your response. So it sounds like there's no way to get this compiled on AIX other than a fix on the python header by the devs? And I suppose that wouldn't change given your experience. As I mentioned before, I ran into something similar (at least I think is similar) when compiling an R package: gcc -std=gnu99 -I/sas/outmva/opt/lib/R/include -DNDEBUG -I/usr/local/include -mno-fp-in-toc -g -O2 -c assign.c -o assign.o gcc -std=gnu99 -I/sas/outmva/opt/lib/R/include -DNDEBUG -I/usr/local/include -mno-fp-in-toc -g -O2 -c bmerge.c -o bmerge.o bmerge.c:25:17: error: 'nearest' redeclared as different kind of symbol static Rboolean nearest=FALSE, enc_warn=TRUE; ^ In file included from /sas/outmva/opt/lib/R/include/R.h:31:0, from data.table.h:1, from bmerge.c:1: /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.3/include-fixed/math.h:1383:21: note: previous declaration of 'nearest' was here extern double nearest(double); ^ bmerge.c:109:21: error: 'class' redeclared as different kind of symbol static SEXP ic, xc, class; ^ In file included from /sas/outmva/opt/lib/R/include/R.h:31:0, from data.table.h:1, from bmerge.c:1: /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.8.3/include-fixed/math.h:1398:21: note: previous declaration of 'class' was here extern int class(); ^ /sas/outmva/opt/lib/R/etc/Makeconf:134: recipe for target 'bmerge.o' failed make: *** [bmerge.o] Error 1 I was able to fix this on AIX by by changing the name 'nearest' and 'class' in bmerge.c so that it doesn't conflict with what's declared in th header file. Again, this does not happen on GCC on other platforms. Is there a way to tell the compiler to pick up the symbols from bmerge.c before taking what's declared in the header? Thank you. -- Vinh
