Date: Tue, 08 Jun 2004 13:40:20 -0700 From: Sean McNeil <sean@mcneil.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached Message-ID: <1086727220.83494.10.camel@server.mcneil.com> In-Reply-To: <1086724856.83077.13.camel@server.mcneil.com> References: <Pine.GSO.4.10.10406081505050.3616-100000@pcnet5.pcnet.com> <1086724856.83077.13.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-06-08 at 13:00, Sean McNeil wrote: > On Tue, 2004-06-08 at 12:15, Daniel Eischen wrote: > > On Tue, 8 Jun 2004, Sean McNeil wrote: > > > I fail to see why this is opposed by the FreeBSD community, the reasons > > > behind the opposition, or why this entire thread has started trying to > > > work around the mistake of making them weak symbols instead of just > > > fixing the underlying problem by making them strong references. > > > > Because there is no problem if you link correctly. And I > > would like to be able to override libc functions with my > > own. I wish malloc was weak. I wish all our exported > > symbols were weak. By the way, you are imposing a requirement of linking pthread in a particular order to that you can override the symbols in libc (just like pthread wants to) and yet do not wish to impose a linking order on this ficticious other need you have? Why not make pthread libc overrides strong? You have made them so for things like _pthread_join, so why not for select and all those? I have an alternative proposal for you: make the libc symbols like the pthread ones.... Taking select as an example, Make libc and pthread both have weak references to __select for select. Make libc have a weak reference to __libc_select for __select. Implement __libc_select in libc and __select in pthread. Sean
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086727220.83494.10.camel>