Bug #1627

preserving OPTS_CXX breaks application builds on different machines

Added by Jim Phillips about 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Spent time:


After;a=commit;h=cf9d5d1f4ca0f4d3c27727f8ab30e665e24b9154 compiler arguments passed to the build script via the OPTS_CXX environment variable are now being captured and applied to later invocations of charmc. This breaks builds where charm is built on a machine requiring one set of flags and the application is built on another machine requiring a different set of flags.

I'm only passing the OPTS_CXX environment variable because in it is Phil's suggested workaround for a failing C++ support test.

It seems strange to preserve an environment variable, since this is something that should be set by the user's environment scripts rather than charmc.


#1 Updated by Phil Miller about 2 years ago

Why are the runtime system and application being built on two different machines, with such distinct environments? Could you please elaborate with the full details of how this arises in practice?

In this case, we really can't get away from capturing the compiler flags used during configuration, because other outputs of the configuration process are coupled to them - if they were to change, the configuration would no longer be valid. In the worst case, we could end up with code that's silently compiled in a way that will crash obscurely at runtime.

#2 Updated by Eric Bohm about 2 years ago

  • Assignee set to Phil Miller

#3 Updated by Sam White about 2 years ago

  • Status changed from New to Feedback

#4 Updated by Jim Phillips about 2 years ago

My automated builds use the same (old, picky) environment for Charm++ and NAMD. The problem arises when people try to do build on their newer desktops using the same Charm++ library. The work-around is to build two copies of Charm++ on different machines until we ditch the old build OS.

#5 Updated by Phil Miller about 2 years ago

I don't think there's anywhere that we 'support' building applications in one environment against a build of Charm++ compiled in a different environment. We already make no ABI compatibility guarantees anyway - this is just asking for trouble.

My inclination would be toward closing this as 'Rejected'. Is that OK with you?

#6 Updated by Jim Phillips about 2 years ago

Actually, I think I can do what I need using the __INTEL_PRE_CFLAGS environment variable.

#7 Updated by Jim Phillips about 2 years ago

By setting __INTEL_PRE_CFLAGS rather than OPTS_CXX I am able to accomplish what I want.

#8 Updated by Phil Miller almost 2 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF