diff mbox

fix gamma symbol for static linking and new targets

Message ID 59D24A01.6060605@arm.com
State Committed
Commit bdc5c59214a9e4bd9a299deead29c04ddf141256
Headers

Commit Message

Szabolcs Nagy Oct. 2, 2017, 2:15 p.m. UTC 
  On 29/09/17 18:56, Joseph Myers wrote:
> On Fri, 29 Sep 2017, Szabolcs Nagy wrote:
>> (at least i don't have those symbols after i rebase
>> the arm/ilp32 patches now, they used to come from
>> math/w_lgamma*_compat2.os)
>>
>> i don't think it's safe to remove them for new targets
>> since they are still in the public math.h
> 
> I think that means new targets and static linking should get them from 
> w_lgamma_template.c.  That is, there should be w_lgamma.c, w_lgammaf.c and 
> w_lgammal.c that include the template in the usual way then (for 
> !LIBM_SVID_COMPAT) create the additional aliases (since we don't want the 
> old versions of wrappers used on new targets - and as gamma is a Unix98 
> interface, it should stay around, but as it's obsolescent, we don't want 
> it for any _FloatN / _FloatNx types).
> 

is this ok?:

The lgamma compat code is no longer built for !LIBM_SVID_COMPAT targets,
but the legacy gamma, gammaf and gammal symbols should be still defined,
so make them aliases to the non-compat lgamma code.

2017-10-02  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	* math/w_lgamma.c: New file.
	* math/w_lgammaf.c: New file.
	* math/w_lgammal.c: New file.

Comments

Joseph Myers Oct. 2, 2017, 2:42 p.m. UTC | #1 
On Mon, 2 Oct 2017, Szabolcs Nagy wrote:

> is this ok?:
> 
> The lgamma compat code is no longer built for !LIBM_SVID_COMPAT targets,
> but the legacy gamma, gammaf and gammal symbols should be still defined,
> so make them aliases to the non-compat lgamma code.
> 
> 2017-10-02  Szabolcs Nagy  <szabolcs.nagy@arm.com>
> 
> 	* math/w_lgamma.c: New file.
> 	* math/w_lgammaf.c: New file.
> 	* math/w_lgammal.c: New file.

OK.
Szabolcs Nagy Oct. 2, 2017, 2:46 p.m. UTC | #2 
On 02/10/17 15:42, Joseph Myers wrote:
> On Mon, 2 Oct 2017, Szabolcs Nagy wrote:
> 
>> is this ok?:
>>
>> The lgamma compat code is no longer built for !LIBM_SVID_COMPAT targets,
>> but the legacy gamma, gammaf and gammal symbols should be still defined,
>> so make them aliases to the non-compat lgamma code.
>>
>> 2017-10-02  Szabolcs Nagy  <szabolcs.nagy@arm.com>
>>
>> 	* math/w_lgamma.c: New file.
>> 	* math/w_lgammaf.c: New file.
>> 	* math/w_lgammal.c: New file.
> 
> OK.
> 

it seems drem and pow10 symbols are also affected.
i will prepare a patch for those too.
Joseph Myers Oct. 2, 2017, 2:51 p.m. UTC | #3 
On Mon, 2 Oct 2017, Szabolcs Nagy wrote:

> it seems drem and pow10 symbols are also affected.

pow10 is deliberately obsoleted and should not be present for new ports or 
static linking and should be a compat symbol for existing ports.

We might reasonably consider doing the same for drem (it's an __USE_MISC 
symbol, not from any supported standard, and an exact alias of remainder).
Szabolcs Nagy Oct. 2, 2017, 3:03 p.m. UTC | #4 
On 02/10/17 15:51, Joseph Myers wrote:
> On Mon, 2 Oct 2017, Szabolcs Nagy wrote:
> 
>> it seems drem and pow10 symbols are also affected.
> 
> pow10 is deliberately obsoleted and should not be present for new ports or 
> static linking and should be a compat symbol for existing ports.
> 
> We might reasonably consider doing the same for drem (it's an __USE_MISC 
> symbol, not from any supported standard, and an exact alias of remainder).
> 

i think drem is more widely used in existing code than pow10.

so i'd prefer to keep drem on new targets
Joseph Myers Oct. 2, 2017, 3:10 p.m. UTC | #5 
On Mon, 2 Oct 2017, Szabolcs Nagy wrote:

> i think drem is more widely used in existing code than pow10.
> 
> so i'd prefer to keep drem on new targets

That's also reasonable, though I think it would be a good idea to revisit 
such pre-C99 APIs with different names in C99 in general, and consider 
obsoleting the pre-C99 names (more generally, __USE_MISC APIs may well be 
appropriate for obsoletion where there is a clear standard replacement 
even if not an exact alias).  (There are other cases of such pre-C99 names 
in glibc, e.g. strtoq.)
Florian Weimer Oct. 2, 2017, 3:25 p.m. UTC | #6 
On 10/02/2017 05:03 PM, Szabolcs Nagy wrote:
> On 02/10/17 15:51, Joseph Myers wrote:
>> On Mon, 2 Oct 2017, Szabolcs Nagy wrote:
>>
>>> it seems drem and pow10 symbols are also affected.
>>
>> pow10 is deliberately obsoleted and should not be present for new ports or
>> static linking and should be a compat symbol for existing ports.
>>
>> We might reasonably consider doing the same for drem (it's an __USE_MISC
>> symbol, not from any supported standard, and an exact alias of remainder).
>>
> 
> i think drem is more widely used in existing code than pow10.

The Fedora 26 (built against glibc 2.25) is this:

For pow10, we have gforth.

For drem, we have clisp, compat-libf2c, ifm, and the popular, schemaless 
database with the offensive name.  The latter comes from the S2 library 
for spherical geometry, I think, which is bundled and unmaintained 
upstream (at least the public repository is).

I still think we could give drem the pow10 treatment, too.

Thanks,
Florian
Szabolcs Nagy Oct. 2, 2017, 5:07 p.m. UTC | #7 
On 02/10/17 16:25, Florian Weimer wrote:
> On 10/02/2017 05:03 PM, Szabolcs Nagy wrote:
>> On 02/10/17 15:51, Joseph Myers wrote:
>>> On Mon, 2 Oct 2017, Szabolcs Nagy wrote:
>>>
>>>> it seems drem and pow10 symbols are also affected.
>>>
>>> pow10 is deliberately obsoleted and should not be present for new ports or
>>> static linking and should be a compat symbol for existing ports.
>>>
>>> We might reasonably consider doing the same for drem (it's an __USE_MISC
>>> symbol, not from any supported standard, and an exact alias of remainder).
>>>
>>
>> i think drem is more widely used in existing code than pow10.
> 
> The Fedora 26 (built against glibc 2.25) is this:
> 
> For pow10, we have gforth.
> 
> For drem, we have clisp, compat-libf2c, ifm, and the popular, schemaless database with the offensive name.  The
> latter comes from the S2 library for spherical geometry, I think, which is bundled and unmaintained upstream
> (at least the public repository is).
> 
> I still think we could give drem the pow10 treatment, too.
> 

removing symbols can potentially break existing code. i think if
it's just an alias then there is no big harm keeping it around.

unlike pow10, drem is historically present in all bsd libcs under
_BSD_SOURCE, that's why i'd expect it to be more widely used.

i'd mostly expect it in historical software (like libf2c) or hacks
that try to wrap all libm functions in glibc, either way it's not
code that anybody want to spend time fixing when doing a new port.

note that gcc has __builtin_drem that expands to drem (not remainder)
if nobody is bothered by that then keeping a weak alias drem should
be fine too.
diff mbox

Patch

diff --git a/math/w_lgamma.c b/math/w_lgamma.c
new file mode 100644
index 0000000000..04b9b197f2
--- /dev/null
+++ b/math/w_lgamma.c
@@ -0,0 +1,10 @@ 
+#include <math-type-macros-double.h>
+#include <w_lgamma_template.c>
+#if __USE_WRAPPER_TEMPLATE
+strong_alias (__lgamma, __gamma)
+weak_alias (__gamma, gamma)
+# ifdef NO_LONG_DOUBLE
+strong_alias (__gamma, __gammal)
+weak_alias (__gammal, gammal)
+# endif
+#endif
diff --git a/math/w_lgammaf.c b/math/w_lgammaf.c
new file mode 100644
index 0000000000..371fa26234
--- /dev/null
+++ b/math/w_lgammaf.c
@@ -0,0 +1,6 @@ 
+#include <math-type-macros-float.h>
+#include <w_lgamma_template.c>
+#if __USE_WRAPPER_TEMPLATE
+strong_alias (__lgammaf, __gammaf)
+weak_alias (__gammaf, gammaf)
+#endif
diff --git a/math/w_lgammal.c b/math/w_lgammal.c
new file mode 100644
index 0000000000..cf6cc9c1ca
--- /dev/null
+++ b/math/w_lgammal.c
@@ -0,0 +1,6 @@ 
+#include <math-type-macros-ldouble.h>
+#include <w_lgamma_template.c>
+#if __USE_WRAPPER_TEMPLATE
+strong_alias (__lgammal, __gammal)
+weak_alias (__gammal, gammal)
+#endif