This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Move new totalorder from libm to libc
- From: Andreas Schwab <schwab at linux-m68k dot org>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: "Gabriel F. T. Gomes" <gabriel at inconstante dot net dot br>, <libc-alpha at sourceware dot org>
- Date: Mon, 16 Dec 2019 19:32:08 +0100
- Subject: Re: Move new totalorder from libm to libc
- References: <87tv62daqi.fsf@mid.deneb.enyo.de> <20191216140714.558e1313@tereshkova> <87o8w8192v.fsf@mid.deneb.enyo.de>
On Dez 16 2019, Florian Weimer wrote:
> * Gabriel F. T. Gomes:
>
>> On Sat, 14 Dec 2019, Florian Weimer wrote:
>>
>>>Should we define the new totalorder in libc, so that it is harder to
>>>get the wrong version at run time due to underlinking?
>>
>> I didn't understand how underlinking could cause a wrong version to be
>> selected. Isn't totalorder only provided by libm? Where would a user
>> program get the old version from? I can only imagine it getting undefined
>> references during link time.
>
> If you build a shared object with -shared, you won't get an undefined
> symbol error (with typical toolchains):
What makes totalorder special in this regard?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."