Install script issue
Hello yt developers, I don't know if this is a "bug," exactly, but I noticed an issue when doing a clean install of yt today involving the h5py install. Namely, it looks like if you have an non-empty CFLAGS environment variable (which can happen without your knowledge if you load certain module files in a supercomputing environment, for example), the h5py build will proceed without getting the "-fno-strict-aliasing" flag and the resulting module will not work. You can get around this either by 1) clobbering CFLAGS, or 2) adding "-fno-strict-aliasing" to it and re-running the script. It seems like the install script should either detect this and work around it, or else warn you that the h5py build has gone of the rails after the installation, because the tracebacks you get from trying to use the whacked-out h5py module are not very illuminating. I would do this myself, but I'm not sure my shell scripting skills are up to the task. Thanks, Andrew
Hi Andrew, Sorry for the delay in replying, and thanks for reporting this. Do you think it would be sufficient to just detect if CFLAGS is not empty and report that to the user, noting that it could cause issues? Also, if you don't mind my asking, which supercomputer was this? We can put a note in the script about the modules. -Matt On Fri, Mar 30, 2012 at 9:45 PM, Andrew Myers <atmyers@berkeley.edu> wrote:
Hello yt developers,
I don't know if this is a "bug," exactly, but I noticed an issue when doing a clean install of yt today involving the h5py install. Namely, it looks like if you have an non-empty CFLAGS environment variable (which can happen without your knowledge if you load certain module files in a supercomputing environment, for example), the h5py build will proceed without getting the "-fno-strict-aliasing" flag and the resulting module will not work. You can get around this either by 1) clobbering CFLAGS, or 2) adding "-fno-strict-aliasing" to it and re-running the script.
It seems like the install script should either detect this and work around it, or else warn you that the h5py build has gone of the rails after the installation, because the tracebacks you get from trying to use the whacked-out h5py module are not very illuminating. I would do this myself, but I'm not sure my shell scripting skills are up to the task.
Thanks, Andrew
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, Yeah, I think that would be great. This was actually on the Berkeley Astro department cluster Henyey, so I'm not sure how immediately relevant a specific warning would be to people at other institutions, but a note that having something in CFLAGS can potentially mess up your h5py module could save people some time down the road. -Andrew M On Tue, Apr 3, 2012 at 6:34 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Andrew,
Sorry for the delay in replying, and thanks for reporting this. Do you think it would be sufficient to just detect if CFLAGS is not empty and report that to the user, noting that it could cause issues?
Also, if you don't mind my asking, which supercomputer was this? We can put a note in the script about the modules.
-Matt
Hello yt developers,
I don't know if this is a "bug," exactly, but I noticed an issue when doing a clean install of yt today involving the h5py install. Namely, it looks like if you have an non-empty CFLAGS environment variable (which can happen without your knowledge if you load certain module files in a supercomputing environment, for example), the h5py build will proceed without getting
On Fri, Mar 30, 2012 at 9:45 PM, Andrew Myers <atmyers@berkeley.edu> wrote: the
"-fno-strict-aliasing" flag and the resulting module will not work. You can get around this either by 1) clobbering CFLAGS, or 2) adding "-fno-strict-aliasing" to it and re-running the script.
It seems like the install script should either detect this and work around it, or else warn you that the h5py build has gone of the rails after the installation, because the tracebacks you get from trying to use the whacked-out h5py module are not very illuminating. I would do this myself, but I'm not sure my shell scripting skills are up to the task.
Thanks, Andrew
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Cool. I committed this in 2af699ff04a4. On Tue, Apr 3, 2012 at 11:49 AM, Andrew Myers <atmyers@berkeley.edu> wrote:
Hi Matt,
Yeah, I think that would be great. This was actually on the Berkeley Astro department cluster Henyey, so I'm not sure how immediately relevant a specific warning would be to people at other institutions, but a note that having something in CFLAGS can potentially mess up your h5py module could save people some time down the road.
-Andrew M
On Tue, Apr 3, 2012 at 6:34 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Andrew,
Sorry for the delay in replying, and thanks for reporting this. Do you think it would be sufficient to just detect if CFLAGS is not empty and report that to the user, noting that it could cause issues?
Also, if you don't mind my asking, which supercomputer was this? We can put a note in the script about the modules.
-Matt
On Fri, Mar 30, 2012 at 9:45 PM, Andrew Myers <atmyers@berkeley.edu> wrote:
Hello yt developers,
I don't know if this is a "bug," exactly, but I noticed an issue when doing a clean install of yt today involving the h5py install. Namely, it looks like if you have an non-empty CFLAGS environment variable (which can happen without your knowledge if you load certain module files in a supercomputing environment, for example), the h5py build will proceed without getting the "-fno-strict-aliasing" flag and the resulting module will not work. You can get around this either by 1) clobbering CFLAGS, or 2) adding "-fno-strict-aliasing" to it and re-running the script.
It seems like the install script should either detect this and work around it, or else warn you that the h5py build has gone of the rails after the installation, because the tracebacks you get from trying to use the whacked-out h5py module are not very illuminating. I would do this myself, but I'm not sure my shell scripting skills are up to the task.
Thanks, Andrew
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Thanks! That looks great. On Tue, Apr 3, 2012 at 10:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Cool. I committed this in 2af699ff04a4.
Hi Matt,
Yeah, I think that would be great. This was actually on the Berkeley Astro department cluster Henyey, so I'm not sure how immediately relevant a specific warning would be to people at other institutions, but a note
having something in CFLAGS can potentially mess up your h5py module could save people some time down the road.
-Andrew M
On Tue, Apr 3, 2012 at 6:34 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Andrew,
Sorry for the delay in replying, and thanks for reporting this. Do you think it would be sufficient to just detect if CFLAGS is not empty and report that to the user, noting that it could cause issues?
Also, if you don't mind my asking, which supercomputer was this? We can put a note in the script about the modules.
-Matt
On Fri, Mar 30, 2012 at 9:45 PM, Andrew Myers <atmyers@berkeley.edu> wrote:
Hello yt developers,
I don't know if this is a "bug," exactly, but I noticed an issue when doing a clean install of yt today involving the h5py install. Namely, it
looks
like if you have an non-empty CFLAGS environment variable (which can happen without your knowledge if you load certain module files in a supercomputing environment, for example), the h5py build will proceed without getting the "-fno-strict-aliasing" flag and the resulting module will not work. You can get around this either by 1) clobbering CFLAGS, or 2) adding "-fno-strict-aliasing" to it and re-running the script.
It seems like the install script should either detect this and work around it, or else warn you that the h5py build has gone of the rails after
On Tue, Apr 3, 2012 at 11:49 AM, Andrew Myers <atmyers@berkeley.edu> wrote: that the
installation, because the tracebacks you get from trying to use the whacked-out h5py module are not very illuminating. I would do this myself, but I'm not sure my shell scripting skills are up to the task.
Thanks, Andrew
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Andrew Myers -
Matthew Turk