[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confused aboth math.in.h

From: Gisle Vanem
Subject: Re: Confused aboth math.in.h
Date: Mon, 24 Nov 2014 11:21:51 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30

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:
   #  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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]