Todd, GCC worked for me, except for the Objective-C portion (the Apple Python Launcher). Apparently, Apple changes the Objective-C language whenever it suits them, and it suited them with the move to El Capitain. This is why we have neutral standards committees...
I think the Python launcher is pretty useless anyway, so it wouldn't bother me if it weren't compiled. There's a ./configure command to turn it off. I also submitted this as a bug to Python. Theoretically, one should be able to set env vars CC=gcc and OBJC=clang. But the Python build tries to build everything with GCC in that case. -- Elizabeth On Tue, Feb 9, 2016 at 12:02 PM, Todd Gamblin <[email protected]> wrote: > > From: <[email protected]> on behalf of Elizabeth Fischer < > [email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Tuesday, February 9, 2016 at 8:56 AM > To: "[email protected]" <[email protected]> > Subject: Re: [easybuild] More on EasyBuild and (DY)LD_LIBRARY_PATH > > > > On Tue, Feb 9, 2016 at 11:47 AM, Todd Gamblin <[email protected]> wrote: > >> FWIW, the Spack Python builds (for 3.5 and 2.7 at least) work on El >> Capitan, thanks to a number of recent contributions. They don't use any >> patches. >> > > With GCC? > > > With Clang (aka /usr/bin/gcc -- thanks apple). Haven't tried with gcc but > I could probably give it a go. > > -Todd > > > >> >> Spack bridges the everything-in-its-own-prefix gap by allowing you to >> activate/deactivate python packages on the fly. You install the module in >> its own prefix then `spack activate <module>`, and it is symlinked into >> place within the python prefix (with special handling for eggs, .pth files, >> etc.) >> >> Think of it as though each python installation is its own virtualenv. >> Modules are installed in their own prefix but can be symlinked into the >> python prefix on demand: >> http://software.llnl.gov/spack/basic_usage.html#extensions-python-support >> http://software.llnl.gov/spack/packaging_guide.html#extensions >> >> We use this to manage Python installs at LLNL. The same support can be >> implemented for other languages that have their own module systems via >> Spack extensions (e.g., we're thinking about lua). >> > > Thank you, that looks like it's well thought through. > > -- Elizabeth > >
