Date: Mon, 18 May 1998 16:03:01 +1000 From: Stephen McKay <syssgm@dtir.qld.gov.au> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: Undefined symbol "___error" Message-ID: <199805180603.QAA16388@troll.dtir.qld.gov.au> In-Reply-To: <199805150251.TAA18202@usr01.primenet.com> from Terry Lambert at "15 May 1998 13:20:19 %2B1000" References: <199805150251.TAA18202@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 15th May 1998, Terry Lambert wrote:
>If *PART* of the system *WASN'T* rebuilt, I now see the problem. The
>user is too lazy to be running -current. ;-).
To be specific, I have an executable linked against libc.so.2.2 and
libtermcap.so.2.1. The current libc is libc.so.3.1 while libtermcap.so.2.1
is still the most recent. The newly compiled libtermcap.so.2.1 references
__error which is not supplied by libc.so.2.2. Splat!
This is not me being lazy. This is a fault in -current. If we were not
interested in supporting binaries from previous releases (a binary not
yet 1 year old, I might add), then why do we version number our libraries
at all?
Discussion should move from "Loser! You ain't got the BALLS to run -current!"
to "Which possible solution is best at this time?"
>#ifdef __GCC__
>#pragma weak __error = ___error
>static ___inline int *___error( void) { extern int errno; return &errno; }
>#endif /* __GCC__*/
>
>#define errno (* __error)
>
>This would give each library a weak accessor that would be overridden
>by the real accessor if the thing got linked to the right libc, right?
I tried a number of variants of this approach and could not make any of
them work. In all cases (well, all that compiled at all), the local
hack ___error() was used in preference to the system supplied __error().
Otherwise, this would be a good hack, costing only 12 bytes per .o file.
Out of the possible solutions discussed, I very much prefer to delay
this (inevitable) errno change until we change to ELF. Next best would
be a hack in ld.so to recognise __error specially and resolve it (if
necessary) from a new lib__error.so. In my view, the least pleasant
option is to bump all major library numbers. This would have to include
everything in ports as well as all the system libraries. I think this
would be too error prone to be practical, and shows a weakness in the
shared library versioning mechanism.
Oh, and doing nothing is not what I call an option.
Stephen.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805180603.QAA16388>