{"action":"created","issue":{"url":"https://api.github.com/repos/LLNL/spack/issues/1687","repository_url":"https://api.github.com/repos/LLNL/spack","labels_url":"https://api.github.com/repos/LLNL/spack/issues/1687/labels{/name}","comments_url":"https://api.github.com/repos/LLNL/spack/issues/1687/comments","events_url":"https://api.github.com/repos/LLNL/spack/issues/1687/events","html_url":"https://github.com/LLNL/spack/issues/1687","id":174579902,"number":1687,"title":"Intel Masquarading as GCC","user":{"login":"citibeth","id":1924215,"avatar_url":"https://avatars.githubusercontent.com/u/1924215?v=3","gravatar_id":"","url":"https://api.github.com/users/citibeth","html_url":"https://github.com/citibeth","followers_url":"https://api.github.com/users/citibeth/followers","following_url":"https://api.github.com/users/citibeth/following{/other_user}","gists_url":"https://api.github.com/users/citibeth/gists{/gist_id}","starred_url":"https://api.github.com/users/citibeth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/citibeth/subscriptions","organizations_url":"https://api.github.com/users/citibeth/orgs","repos_url":"https://api.github.com/users/citibeth/repos","events_url":"https://api.github.com/users/citibeth/events{/privacy}","received_events_url":"https://api.github.com/users/citibeth/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2016-09-01T17:24:06Z","updated_at":"2016-09-14T22:11:19Z","closed_at":null,"body":"I remember some issues of Intel compilers pretending to be GCC, and trying to be compatible with certain versions of GCC.  Is there anything on this topic people think should go in the Spack manual?\r\n\r\n@tgamblin  wrote:\r\n\r\n> This is an area of the dependency model that’s not covered well currently.\r\n>  \r\n> Compilers are getting more complicated, and the way the Intel compiler in particular handles ABI compatibility is complicated.  icpc relies on gcc’s libstdc++, standard c headers, etc. So it requires gcc as a build and link dependency.  For normal users, it does this in a relatively simple way; it finds the gcc in your PATH and assumes that’s the right one.  This works for most people with one install of icc on a standard linux distro.  For people in combinatorial hell, not so much. You can supply –gcc-name=<path to gcc> to tell it which gcc to use. This has become more of an issue recently because people need newer versions of gcc (often newer than what is on the system) to support C++11/14/17 features in icpc.  Matching the versions can get pretty nasty.\r\n>  \r\n> Basically this means gcc is a dependency of icc, so you have:\r\n>  \r\n> 1.       A build (compiler) dependency on the intel compiler b/c you wanted to use it\r\n> \r\n> 2.       A build dependency from icc -> gcc for compatibility\r\n> \r\n> 3.       A link dependency on the particular gcc’s runtime libraries (glibc, libstdc++)\r\n> \r\n>  \r\n> The solution we would like to implement is to make compilers into fancier build dependencies, and to allow compiler to *impose* additional link dependencies on things that use them as build dependencies.  That would maintain the ability to have different compilers for different parts of your DAG, but it would also enforce ABI compatibility through the link dependencies, which would need to be normalized (shared) across the DAG. So basically we’d have a way to use Spack’s “one version of everything in the DAG” rule on compiler runtime libraries, but to allow it to understand that runtime libraries might be shareable in certain ways across compilers.  i.e., you could reliably build a multi-compiler executable, and maybe pick the fastest compiler for different nodes in the DAG.  This is something that is currently rather painful to do (so no one does it).\r\n>  \r\n> The other nice thing this would do would be to allow you to use the virtual dependency system with compilers, so we can make compilers providers of particular languages at particular versions (c@99, c@03, cxx@11, cxx@14, fortran@77, etc.) and packages then only have to depend on the language they need.  We could get rid of the sort-of-weird 4-tuple compiler system Spack currently uses.  This would also let you mix C and Fortran compilers more easily.\r\n>  \r\n> So, short story: this is something not currently in Spack’s dependency model, but we’re working on it.  I would hold off on putting this in the docs.  Unless you think the explanation above is something that should go in the docs.\r\n>  \r\n> -Todd\r\n> "},"comment":{"url":"https://api.github.com/repos/LLNL/spack/issues/comments/247172426","html_url":"https://github.com/LLNL/spack/issues/1687#issuecomment-247172426","issue_url":"https://api.github.com/repos/LLNL/spack/issues/1687","id":247172426,"user":{"login":"lee218llnl","id":3641995,"avatar_url":"https://avatars.githubusercontent.com/u/3641995?v=3","gravatar_id":"","url":"https://api.github.com/users/lee218llnl","html_url":"https://github.com/lee218llnl","followers_url":"https://api.github.com/users/lee218llnl/followers","following_url":"https://api.github.com/users/lee218llnl/following{/other_user}","gists_url":"https://api.github.com/users/lee218llnl/gists{/gist_id}","starred_url":"https://api.github.com/users/lee218llnl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lee218llnl/subscriptions","organizations_url":"https://api.github.com/users/lee218llnl/orgs","repos_url":"https://api.github.com/users/lee218llnl/repos","events_url":"https://api.github.com/users/lee218llnl/events{/privacy}","received_events_url":"https://api.github.com/users/lee218llnl/received_events","type":"User","site_admin":false},"created_at":"2016-09-14T22:11:19Z","updated_at":"2016-09-14T22:11:19Z","body":"@citibeth This writeup is very nice! I was able to test this out and get it to work. As you indicated, the details of the compilers.yaml structure for the \"Command Line Configuration\" will need to be updated after #1532 is merged (the [c,cxx,f]flags will need to be moved into the flags sub category. It may also be worth noting that rpaths are not being set for the gcc location, so users will have to add this to their ldflags in compilers.yaml or load the appropriate gcc module when running to actually pick up the specified gcc's libraries at run time."}}
{"actor":{"display_login":"lee218llnl"}}