Re: Confused aboth math.in.h

[Pádraig Brady]

On 24/11/14 11:21, Gisle Vanem wrote:
> Pádraig Brady wrote:
> 
>>> I assume if some vendor have 'cosf' it should be undefined
>>> before Gnulib is trying to override or replace it. Not vice
>>> versa. So shouldn't this be:
>>>    # if @HAVE_COSF@ || @REPLACE_COSF@
>>>    #  undef cosf
>>
>> Well all the ...f() variants seem to be treated like this:
>> acosf() coshf() asinf() atanf() atan2f() ceilf() expf() ...
>>
>> In the m4, the corresponding check is with: AC_CHECK_FUNCS([cosf])
>> I.E. the linker is used to find the function in libm.
>> If it's only a macro and not in libm, then the code in math.h.in
>> above makes sense.
>>
>> So are you saying that HAVE_COSF is 1 for you (i.e. it's in your libm),
>> and you're also replacing it?
> 
> Thank for your reply. Sorry for the late reply.
> 
> I'm not sure if I'm replacing it or not. Since the .in.h-files seems
> so contorted, it's not easy to see what the rationale is behind
> those #ifdef. It seems to me Gnulib has an option to replace most
> CRT functions with an 'rpl_*' version. But none of these math-
> functions, right?

Well the ones being considered here are provisions for missing
functions rather than replacements of problematic ones.

> If so, I guess ./lib/test-cosf.c wont build unless cosf() is provided
> by Gnulib. Right?

The tests should work independent of replacement/provision.

> Another thing that puzzles me with Gnulib's math-functions for MSVC.
> MSVC v18 (VS Express 2013, Vista+) has more math functions than MSVC v16.
> For example "exp2()". So if a Gnulib imp-lib built with MSVC v18 is linked
> to a program an run on Win-XP, the program will not run; missing exp2()
> in Win-XP's MSVCRT.dll. And vice-versa; possibly multiple symbols during link.
> Does this mean a Gnulib DLL must be rebuilt for each Windows/MSVC version?

I've no experience of windows TBH, but gnulib is primarily designed as
a source inclusion mechanism for projects, rather than as a standalone
library for distribution.

thanks,
Pádraig.