So a known problem that has been hanging around for a long time breaking our tests but never fixed.
On Dec 21, 2013, at 10:15 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: > >> Hmm, based on my limited checking the drand48 prototypes may be >> turned off with -std=c89 which of course means that configure >> should detect no drand48 in that case and turn off drand48, but >> since configure still does the silly “check for symbol in library” >> it still finds drand48() in the library and hence turns it on. > > That's not what it does. It actually includes stdlib.h and attempts to > compile as usual. A fix for the test is in 'jed/missing-prototype’ Hmm, then maybe it should be removed rom the list functions = ['access', '_access', 'clock', 'drand48', 'getcwd', '_getcwd', 'getdomainname', 'gethostname’, it is confusing to have it tested in two places, I saw this one and just assumed it is the only place. Barry request-assigned: petsc-dev missing drand48() prototype with -std=c89 > > https://bitbucket.org/petsc/petsc/commits/6c614e632301d4991c6282096bd30e29054123f5 > > but this creates a dialect problem that I don't know how to fix: > > http://lists.mcs.anl.gov/pipermail/petsc-dev/2013-April/011931.html > http://lists.mcs.anl.gov/pipermail/petsc-dev/2013-May/012114.html > >> Perhaps a custom drand48() test in configure that checks a few values and >> makes sure they are not all zero? > > That implies actually running code (possibly submitted through the batch > system), and would thus be a --known-drand48 flag. We can solve this in > a simpler way.
