Date: Wed, 20 May 1998 23:27:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: syssgm@dtir.qld.gov.au (Stephen McKay) Cc: tlambert@primenet.com, freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: Fix for undefined "__error" and discussion of shared object versioning Message-ID: <199805202327.QAA02369@usr04.primenet.com> In-Reply-To: <199805200747.RAA09525@troll.dtir.qld.gov.au> from "Stephen McKay" at May 20, 98 05:47:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >The difference in the output is because PHK's malloc always fails a
> >``readlink("/etc/malloc.conf");'' and sets errno = ENOENT (2).
>
> This explains the errno of 2. fake_used should be 0. I explain the
> count of 2 by assuming that one is for the assignment to errno, and
> the other for the read of errno. Our ___error() should not have been
> called at all in this example. So, it's not working properly after all.
>
> I am keen to make this work, but don't know how. Why don't weak symbols
> work for this?
Use the real symbol names. I don't know why what you are doing won't
work, but it's *not* what I'm doing, wo it really doesn't matter
why it doesn't work because it's the wrong thing to do anyway.
> >> I don't see how your major/minor/subminor is any better than the
> >> current major/minor, or how it would avoid the current problem.
> >
> >It would avoid the problem by letting us bump the minor but not the
> >subminor when the errno.h change went in. So long as you did not
> >foolishly replace an existing library of the same major/minor that
> >you had built on your own, the executable would continue to prefer
> >the old library to the new library you had built.
>
> What you are saying is that we would bump the minor numbers on all
> libraries with your system, as opposed to bumping the major numbers
> on all libraries with the current system. This gains nothing as far
> as I can see.
It gains you the ability to keep running the binaries that you won't
(or can't) relink against the correct libc, when you are willing to
rebuild the other libraries (for no reason that I can tell) to make
them depend on the new libc.
It's a magic hand-wave to let you run programs that weren't linked
for -current with libc's from -stable and other shared libraries
not-from-stable-but-from-current.
The real problem here is that you shouldn't be rebuilding libraries
that your old programs would bind to, adding new dependencies in
the process.
I think the soloution is to make the old programs continue to bind to
old libraries. But to be able to add bug fixes to them at the same
time (thus allowing you to wantonly rebuild them), you need a subminor
version, and a binding preference for a given minor.
When the 3.0-release happens, then the major numbers can be bumped,
and the minors and subminors will be rezero-ed. So it doesn't matter
how large the minor number get in the developement branch, so long
as it resets on the release.
Beasically, it prevents FreeBSD from looking like the consequences
of library changes weren't thought out (which they weren't) by adding
a mechanism to prevent high-speed major version increments (incidently,
by thinking it out).
It divorces the idea of additions from the idea of dependent additions
(and/or subtractions).
If I add the function "foo" to a library, you could care less. If I
added the function "__error", and then made all new code call it,
then you start to care.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?199805202327.QAA02369>