Bug 113852 - mess with signbit function in octave source rpm
Summary: mess with signbit function in octave source rpm
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: octave   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lon Hohberger
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-19 15:32 UTC by Sysoltsev Slawa
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: 2.1.57-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 21:07:27 UTC
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 16:01 UTC, Lon Hohberger
no flags Details | Diff
Include math.h and define _GNU_SOURCE to get signbit definition (696 bytes, patch)
2004-06-24 18:24 UTC, Lon Hohberger
no flags Details | Diff

Description Sysoltsev Slawa 2004-01-19 15:32:44 UTC
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 16:01:42 UTC
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 16:02:12 UTC
Patch untested.

Comment 3 Lon Hohberger 2004-06-23 17:38:09 UTC
Patch fails test.

Comment 4 Lon Hohberger 2004-06-24 18:24:36 UTC
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 20:16:59 UTC
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.