I build a software package (Cactus) where several components require certain external libraries to be present. To simplify the build process, Cactus can build these external packages if they are not already provided by the system. Cactus then uses the same build environment and compiler flags for the external packages as for its application code.
If necessary, I could easily build hwloc manually, and point Cactus to it. However, I like the automation, and since I also like hwloc I thought I'd track down and correct the problem. -erik On Thu, Jan 17, 2013 at 3:06 PM, Jeff Hammond <jhamm...@alcf.anl.gov> wrote: > Okay, I'll see if I can verify this. However, I wonder why you need > to build with Cray compilers? hwloc has a C API, no? A C library > built with GCC should link against an application compiled with Cray. > I really don't see any value in using the Cray optimizing compiler for > a library that clearly isn't performance critical. > > Jeff > > On Thu, Jan 17, 2013 at 2:00 PM, Erik Schnetter <schnet...@cct.lsu.edu> > wrote: > > Given that the Cray compiler aborts on this code with an incorrect error > > message, I would actually call it a compiler bug. The compiler may > possibly > > want to complain that it doesn't know __builtin_ffsl, but its error > message > > (Declaration is incompatible with "int ffsl(long)") indicates that there > is > > some other problem. Note that hwloc never declares ffsl; it only calls > > __builtin_ffsl. > > > > However, I have a work-around, and leave it up to you to report this or > not. > > > > -erik > > > > > > On Thu, Jan 17, 2013 at 2:40 PM, Jeff Hammond <jhamm...@alcf.anl.gov> > wrote: > >> > >> Well then, this is most certainly not a Cray bug :-) The compiler is > >> doing exactly what you asked it to do. > >> > >> I would configure hwloc without this flag and assume that this > >> resolves the issue. > >> > >> Jeff > >> > >> On Thu, Jan 17, 2013 at 1:27 PM, Erik Schnetter <schnet...@cct.lsu.edu> > >> wrote: > >> > I realise I did not mention the flags I used when configuring hwloc. I > >> > am > >> > using > >> > > >> > -g -h gnu -O3 > >> > > >> > which explicitly asks to recognise GNU extensions. (I need to use -h > gnu > >> > to > >> > compile certain other code.) This would explain why __GNUC__ is > >> > defined... > >> > Apologies for omitting this earlier. > >> > > >> > -erik > >> > > >> > > >> > > >> > On Thu, Jan 17, 2013 at 2:21 PM, Jeff Hammond <jhamm...@alcf.anl.gov> > >> > wrote: > >> >> > >> >> I was not able to reproduce the behavior described by Erik on the > >> >> NERSC Cray XE6, which is to say, Cray C does not claim to be GCC > >> >> there. As I can't verify the problem, I can't report it. > >> >> > >> >> I have no experience with Cray bug fix latency but I suspect this > >> >> needs to be worked-around (I refuse to call it a fix since there is > no > >> >> problem in hwloc) because Cray won't backport whatever fix they > >> >> implement to all their compilers that users might come across. > >> >> > >> >> Jeff > >> >> > >> >> On Thu, Jan 17, 2013 at 1:15 PM, Erik Schnetter < > schnet...@cct.lsu.edu> > >> >> wrote: > >> >> > I have no idea how fast Cray acts in such a case. > >> >> > > >> >> > -erik > >> >> > > >> >> > > >> >> > On Thu, Jan 17, 2013 at 2:05 PM, Brice Goglin < > brice.gog...@inria.fr> > >> >> > wrote: > >> >> >> > >> >> >> Does Cray fix such bugs quickly usually? If so, no need to change > >> >> >> hwloc. > >> >> >> If not, I'll need somebody to test the change on other cray > >> >> >> platforms > >> >> >> and > >> >> >> compiler versions. > >> >> >> Brice > >> >> >> > >> >> >> > >> >> >> > >> >> >> Jeff Hammond <jhamm...@alcf.anl.gov> a écrit : > >> >> >>> > >> >> >>> This is a bug in the Cray compiler. They cannot and should not > set > >> >> >>> the __GNUC__ flag unless they are fully compatible with GCC. > There > >> >> >>> > >> >> >>> are many ways to define "fully compatible" but at a minimum, code > >> >> >>> that > >> >> >>> compiles with GCC needs to compile with any compiler that elects > to > >> >> >>> define __GNUC__. It is prudent to impose a higher standard in > some > >> >> >>> > >> >> >>> cases but that's not pertinent to this discussion. > >> >> >>> > >> >> >>> Lots of vendor compilers pretend to be __GNUC__ for any number of > >> >> >>> reasons. I believe that they are all wrong for doing it. > >> >> >>> > >> >> >>> Regarding this specific issue, there is nothing wrong with hwloc > >> >> >>> and I > >> >> >>> > >> >> >>> don't know why anyone should bother trying to fix Cray's problem, > >> >> >>> but > >> >> >>> I suspect that pragmatism will prevail, as it appears to have in > >> >> >>> the > >> >> >>> case of Boost > >> >> >>> > >> >> >>> > >> >> >>> ( > http://www.boost.org/doc/libs/1_52_0/boost/config/select_platform_config.hpp > ). > >> >> >>> > >> >> >>> > >> >> >>> I'll reproduce this locally and contact Cray directly about > fixing > >> >> >>> this on their end. > >> >> >>> > >> >> >>> Best, > >> >> >>> > >> >> >>> Jeff > >> >> >>> > >> >> >>> On Thu, Jan 17, 2013 at 12:19 PM, Erik Schnetter > >> >> >>> <schnet...@gmail.com> > >> >> >>> wrote: > >> >> >>> > >> >> >>>> hwloc-1.6.1rc2 fails to build with the Cray compiler > >> >> >>>> > >> >> >>>> Cray C : Version 8.1.2 Thu Jan 17, 2013 12:18:54 > >> >> >>>> > >> >> >>>> > >> >> >>>> The error message is > >> >> >>>> > >> >> >>>> CC bitmap.lo > >> >> >>>> CC-147 craycc: ERROR > >> >> >>>> Declaration is incompatible with "int ffsl(long)" (declared at > >> >> >>>> line > >> >> >>>> 526 > >> >> >>>> of > >> >> >>>> "/opt/cray/xe-sysroot/4.1.20/usr/include/string.h"). > >> >> >>>> > >> >> >>>> > >> >> >>>> (Yes, there is no line number with the error message.) > >> >> >>>> > >> >> >>>> This seems to be caused by the fact that the Cray c! > >> >> >>>> ompiler > >> >> >>>> sets __GNUC__, > >> >> >>>> > >> >> >>>> but is not quite compatible. A work-around is to change line 56 > of > >> >> >>>> include/private/misc.h from > >> >> >>>> > >> >> >>>> #elif defined(__GNUC__) > >> >> >>>> > >> >> >>>> to > >> >> >>>> > >> >> >>>> #elif defined(__GNUC__) && !defined(_CRAYC) > >> >> >>>> > >> >> >>>> > >> >> >>>> -erik > >> >> >>>> > >> >> >>>> -- > >> >> >>>> Erik Schnetter <schnet...@gmail.com> > >> >> >>>> http://www.perimeterinstitute.ca/personal/eschnetter/ > >> >> >>>> > >> >> >>>> > >> >> >>>> ________________________________ > >> >> >>>> > >> >> >>>> hwloc-users mailing list > >> >> >>>> hwloc-us...@open-mpi.org > >> >> >>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> > >> >> >> hwloc-users mailing list > >> >> >> hwloc-us...@open-mpi.org > >> >> >> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Erik Schnetter <schnet...@cct.lsu.edu> > >> >> > http://www.perimeterinstitute.ca/personal/eschnetter/ > >> >> > >> >> > >> >> > >> >> -- > >> >> Jeff Hammond > >> >> Argonne Leadership Computing Facility > >> >> University of Chicago Computation Institute > >> >> jhamm...@alcf.anl.gov / (630) 252-5381 > >> >> http://www.linkedin.com/in/jeffhammond > >> >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > >> > > >> > > >> > > >> > > >> > -- > >> > Erik Schnetter <schnet...@cct.lsu.edu> > >> > http://www.perimeterinstitute.ca/personal/eschnetter/ > >> > >> > >> > >> -- > >> Jeff Hammond > >> Argonne Leadership Computing Facility > >> University of Chicago Computation Institute > >> jhamm...@alcf.anl.gov / (630) 252-5381 > >> http://www.linkedin.com/in/jeffhammond > >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > > > > > > > > > -- > > Erik Schnetter <schnet...@cct.lsu.edu> > > http://www.perimeterinstitute.ca/personal/eschnetter/ > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhamm...@alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > -- Erik Schnetter <schnet...@cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/
