On Sun, Mar 11, 2012 at 11:50 PM, Michael Goffioul
wrote:
> On Sun, Mar 11, 2012 at 10:52 PM, Bruno Haible wrote:
>> Michael Goffioul wrote:
>>> frexpf is actually defined as a macro in C,
>>> and as an inline function in C++.
>>
>> Normally gnulib avoids collisions with system functions by check
On Sun, Mar 11, 2012 at 10:52 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> frexpf is actually defined as a macro in C,
>> and as an inline function in C++.
>
> Normally gnulib avoids collisions with system functions by checking whether
> a system function exists, via AC_CHECK_FUNCS. But AC
Michael Goffioul wrote:
> frexpf is actually defined as a macro in C,
> and as an inline function in C++.
Normally gnulib avoids collisions with system functions by checking whether
a system function exists, via AC_CHECK_FUNCS. But AC_CHECK_FUNCS looks
only in the libraries and misses the inline f
On Sun, Mar 11, 2012 at 6:58 PM, Michael Goffioul
wrote:
> To confirm my suspicion, I tested the following sample:
>
> #include "config.h"
> #include
> #include
>
> int main (int argc, char** argv)
> {
> volatile float x;
> float zero = 0.0f;
>
> x = 1.0f / zero;
> {
On Sun, Mar 11, 2012 at 6:30 PM, Michael Goffioul
wrote:
> Hi,
>
> I'm trying to clarify a potential issue when using gnulib float math
> functions like frexpf (and possibly others) with MSVC9. It all started
> when compiling octave and getting link error because of duplicate
> symbols like frexpf
Hi,
I'm trying to clarify a potential issue when using gnulib float math
functions like frexpf (and possibly others) with MSVC9. It all started
when compiling octave and getting link error because of duplicate
symbols like frexpf in libgnulib.la and octave code like Cell.cc. I
don't fully unsersta
