Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 113852 - mess with signbit function in octave source rpm
mess with signbit function in octave source rpm
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: octave (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Depends On:
  Show dependency treegraph
Reported: 2004-01-19 10:32 EST by Sysoltsev Slawa
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: 2.1.57-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 17:07:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Include math.h in lo_ieee.h (513 bytes, patch)
2004-06-23 12:01 EDT, Lon Hohberger
no flags Details | Diff
Include math.h and define _GNU_SOURCE to get signbit definition (696 bytes, patch)
2004-06-24 14:24 EDT, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Sysoltsev Slawa 2004-01-19 10:32:44 EST
Description of problem:
There is some mess in octave package with signbit functon. At first, 
EL3.0 have signbit function defined in math.h for __USE_ISOC99 
compilation (by default any C++, but not C), but configure isn’t able to 
detect that:

checking for copysign... yes
checking for signbit... no
checking for acosh... yes

The problem is that configure looks for signbit function body, but on 
linux signbit is a macro, that uses internal __signbit function. So 
configure assumes there is no signbit function and so lo_ieee_signbit 
macro in lo-ieee.h becomes hardcoded 0, that is not pretty good.

Now let’s imagine configure would detect signbit properly. Another 
problem with it that gcc’s header <cmath> moves definition of signbit to 
the std namespace, after including <cmath>, ::signbit is undefined 
symbol, but std::signbit is a template function. Therefore in C++ 
sources that use <cmath> you must use std::signbit, not signbit. There 
is such error in Cmatrix.cc, dMatrix.cc, pr-output.cc. Probably macro 
lo_ieee_signbit should be changed to use std::signbit on systems with 
gcc3.2 default compiler.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Build octave in usual way on Enterprise Linux 3.0 by gcc3.2
Actual results:
signbit isn't detected during configure and lo_ieee_signbit is hardcoded 
as 0.
When you'll fix the bug with signbit detection, you get the compile-time 
error about undefined identifier "signbit"

Expected results:
octave with really working lo_ieee_signbit

Additional info:
Comment 1 Lon Hohberger 2004-06-23 12:01:42 EDT
Created attachment 101360 [details]
Include math.h in lo_ieee.h

This should fix the problem with respect to signbit being defined as 0.  By
including math.h, signbit will be defined and lo_ieee_signbit() will thus be
defined to signbit().
Comment 2 Lon Hohberger 2004-06-23 12:02:12 EDT
Patch untested.
Comment 3 Lon Hohberger 2004-06-23 13:38:09 EDT
Patch fails test.
Comment 4 Lon Hohberger 2004-06-24 14:24:36 EDT
Created attachment 101380 [details]
Include math.h and define _GNU_SOURCE to get signbit definition

This patch causes inclusion of math.h in lo-ieee.h if signbit and
HAVE_SIGNBIT/HAVE_COPYSIGN aren't defined, with _GNU_SOURCE defined so that
signbit gets defined on platforms which support the _GNU_SOURCE macro.

If signbit is not defined, the build stops. (This isn't necessary, nor
desirable, for upstream use, but can be useful to detect this problem in the
Comment 5 Lon Hohberger 2004-06-24 16:16:59 EDT
Typo.  s/GUN/GNU/g in the patch.

Note You need to log in before you can comment on or make changes to this bug.