Re: libc shlib version
In message [EMAIL PROTECTED] "David O'Brien" writes: : On Wed, Nov 15, 2000 at 12:21:02AM -0700, Warner Losh wrote: : Maybe I'm crazy, but can't we find and kill the API change that caused : this and back it out for 4.x? I suspect it was the per interface stat : changes in the network code, but I could very well be wrong. : : We should not, the API change was one allowed by the way we bump shared : version numbers. Rather than deal with this single case, we should : consider the issue in the large. This makes it harder to deal with mixed environments, but not hugely so. I'm thinking that if is just one thing, and it happened recently, it would be less pain to back out the API change. We're not supposed to have major libc bumps in -stable. If it is a bunch of changes or if the changes happened a long time ago, then we have no choice but to fix the problem now and how the "window" isn't too disruptive. : These sorts of things aren't supposed to impact libc at all. Do we : know which one caused the problem? : : Sure they are. We can add syscalls,etc al. utill the cows come home and : not bump the version number. I can't tell, but it looks like we're agreeing here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
Can we just stop arguing about this and bump the frickin' numbers already? Time is running out! - jordan On Wed, Nov 15, 2000 at 12:21:02AM -0700, Warner Losh wrote: Maybe I'm crazy, but can't we find and kill the API change that caused this and back it out for 4.x? I suspect it was the per interface stat changes in the network code, but I could very well be wrong. We should not, the API change was one allowed by the way we bump shared version numbers. Rather than deal with this single case, we should consider the issue in the large. These sorts of things aren't supposed to impact libc at all. Do we know which one caused the problem? Sure they are. We can add syscalls,etc al. utill the cows come home and not bump the version number. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In message [EMAIL PROTECTED] Jordan Hubbard writes: : Can we just stop arguing about this and bump the frickin' numbers already? : Time is running out! That's your call as RE. Since we don't know what change caused it, that's likely the least bad thing we can do. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version (consensus?)
At 03:26 PM 11/13/00 -0800, David O'Brien wrote: On Mon, Nov 13, 2000 at 03:06:41PM -0800, Satoshi - Ports Wraith - Asami wrote: * I'm going to go ahead and bump -current's libc today in preparation of * doing in -stable if it comes down to it. I know Garret has been waiting * to make some changes that would need a bump anyway. So it won't be * wasted. Can you commit the change RSN? I need a new snap with the updated version numbers before I can even start rebuilding the packages. We are in a race against time now. What's the holdup? Root canal crown prep and make world time. :-) Sorry to hear. sudder Is the bump going to happen before 4.2 or not? I *do* realize what PITA this is. Though for some it is an opportunity, as they can make changes to -current that would require a version bump. Of course if the those changes can be MFC'd then we are in the same boat down the line at some point and -current must be then bumped before -stable can again be bumped. And another compat distribution. 8-/ Main concern is the looming release date 6 days. Would rather see this done right and delay the release past the 20th. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
* From: "David O'Brien" [EMAIL PROTECTED] * Not sure if you saw this message. The more I think about it, I'm not * sure bumping the shared libc version will accomplish anything other than * require a compat4x distribution for 4.2-RELEASE. For the 4.0R upgrade * kit you'd just have to include a libc.so.5, and that would mismatch the * kernel as bad as the libc.so.4 that is currently included. Hmm. That's a good point. So you mean there is no way to build a libc that works for 4.2 that will also work with a 4.0 kernel? (I don't think just changing the libc source on a 4.0 machine will accomplish that. Besides, that sounds even more dangerous, to build something with mixed sources.) * How did you get the included libc.so.4? If you just took a -stable one * that could easily be the problem. The most correct way would be to take * a 4.0-R machine w/src (or at least source and a chrooted build * environment) and only update the libc sources and build libc.so.4 that * way. I don't know enough about the libc to make a decision here, so I will respect whatever you experts decide. However, incompatible is incompatible and it seems to me that we should still bump the version of libc just to make sure people won't get into a similar situation by copying supposedly compatible shared library. (If libc was at so.5 in the upgrade kit it at least wouldn't have killed existing binaries.) By the way, if the conclusion is that we can't provide an upgrade kit that will work for 4.0R (regardless of whether we bump libc or not), I'll just replace that package with something that prints "sorry, we can't support that system anymore, please upgrade". Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version (consensus?)
On Tue, Nov 14, 2000 at 04:03:19PM -0600, Jeffrey J. Mountin wrote: Is the bump going to happen before 4.2 or not? I don't know. I'd like to hear Satoshi's response to my last email on the topic. The typical test [in this case] would be does a 4.0R shared binary still run fine on a 4.2-R system. No one has brought this up as the case. And for the example given, I don't know how bumping libc's shared version number will solve the problem. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
On Tue, Nov 14, 2000 at 02:15:49PM -0800, Satoshi - Ports Wraith - Asami wrote:
Hmm. That's a good point. So you mean there is no way to build a
libc that works for 4.2 that will also work with a 4.0 kernel?
Yes.
(I don't think just changing the libc source on a 4.0 machine will
accomplish that. Besides, that sounds even more dangerous, to build
something with mixed sources.)
IF 4.2-R libc sources would compile on a 4.0-R system the resulting
libc.so.4 will work much better than using a stock 4.2-R libc.so.4. This
is because the /usr/include/sys/ and /usr/include/machine/ headers
(especially the syscall ones) used to compile the 4.2-R libc sources will
match the 4.0-R kernel. Interface changes (as exposed) in /sys/sys and
/sys/arch/include are one of the bigger ways to get a kernel and
userland out of sync.
However, incompatible is incompatible and it seems to me that we should
still bump the version of libc just to make sure people won't get into
a similar situation by copying supposedly compatible shared library.
Maybe but this is unix where we kinda give people all the rope the
need... Switching to a versioned API would probably help this issue.
But it increases the library and toolchain maintenance.
(If libc was at so.5 in the upgrade kit it at least wouldn't have
killed existing binaries.)
I guess that would be one approach... but I fear it will lead us to bump
the version at every release. I think this could increase support
questions.
By the way, if the conclusion is that we can't provide an upgrade kit
that will work for 4.0R (regardless of whether we bump libc or not),
I'll just replace that package with something that prints "sorry, we
can't support that system anymore, please upgrade".
If you've got space [and time] to build a special libc.so.4 for 4.[01]-R,
using 4.2 libc (only) sources, it should work well. Of course at some
point it is a hopeless cause, as there will be some change to the libc
sources that requires changes in /usr/include/{sys,machine}/ .
In the merging of xpg4 into libc using the various Binutils utils.
JDP would know more about the viability of this than I do.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
On Mon, 13 Nov 2000, David O'Brien wrote: On Mon, Nov 13, 2000 at 04:44:17AM -0500, Daniel M. Eischen wrote: Why not find what was added and back it out? Why loose the functionality. Bumping a shared version isn't that big a deal. It hasn't been shown that functionality would be lost. If it can't be worked around and functionality is lost, then I agree -- leave it in. Aren't we going to need yet another version bump for 5.0? -current libc will have to be bumped at the same time it is in RELENG_4 as they are current at the same value. I mean when 5.0 is released. There's bound to be more changes that require another version bump. Wasn't it dg who was waiting to add some changes to libc requiring a version bump? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Satoshi - Ports Wraith - Asami [EMAIL PROTECTED] wrote: * From: John Polstra [EMAIL PROTECTED] * If it contains a new libc, that seems like the real problem * to me. It's always risky to use new libs (especially libc) with an * old kernel. New ports and packages didn't work with the old libc because someone moved stuff from libxpg4 to libc without changing the version numbers. Putting it in the upgrade kit was the only way to let 4.0R people use ports-current. That sounds like a good reason to me. Maybe you should have included a kernel in the upgrade kit too ... ;-) Maybe I should have insisted that the libc version change back then. I really wish we could keep the two version numbers from a.out, so I don't have to worry about stuff like this. : Sorry! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Thomas David Rivers [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Satoshi - Ports Wraith - Asami) wrote: I really wish we could keep the two version numbers from a.out, so I don't have to worry about stuff like this. : You can, if you will accept some restrictions: Let's say the two numbers are the Version number and the Revision number. And, let's furthermore say we will restrict ourselves to only 99 revisions per Version. Then; let the Elf library number be: (100 * Version number) + Revision number *poof* two numbers... i.e. library version 10.20 would get 1020 as the Elf version number. Nope, that wouldn't provide the desired benefits. The whole point of having two version numbers is that they are treated differently. The a.out dynamic linker looked for an exact match on the major version number, and a = match on the minor number. Doing what you suggest wouldn't accomplish that -- we'd still get the exact match on both numbers. This all was discussed to death in the mailing lists when we switched to ELF, so pardon me if I refuse to let myself get drawn into another long-winded rehash of it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Satoshi Asami [EMAIL PROTECTED] wrote: It was brought to my attention that recent 40upgrade kills all the networking programs. Looking at the plists, the only thing I can think of is that libc.so.4 has somehow lost backward compatibility. This isn't much to go on. What are the symptoms? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
* From: John Polstra [EMAIL PROTECTED] * In article [EMAIL PROTECTED], * Satoshi Asami [EMAIL PROTECTED] wrote: * * It was brought to my attention that recent 40upgrade kills all the * networking programs. Looking at the plists, the only thing I can * think of is that libc.so.4 has somehow lost backward compatibility. * * This isn't much to go on. What are the symptoms? I don't know much either, as I haven't experienced it myself. The reports say core dumps from fetch, etc. Please see PR #21997. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Satoshi - Ports Wraith - Asami [EMAIL PROTECTED] wrote: * From: John Polstra [EMAIL PROTECTED] * In article [EMAIL PROTECTED], * Satoshi Asami [EMAIL PROTECTED] wrote: * * It was brought to my attention that recent 40upgrade kills all the * networking programs. Looking at the plists, the only thing I can * think of is that libc.so.4 has somehow lost backward compatibility. * * This isn't much to go on. What are the symptoms? I don't know much either, as I haven't experienced it myself. The reports say core dumps from fetch, etc. Please see PR #21997. OK, all those failures are signal 12 == SIGSYS == non-existent signal call. Somebody must have made a change to libc which caused it to start using a signal call that didn't exist in 4.0-RELEASE. So yes, I suppose that the version number of libc should be bumped. Likewise for libc_r, if it hasn't already been bumped for this release. What a pain -- that means yet another compatxx distribution. Whether the bump is still possible at this late date is a question for the Release Engineer. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
Whether the bump is still possible at this late date is a question for the Release Engineer. Any pending bumps should *definitely* occur before the release goes out, so consider me all in favor. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
* From: Jordan Hubbard [EMAIL PROTECTED] * Any pending bumps should *definitely* occur before the release goes * out, so consider me all in favor. You guys may have missed what I said in the first mail. That implies rebuilding all packages. I can do that, but I'm afraid it will most likely delay the release. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
