[petsc-dev] http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2013/12/2 0/examples_master_arch-linux-c89_thrash.log

[Barry Smith]

  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 <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> 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.