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
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
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.
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
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