On 29 September 2015 at 14:51, Vinh Nguyen <vinhdizzo@xxxxxxxxx> wrote: > 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. Another option would be to build GCC with _XOPEN_SOURCE=700 defined, or rebuild Python with the same _XOPEN_SOURCE value as GCC was built with (which was probably not set at all when building GCC) so that they agree. Possibly you just need to rebuild Python with that installation of GCC, so that it uses the "include-fixed" headers from GCC. > 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? nearest() and class() are non-standard functions defined on AIX. That's nothing to do with GCC, if a package wants to be compilable on AIX then it shouldn't declare global names that conflict with global names in system headers. > Thank you. > > -- Vinh
