Re: Confused aboth math.in.h

[Gisle Vanem]

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?

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

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?

--gv