[ET Trac] [Einstein Toolkit] #1661: ExternalLibraries/PAPI does not build with gcc 4.8.2

Einstein Toolkit trac-noreply at einsteintoolkit.org
Mon Sep 29 12:30:30 CDT 2014


#1661: ExternalLibraries/PAPI does not build with gcc 4.8.2
------------------------------------+---------------------------------------
  Reporter:  tbode                  |       Owner:  tbode              
      Type:  defect                 |      Status:  new                
  Priority:  major                  |   Milestone:  ET_2014_11         
 Component:  EinsteinToolkit thorn  |     Version:  development version
Resolution:                         |    Keywords:  PAPI               
------------------------------------+---------------------------------------

Comment (by rhaas):

 Well I did not want to step on anyone's toes. :-).

 I don't do (a) of course. I tend to iterate between compiling, fixing the
 compiler reported errors and compile again until the code compiles (ie the
 same procedure as when fixing code of my own). Then I do a diff between
 the original version and the fixed one. So it's more like (b) but with a
 manual fix rather than constructing a perl regex which I have to test and
 verify by doing a diff to see what it actually changed.

 I agree that for this change (removing -Werror) the perl script is shorter
 and not more complex than the patch. Pelr "wins" when the number of
 affected files is large and the replacement is simple. Perl **may** affect
 innocent files (eg changelogs) but no one should (have to) look at those
 files. It also means that there are potentially multiple locations to
 check for "patches" namely the configure script for the perl call and the
 dist directory for more complex changes.

 Just as long we don't try to do what
 http://svn.cactuscode.org/projects/ExternalLibraries/LORENE/trunk/dist/check_fopen_error.patch
 does in perl, I am happy.

 For many tools, but in particular with perl I would rather not want use
 shortness of the script as a measure for its simplicity :-). For example
 the perl scrip used
 {{{
 perl -pi -e 's/malloc.h/stdlib.h/'
 }}}
 contains a (most likely never triggered) bug since {{{.}}} is not properly
 escape inside of the regex. It should be
 {{{
 perl -pi -e 's/malloc\.h/stdlib\.h/'
 }}}
 or any amount of extra complication if there'd ever by something like
 "mymalloc.h" if one would want to be pedantic.

 So: the perl solution is fine with me, but I do reserver the right to
 complain again if the perl expressions become truly complex.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1661#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list