Re: [DynInst_API:] dyninst 9.3.2 and gcc 4.4

[Matthew LeGendre <legendre1@xxxxxxxx>]

On Fri, 12 May 2017, Bill Williams wrote:
> First question: do these systems have a default version of clang or icc 
> that supports this feature? It should be fine to build Dyninst with 
> either of those assuming they're recent enough (and I've been working 
> with icc builds off and on locally).
mira is a BlueGene, so certainly no icc.  IBM isn't relasing upgraded FE 
compilers, so I'd be surprised if there were any new ones on mira--we 
certainly don't have any.
> Second, and more general, question: is there any rhyme or reason to 
> which HPC systems are stuck on a RHEL6 or equivalent baseline, and how 
> difficult is it to convince the sysadmins to make a reasonable compiler 
> available?
For the BlueGene/Q systems no one's upgrading past RHEL6.  That's IBM's 
supported distro.  I'd guess there's 1-2 years lifetime left on most 
BlueGene/Q installations.
For LLNL's linux clusters, I'd guess RHEL6 has another 1-1.5 years left. 
But it's much easier to have upgraded compilers on them, so we have plenty 
of alternative gcc/clang/icc installations.  Clusters tend to have a 
lifetime of approx 4-5 years, and major OS upgrades are hard, so we can 
linger on old OS versions for a while.
-Matt


> This is not a C++11-ism that I dragged in intentionally, but there are 
> plenty of post-4.4 C++11 features that we would like to be able to 
> exploit for readability and portability, so it's not just a question of 
> academic interest.
> ________________________________________
> From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of Mark W. Krentel <krentel@xxxxxxxx>
> Sent: Friday, May 12, 2017 2:02 PM
> To: dyninst-api@xxxxxxxxxxx
> Subject: [DynInst_API:] dyninst 9.3.2 and gcc 4.4
>
> I ran into this problem while trying to build Dyninst 9.3.2 on Blue
> Gene (mira, vesta) at Argonne.
>
> Dyninst 9.3.x won't build with GNU 4.4 because the typeCollection
> destructor in Collections.C uses the C++11 range iterator feature
> which is not supported in 4.4.
>
>     318 typeCollection::~typeCollection()
>     319 {
>     320     // delete all of the types
>     321     for(const auto& t: typesByName) {
>     322         t.second->decrRefCount();
>     323     }
>     324
>     325     for(const auto& t: typesByID) {
>     326         t.second->decrRefCount();
>     327     }
>     328 }
>
> This is easy enough to patch because so far, this is the only use of
> this feature.  But it brings up the difficult subject of supporting
> gcc/g++ 4.4 or not.
>
> This puts me in an awkward position.  I understand that 4.4 is ancient
> and it's long past time to move the line to 4.8.
>
> But there are a lot of systems that I care about that still run RH
> 6.x, including mira at Argonne, and that comes with gcc/g++ 4.4.7.
> (mira has 4.8, but only for the back end.)  It's awkward when the
> build directions start with, "ask your sysadmin to install a later
> compiler."
>
> Anyway, it's easy enough to work around, for now.
>
> --Mark
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api