Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 07:59:03AM -0500, Daniel Eischen wrote: Did you miss the HEADS UP posted to -current? You better read these. Somehow, I just didn't notice that there is a HEADS UP. I have bang my head to the wall because of this sillyness I've done :( I have just reformat my box, and now running: 5.0-20010210-CURRENT I think this is currently the last known good snapshot in current.freebsd.org To get around the installworld problem, do: Too late. I have just, for the first time since running -CURRENT feel the sorrow of running -CURRENT. He3x... But I'm not complaining. I take this as a challenge and as a reminder to not miss any more HEADS UPs ;) Thanks anyway for the help... Dan Eischen /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Wed, Feb 14, 2001 at 12:47:59AM +, Paul Richards wrote: Instead what we have now is libxyz.so.3 and libxyz.so.3 which are different from each other. No different than two libxyz.so.3.1 and libxyz.so.3.1 could be (a.out days). (well not entirely true, but in the a.out days, one could make a major change in the functionality of a lib routine w/o even a minor bump) If two libxyz.so.3 and libxyz.so.3 are incompatible, then a major shared version bump wasn't done when it should have been. When you login to a strange machine and you're trying to diagnose a problem there's no way to know whether the libc they've got installed is of version X or version Y because there's nothing to tell you what sources libc.so.Z was built from, it could be the .Z version with the X fixes or the Y fixes. When we had minor version numbers you still didnt' know if the X fixes or Y fixes were in it. You've missed the point I was trying to make. Our reluctance to bump what we perceive to be a major number is hampering our ability to differentiate between different versions. We aren't reluctant to bump in -STABLE if there is a need for it. The reluctance is in -CURRENT where we bump once and let that cover all the incompatibilities. We don't put our released version users thru the hoops we are willing to for the development version users. We could just as easily use a minor numbering scheme with Elf to indicate that a version change has occured but not an interface change. We only bumped due to interface changes in the .MAJOR.MINOR days. The difference is *adding* an interface today does in cause a bump. In the .MAJOR.MINOR days it would require a bump the MINOR number. In both days, an incompatible change in an existing interface require(s)(ed) a MAJOR bump. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
David O'Brien wrote: We only bumped due to interface changes in the .MAJOR.MINOR days. The difference is *adding* an interface today does in cause a bump. In the .MAJOR.MINOR days it would require a bump the MINOR number. In both days, an incompatible change in an existing interface require(s)(ed) a MAJOR bump. Yes, that was true. The way we used to do it didn't address all the problems I'm alluding to either but I felt we had more versioning before than we do now. Regardless of that the issues are important enough that I think we should discuss them. There are in my mind two issues: 1) Being able to have the system continue working when a significant interface change occurs. 2) Being able to identify a specific version of a library on a system in order to determine whether it's a rogue version for a particular application. The former I accept works fine now as long as you can take the pain of current. An asthetic requirement to have a nice library number is counter-productive though when it screws the development team so completely that the system is unusable for a week. While developers should accept that they must occasionally suffer considerable pain when running -current it's foolish to not consider alternative methods of working when we run into a problem that causes the project to come to a grinding halt. Most of us don't have rooms full of development boxes, we have all our day to day applications on our development box and having to rebuild it completely is something we accept we may have to do on occasion but it's something we should try and avoid having to happen because it's so wasteful of everyone's time and energy. This library version problem is a non-problem from a technological perspective, it's only a problem from a policy perspective and it's a policy that's based entirely on asthetic requirements. I don't want to see library versions get into the hundreds (unless we adopt that as a convention i.e. 5xx) because we're bumping them all the time but at the same time, if one is necessary then it's necessary, even if it's current. Commercial vendors will skip version numbers in their public releases if their internal development required more than one bump. I don't think the attempt to make the major number bump once per release is a sensible goal. If we have to bump a major number on the stable branch (god forbid, but it may happen one day) then we'll have to deviate from that policy because it'll clash with the version number of -current and therefore I think the policy is flawed because it doesn't consider all the possible scenarios we might have to deal with. The second issue is probably not related to bumping the library version, since I accept your point that we didn't bump major or minor numbers for every change to the library. I think some way of identifying a build of a library would be a good thing though and perhaps we should discuss adding a "properties" field to libraries so we can identify which specific version of a library is installed. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: Commercial vendors will skip version numbers in their public releases if their internal development required more than one bump. Which ones? Sun Solaris still ships their libc as "libc.so.1", even in Solaris 8. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
2001-02-15
Thread
Paul Richards_imap/mail.originative.co.uk/Inbox.sbd/New Mail.sbd/OpenLDAP.sbd/Devel
David O'Brien wrote: On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: Commercial vendors will skip version numbers in their public releases if their internal development required more than one bump. Which ones? Sun Solaris still ships their libc as "libc.so.1", even in Solaris 8. I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Thu, Feb 15, 2001 at 12:44:26PM +, Paul Richards_imap/mail.originative.co.uk/Inbox.sbd/New Mail.sbd/OpenLDAP.sbd/Devel wrote: I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Yes, I know how Solaris does symbol versioning. FreeBSD does not have this technology today, so we cannot use it instead. The Linux way of doing this still has problems (see the Binutils mailing list). I'm waiting for the Linux way of doing this to fully settle and prove itself before I look at maybe using it for FreeBSD. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Thank you ! This confused the hell out of me when I first bumped into it on Solaris ! Something to read in the morning -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Wed, Feb 14, 2001 at 00:47 +, Paul Richards wrote: To be honest, DLLs are better than our scheme from that perspective. While you might screw a load of applications by upgrading a DLL with the same name you can at least look at the version number in the properties to find out which version of that DLL it is. There's no way of looking at a libc.so.5 and say which version of libc.so.5 it is. Although `ident` does provide a slightly cumbersome way of getting some information to help with that when you really need it. But isn't this aspect something a project creating its own libc can solve by itself regardless of the executable format the library is held in? You're always free to introduce a version query function returning the necessary info to the app. And storing this information in an ASCII frame in the code while separating the pure number upon (logical) query you can do something in userland, too, like "strings $LIB | grep 'LibVersion'". Admittedly it's not elegant neither is it done with system tools like "executable properties". But it should work. And it's your or our lib (depending on how you look at it) -- do with it whatever you want to ... :) And why does it remind me of "you cannot tell the config used for compilation from looking at a kernel image, without watching it run and probe your machine and still having some possibility of errors / misses"? That's BTW where I feel that INCLUDE_CONFIG_FILE should be a default option. Why not just stick this info into the resulting binary if you depend on knowing it later and cost is acceptable if not unnoticable? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, 12 Feb 2001 17:20:51 -0800, Peter Wemm [EMAIL PROTECTED] said: If we had taken -current to 500, we could go to 501, 502, etc as required to stop killing our developers, and prior to entering 5.0-BETA we go back to the next sequentially available major number (be it 5, or 6 if RELENG_4 bumps again). Shared library version numbers going backwards is *evil*. Not quite as evil as it used to be under a.out, but still evil. Please don't go there. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Garrett Wollman wrote: On Mon, 12 Feb 2001 17:20:51 -0800, Peter Wemm [EMAIL PROTECTED] said: If we had taken -current to 500, we could go to 501, 502, etc as required to stop killing our developers, and prior to entering 5.0-BETA we go back to the next sequentially available major number (be it 5, or 6 if RELENG_4 bumps again). Shared library version numbers going backwards is *evil*. Not quite as evil as it used to be under a.out, but still evil. Please don't go there. There is no concept of "forward" or "backward" as far as the toolchain and runtime support goes. There is only "filename exists" or "file not found". Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, 13 Feb 2001 07:38:40 -0800, Peter Wemm [EMAIL PROTECTED] said: There is no concept of "forward" or "backward" as far as the toolchain and runtime support goes. There is only "filename exists" or "file not found". This is a human-factors issue, not a code issue. People expect to see version numbers increasing. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. What's wrong with shipping with say libc.so.505 in 5.0 and then say libc.so.645 in 6.0? Umm, I dunno, except that it'll look weird, but that's just a matter of taste. I actually quite like this idea, I prefer it to the dropping down to a single digit. What happens if there's a critical fix in a -stable branch, we *must* have the option to bump library versions when we need to and if we release 5-stable and intend to release 6-stable with libc.so.6 then you've got problems if you find a showstopper in 5-stable and need to release a new libc in that branch. If we have 3 digit library versions then there's always scope to roll forward library versions on a branch, as long as there aren't more than 99 of them :-) Of course, what we really need is "mandatory minor numbers", i.e. minor numbers that are treated as "I need this version", not as "I need this version or newer"... *ducks* *runs* When we dropped minor numbers I had a worry that we'd run into one of Windows' greatest problems and we have. Applications that are developed and tested to work with a particular library might not work with a different version, we're suffering a worst case scenario of this problem now but even "fixes" in new versions can cause applications to break and we've already seen this many times in this iteration of -current. I think we need some form of version control on libraries so that applications know whether they're linking with the version they're designed for and to be able to keep multiple versions around in the system so all applications continue to work. I understand the reasoning that Elf doesn't need minor numbers but they served an useful purpose in maintaining application compatibility that we now lack. If there isn't any better solution then we should be much more free and easy in bumping the version number because otherwise we're storing up problems exactly along the lines that makes Windows so flakey when you change a dll. Another issue is that if two versions of a library have the same number then there's no way to find out which the application was intended to link against. If the version number is bumped more regularly then you can scan the filesystem and ldd the binaries to find out whether they need to be rebuilt against a new library. Given a lot of negatives and only an asthetic postive library bumping should take place much more often and moving to a 3 digit number based on the branch actually makes a lot of sense. Paul Richards To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Garrett Wollman wrote: On Tue, 13 Feb 2001 07:38:40 -0800, Peter Wemm [EMAIL PROTECTED] said: There is no concept of "forward" or "backward" as far as the toolchain and runtime support goes. There is only "filename exists" or "file not found". This is a human-factors issue, not a code issue. People expect to see version numbers increasing. The proposal as it presently stands is to never let these reach beta or -release. -current developers can deal with this just fine, it is the least of their problems. However, some want these in -release too... But that is a long way away. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 04:24:00PM +, Paul RichardsF wrote: When we dropped minor numbers I had a worry that we'd run into one of Windows' greatest problems and we have. Applications that are developed and tested to work with a particular library might not work with a different version, How is that??? It is beter under ELF than a.out in that ld.so isn't making a guess as to which shared libs were compatible and which weren't. The ELF ld.so does not look for shared lib libxyz.so.2, find libxyz.so.3 and decide maybe they are close enough and use it instead. The a.out ld.so would use libxyz.so.2.2 when the binary was compiled and tested with libxyz.so.2.1. we're suffering a worst case scenario of this problem now but even "fixes" in new versions can cause applications to break and Don't confuse development (which in years past would have never made it out of the "company's" development machines, with deployed releases. we've already seen this many times in this iteration of -current. *Way*, way too many people are using -CURRENT that have no business doing so. I think we need some form of version control on libraries so that applications know whether they're linking with the version they're designed for and to be able to keep multiple versions around in the system so all applications continue to work. We have that today and it works very well [in our released product]. I understand the reasoning that Elf doesn't need minor numbers but they served an useful purpose in maintaining application compatibility that we now lack. NO! Please review the rules ld.so in both ELF and a.out varieties uses in finding a desired shared lib. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
David O'Brien wrote: On Tue, Feb 13, 2001 at 04:24:00PM +, Paul RichardsF wrote: When we dropped minor numbers I had a worry that we'd run into one of Windows' greatest problems and we have. Applications that are developed and tested to work with a particular library might not work with a different version, How is that??? Because applications expect a stable interface. If an application is developed and tested against a particular behaviour of a library function and that function's behaviour is changed it could and sometimes does break the application. More often than not that sort of failure is a side effect of *fixing* something that was previously broken. It is beter under ELF than a.out in that ld.so isn't making a guess as to which shared libs were compatible and which weren't. The ELF ld.so does not look for shared lib libxyz.so.2, find libxyz.so.3 and decide maybe they are close enough and use it instead. The a.out ld.so would use libxyz.so.2.2 when the binary was compiled and tested with libxyz.so.2.1. Instead what we have now is libxyz.so.3 and libxyz.so.3 which are different from each other. When you've got an application that just broken you've got no way of finding out which version of the library was the working one, or any way of linking against it because it cannot co-exist with the newer version because they've got the same name. This is precisely the problem we've got now. Maybe I didn't make it clear in my last email, it's not the old a.out way of picking the library to link with that was better, it was the finer grained versioning. we're suffering a worst case scenario of this problem now but even "fixes" in new versions can cause applications to break and Don't confuse development (which in years past would have never made it out of the "company's" development machines, with deployed releases. This applies to released code as much as in-development code. When you login to a strange machine and you're trying to diagnose a problem there's no way to know whether the libc they've got installed is of version X or version Y because there's nothing to tell you what sources libc.so.Z was built from, it could be the .Z version with the X fixes or the Y fixes. To be honest, DLLs are better than our scheme from that perspective. While you might screw a load of applications by upgrading a DLL with the same name you can at least look at the version number in the properties to find out which version of that DLL it is. There's no way of looking at a libc.so.5 and say which version of libc.so.5 it is. Although `ident` does provide a slightly cumbersome way of getting some information to help with that when you really need it. we've already seen this many times in this iteration of -current. *Way*, way too many people are using -CURRENT that have no business doing so. I agree with that, I've always been an advocate of raising the barrier of entry to using -current. I think we need some form of version control on libraries so that applications know whether they're linking with the version they're designed for and to be able to keep multiple versions around in the system so all applications continue to work. We have that today and it works very well [in our released product]. I understand the reasoning that Elf doesn't need minor numbers but they served an useful purpose in maintaining application compatibility that we now lack. NO! Please review the rules ld.so in both ELF and a.out varieties uses in finding a desired shared lib. You've missed the point I was trying to make. Our reluctance to bump what we perceive to be a major number is hampering our ability to differentiate between different versions. It has nothing to do with the difference between a.out and Elf library selection, it's a project policy problem. We could just as easily use a minor numbering scheme with Elf to indicate that a version change has occured but not an interface change. To some extent a three figure version number does something along those lines. If we bumped the version number with a bit more abandon this problem wouldn't even be a problem. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, 12 Feb 2001, John Indra wrote: Just finished buildworld on recent -CURRENT. installworld target died with this: === gnu/usr.bin/perl/suidperl install -c -s -o root -g wheel -m 511 suidperl /usr/bin /usr/bin/sperl5 - /usr/bin/suidperl /usr/bin/sperl5.6.0 - /usr/bin/suidperl === gnu/usr.bin/perl/library sed: stdout: Bad file descriptor *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/library. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Sigh... Now I have an impaired world and kernel that's way out of sync :( I guess I am still lucky enough if this mail can reach the mailing list. This mail only serves as a warning to other typical -CURRENT user like me to be aware that -CURRENT has troubles for the moment... Did you miss the HEADS UP posted to -current? You better read these. To get around the installworld problem, do: # cd /usr/src/usr.bin/sed # make install # cd /usr/src # make installworld If that doesn't work, then try: # make -k installworld # make installworld -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
To be blunt, the FILE * changes go too far, even for -current. Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Alternatively, the upgrade path must be fixed. We've managed to avoid extra special instructions in the vast majority of cases, and I don't want to start introducing them now. It is the road to madness. We tried that once before and the support load was too high. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, 12 Feb 2001, Warner Losh wrote: To be blunt, the FILE * changes go too far, even for -current. Other than having to installworld twice, I've had zero problems. But I don't recompile my applications often, and am probably still running things that depend on libc.so.4. Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Too bad ELF libraries don't have minor version numbers. It's a shame to waste a library version number. Alternatively, the upgrade path must be fixed. We've managed to avoid extra special instructions in the vast majority of cases, and I don't want to start introducing them now. It is the road to madness. We tried that once before and the support load was too high. I don't have the time or resources to fix the upgrade path. If someone else wants to, it would certainly be appreciated. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
In message [EMAIL PROTECTED] Daniel Eischen writes: : On Mon, 12 Feb 2001, Warner Losh wrote: : To be blunt, the FILE * changes go too far, even for -current. : : Other than having to installworld twice, I've had zero problems. : But I don't recompile my applications often, and am probably : still running things that depend on libc.so.4. I have lots of binaries that depend on libc.so.5 (I just checked) and none that depend on libc.so.4 or libc.so.3 (since those were removed from my system a while ago). I suspect many of them will break. : Changes of this magnitude require a bump of the major number, even : though we've already done that in -current. It breaks nearly : everything, including the upgrade path. Alternatively, the locking : changes need to be backed out. : : Too bad ELF libraries don't have minor version numbers. It's : a shame to waste a library version number. Don't think of it as a waste. : Alternatively, the upgrade path must be fixed. We've managed to avoid : extra special instructions in the vast majority of cases, and I don't : want to start introducing them now. It is the road to madness. We : tried that once before and the support load was too high. : : I don't have the time or resources to fix the upgrade path. If : someone else wants to, it would certainly be appreciated. Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. I have to "me too" this; the change simply isn't OK. There are a variety of ways that we can work around the issue and maintain binary compatibility, whilst still moving towards something that is immune to this breakage in future. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Yup, I agree here. IMO so many things depend on the stdio bits, that a major number increase would have been desireable. So far, bzip2, pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be rebuilt. Bumping the major number would at least allow these a stay of execution. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, 12 Feb 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Daniel Eischen writes: : On Mon, 12 Feb 2001, Warner Losh wrote: : To be blunt, the FILE * changes go too far, even for -current. : : Other than having to installworld twice, I've had zero problems. : But I don't recompile my applications often, and am probably : still running things that depend on libc.so.4. I have lots of binaries that depend on libc.so.5 (I just checked) and none that depend on libc.so.4 or libc.so.3 (since those were removed from my system a while ago). I suspect many of them will break. : Changes of this magnitude require a bump of the major number, even : though we've already done that in -current. It breaks nearly : everything, including the upgrade path. Alternatively, the locking : changes need to be backed out. : : Too bad ELF libraries don't have minor version numbers. It's : a shame to waste a library version number. Don't think of it as a waste. : Alternatively, the upgrade path must be fixed. We've managed to avoid : extra special instructions in the vast majority of cases, and I don't : want to start introducing them now. It is the road to madness. We : tried that once before and the support load was too high. : : I don't have the time or resources to fix the upgrade path. If : someone else wants to, it would certainly be appreciated. Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. If you bump the library versions, doesn't that fix the upgrade path? I can think of a gross hack that gets around the problem for now. Allocate the FILE with enough storage for the lock, but don't declare it in FILE. __sF[3] would still be the same size and we could have __sF_locks[3] internally, and use these if fp is stdin, stdout, or stderr, else the lock is at the end of the struct. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Then wouldn't the "partially applied patch" rule apply? eg, back it out until the issues can be resolved. Breaking the upgrade path isn't acceptible. If you bump the library versions, doesn't that fix the upgrade path? No, because the library version bump has already happened. I can think of a gross hack that gets around the problem for now. Allocate the FILE with enough storage for the lock, but don't declare it in FILE. __sF[3] would still be the same size and we could have __sF_locks[3] internally, and use these if fp is stdin, stdout, or stderr, else the lock is at the end of the struct. You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. Now, __sF is defined as an array of FILE_old and handled specially internally (this part is gross, but necessary). You'll have to put the lock, etc. in a separate array and handle it specially, or you can have real FILE structures shadowing the FILE_old structures. Because this is a hack for binary compatibility and upgrading only, you can throw it away before we actually get to 5.0. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Warner Losh [EMAIL PROTECTED] writes: Alternatively, the upgrade path must be fixed. I don't see any way to do that. Everything on your system that isn't statically linked will need to be recompiled unless the libc major number is bumped. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch for FILE problems (was Re: -CURRENT is bad for me...)
Attached is a patch that attempts to work around recent stdio
breakage in -current. I've verified it compiles, but won't be
able to test it until at least tomorrow. If someone wants to
review it and verify it works, I'll commit it.
Thanks,
--
Dan Eischen
Index: include/stdio.h
===
RCS file: /opt/FreeBSD/cvs/src/include/stdio.h,v
retrieving revision 1.28
diff -u -r1.28 stdio.h
--- include/stdio.h 2001/02/12 03:31:23 1.28
+++ include/stdio.h 2001/02/12 23:21:41
@@ -96,6 +96,39 @@
*
* NB: see WARNING above before changing the layout of this structure!
*/
+typedefstruct __old_sFILE {
+ unsigned char *_p; /* current position in (some) buffer */
+ int _r; /* read space left for getc() */
+ int _w; /* write space left for putc() */
+ short _flags; /* flags, below; this FILE is free if 0 */
+ short _file; /* fileno, if Unix descriptor, else -1 */
+ struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */
+ int _lbfsize; /* 0 or -_bf._size, for inline putc */
+
+ /* operations */
+ void*_cookie; /* cookie passed to io functions */
+ int (*_close) __P((void *));
+ int (*_read) __P((void *, char *, int));
+ fpos_t (*_seek) __P((void *, fpos_t, int));
+ int (*_write) __P((void *, const char *, int));
+
+ /* separate buffer for long sequences of ungetc() */
+ struct __sbuf _ub; /* ungetc buffer */
+ unsigned char *_up; /* saved _p when _p is doing ungetc data */
+ int _ur;/* saved _r when _r is counting ungetc data */
+
+ /* tricks to meet minimum requirements even when malloc() fails */
+ unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
+ unsigned char _nbuf[1]; /* guarantee a getc() buffer */
+
+ /* separate buffer for fgetln() when line crosses buffer boundary */
+ struct __sbuf _lb; /* buffer for fgetln() */
+
+ /* Unix stdio files get aligned to block boundaries on fseek() */
+ int _blksize; /* stat.st_blksize (may be != _bf._size) */
+ fpos_t _offset;/* current lseek offset (see WARNING) */
+} __old_FILE;
+
typedefstruct __sFILE {
unsigned char *_p; /* current position in (some) buffer */
int _r; /* read space left for getc() */
@@ -131,7 +164,7 @@
} FILE;
__BEGIN_DECLS
-extern FILE __sF[];
+extern __old_FILE __sF[];
__END_DECLS
#define__SLBF 0x0001 /* line buffered */
@@ -194,9 +227,9 @@
#defineSEEK_END2 /* set file offset to EOF plus offset */
#endif
-#definestdin (__sF[0])
-#definestdout (__sF[1])
-#definestderr (__sF[2])
+#definestdin ((FILE *)__sF[0])
+#definestdout ((FILE *)__sF[1])
+#definestderr ((FILE *)__sF[2])
/*
* Functions defined in ANSI C standard.
Index: lib/libc/stdio/_flock_stub.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc/stdio/_flock_stub.c,v
retrieving revision 1.5
diff -u -r1.5 _flock_stub.c
--- lib/libc/stdio/_flock_stub.c2001/02/11 22:06:39 1.5
+++ lib/libc/stdio/_flock_stub.c2001/02/12 23:16:41
@@ -67,6 +67,21 @@
int fl_count; /* recursive lock count */
};
+static FILEstd_files[3];
+
+static inline FILE *
+get_file_with_lock(FILE *fp)
+{
+ if (fp == stdin)
+ return (std_files[0]);
+ else if (fp == stdout)
+ return (std_files[1]);
+ else if (fp == stderr)
+ return (std_files[2]);
+ else
+ return (fp);
+}
+
/*
* Allocate and initialize a file lock.
*/
@@ -89,9 +104,10 @@
}
void
-_flockfile(FILE *fp)
+_flockfile(FILE *f)
{
pthread_t curthread = _pthread_self();
+ FILE*fp = get_file_with_lock(f);
/*
* Check if this is a real file with a valid lock, creating
@@ -123,9 +139,10 @@
}
int
-_ftrylockfile(FILE *fp)
+_ftrylockfile(FILE *f)
{
pthread_t curthread = _pthread_self();
+ FILE*fp = get_file_with_lock(f);
int ret = 0;
/*
@@ -153,9 +170,10 @@
}
void
-_funlockfile(FILE *fp)
+_funlockfile(FILE *f)
{
pthread_t curthread = _pthread_self();
+ FILE*fp = get_file_with_lock(f);
/*
* Check if this is a real file with a valid lock owned
Index: lib/libc/stdio/findfp.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc/stdio/findfp.c,v
retrieving revision 1.12
diff -u -r1.12 findfp.c
--- lib/libc/stdio/findfp.c 2001/02/12 03:31:23 1.12
+++ lib/libc/stdio/findfp.c 2001/02/13 00:05:09
@@ -65,15 +65,14 @@
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hack. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Daniel Eischen writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. Thank you! I appreciate this! I'll kick off the compile right now. I have a machine I need to upgrade tonight. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. How does it break the upgrade path from 4.x to 5.0?? 5.0 has a higher libc.so version than 4.2. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Daniel Eischen [EMAIL PROTECTED] writes: Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Please. Let's not, and say we did. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 04:20:04PM -0800, Alex Zepeda wrote: How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Yes. I don't want to be in a position where we wonder what happened to libc.so.5 when I don't see it in my /usr/lib/ or /usr/lib/compat/ Seems to me that a new major number is far cleaner than a gross hack. I am very against this. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
In message [EMAIL PROTECTED] "David O'Brien" writes: : On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: : Changes of this magnitude require a bump of the major number, even : though we've already done that in -current. It breaks nearly : everything, including the upgrade path. : : How does it break the upgrade path from 4.x to 5.0?? 5.0 has a higher : libc.so version than 4.2. It breaks the current pre Feb 10 - current post Feb 10 case. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Daniel Eischen [EMAIL PROTECTED] writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. : : Please. Let's not, and say we did. I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 01:42:16PM -0800, Alex Zepeda wrote: Yup, I agree here. IMO so many things depend on the stdio bits, that a major number increase would have been desireable. So far, bzip2, pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be rebuilt. Bumping the major number would at least allow these a stay of execution. /usr/ports is *very* easy to use. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions on IRC for the past two hours. Peter will likely commit a patch sometime soon. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Warner Losh [EMAIL PROTECTED] writes: : I'd rather see this patch, or something similar, than bump the major : version again. We can phase in a better way to obviate the need to do : this in the future. : : Brian Feldman, Peter Wemm, David O'Brien and myself have been : discussing possible solutions on IRC for the past two hours. Peter : will likely commit a patch sometime soon. If there's something better than Daniel's solution that doesn't require a major bump and is compatible with the old libc.so.5 api, then I'm all for that. I'd love to test it out as well if there's any desire for that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 01:48:33AM +0100, Dag-Erling Smorgrav wrote: Peter will likely commit a patch sometime soon. I am hoping it is posted for discussion to -arch before commit (so we get this right). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On 13 Feb 2001, Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions on IRC for the past two hours. Peter will likely commit a patch sometime soon. I wish someone would have told me; I wouldn't have bothered with the patch. At any rate, kudos to you if you can fix it. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: If there's something better than Daniel's solution that doesn't require a major bump and is compatible with the old libc.so.5 api, then I'm all for that. I'd love to test it out as well if there's any desire for that. Yes, there is. Steal _cookie, rename it to _ext or something like that, and make it point to a separate structure that contains _cookie and the mutex. Optionally add a #define to avoid changing libc code that uses _cookie. That's not what Peter intends to commit, though. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 07:28:30PM -0500, Daniel Eischen wrote:
Attached is a patch that attempts to work around recent stdio
breakage in -current. I've verified it compiles, but won't be
able to test it until at least tomorrow. If someone wants to
review it and verify it works, I'll commit it.
How about this? :^)
--- lib/libc/Makefile.orig Mon Feb 12 16:30:48 2001
+++ lib/libc/Makefile Mon Feb 12 16:30:37 2001
@@ -7,7 +7,7 @@
# from CFLAGS below. To remove these strings from just the system call
# stubs, remove just -DSYSLIBC_RCS from CFLAGS.
LIB=c
-SHLIB_MAJOR= 5
+SHLIB_MAJOR= 6
SHLIB_MINOR= 0
CFLAGS+=-DLIBC_RCS -DSYSLIBC_RCS -I${.CURDIR}/include
AINC= -I${.CURDIR}/${MACHINE_ARCH}
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh wrote: In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Daniel Eischen [EMAIL PROTECTED] writes: : Attached is a patch that attempts to work around recent stdio : breakage in -current. I've verified it compiles, but won't be : able to test it until at least tomorrow. If someone wants to : review it and verify it works, I'll commit it. : : Please. Let's not, and say we did. I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Personally, I think we place far too much weight on the major number thing. I think we should be allowed to bump it when the alternative is 'major pain' to developers. I also object to hacking around like this. I would far prefer that we fix it properly. We *need* to be able to innovate, especially with locking in libc in 5.x. I suspect we will have major events like this several more times before 5.0-R when we add in hooks for KSE or rfork threading. http://people.freebsd.org/~peter/stdio.diff3 Lets commit that and get on with life. Existing binaries will just keep on running. And if we dont ship libc.so.5, in 5.0-R, then *so what*? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 04:33:26PM -0800, Alex Zepeda wrote: How about this? :^) Because bumping the shared version again needs *DISCUSSING*. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I'd rather see this patch, or something similar, than bump the major version again. We can phase in a better way to obviate the need to do this in the future. Brian Feldman, Peter Wemm, David O'Brien and myself have been discussing possible solutions on IRC for the past two hours. Peter will likely commit a patch sometime soon. Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. I can deal with /usr/local and /usr/X11R6 recompiles, but when the installworld dies because the dynamic linked copy of /usr/bin/* in /tmp/XXX/* gets the /usr/lib/libc.so.5 clobbered and explodes, leaving a 100% totally screwed up system, then I begin to think we are doing something wrong. If it wasn't for that, I could deal with a /usr/local and /usr/X11R6/lib recompile. I wish the people who say 'dont bump libraries at any cost' would fix the build so it was possible for an installworld to complete with an incompatable libc change. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: http://people.freebsd.org/~peter/stdio.diff3 Except that we bump to 500 instead of 6, and back to 5 before -RELEASE. When we've branched RELENG_5, if we need to bump libc's major in 6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we want, and bump it down to 6 before 6.0-RELEASE. People tracking -CURRENT will end up with a handful of different libc versions, but they'll avoid the pains we're going through now, and people upgrading from RELENG_N to RELENG_N+1 will never see a libc major version increase of more than 1. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh wrote: In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Warner Losh [EMAIL PROTECTED] writes: : I'd rather see this patch, or something similar, than bump the major : version again. We can phase in a better way to obviate the need to do : this in the future. : : Brian Feldman, Peter Wemm, David O'Brien and myself have been : discussing possible solutions on IRC for the past two hours. Peter : will likely commit a patch sometime soon. If there's something better than Daniel's solution that doesn't require a major bump and is compatible with the old libc.so.5 api, then I'm all for that. I'd love to test it out as well if there's any desire for that. Do you really want to carry the baggage for the entire 5.0-RELEASE and 5-STABLE branch? Just because of a pedantic policy point? Personally, I think that sucks. :-( Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hack. The major number has ALREADY BEEN BUMPED. The "gross hack" is a transitional step necessary for the upgrade path to work, and would be removed after it was no longer required. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:09:19PM -0800, Peter Wemm wrote: I can deal with /usr/local and /usr/X11R6 recompiles, but when the installworld dies because the dynamic linked copy of /usr/bin/* in /tmp/XXX/* gets the /usr/lib/libc.so.5 clobbered and explodes, leaving a 100% totally screwed up system, then I begin to think we are doing something wrong. If it wasn't for that, I could deal with a /usr/local and /usr/X11R6/lib recompile. 100% agreed. Before doing this, can we put out a *HEADS UP* for people to NOT update their -current boxes for a day or two, and take a look at fixing the `make installworld' problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 02:14:03AM +0100, Dag-Erling Smorgrav wrote: No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). Uh, NO. It was discussed on IRC, NOT -arch. It needs to go there before doing something like this. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: http://people.freebsd.org/~peter/stdio.diff3 Except that we bump to 500 instead of 6, and back to 5 before -RELEASE. When we've branched RELENG_5, if we need to bump libc's major in 6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we want, and bump it down to 6 before 6.0-RELEASE. People tracking -CURRENT will end up with a handful of different libc versions, but they'll avoid the pains we're going through now, and people upgrading from RELENG_N to RELENG_N+1 will never see a libc major version increase of more than 1. I think this is the least evil of all. I totally support this option. It gives us a nice stable sequential *-RELEASE version numbering sequence without holes. It avoids the current problem: - RELENG_4 bumped from 3.0 to 4.0 - this forced a premature 4.0-5.0 bump in -current - we missed our chance for major changes. (!!!) If we had taken -current to 500, we could go to 501, 502, etc as required to stop killing our developers, and prior to entering 5.0-BETA we go back to the next sequentially available major number (be it 5, or 6 if RELENG_4 bumps again). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Daniel Eischen wrote: Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Thanks, __BEGIN_DECLS -extern FILE __sF[]; +extern __old_FILE __sF[]; __END_DECLS -#define stdin (__sF[0]) -#define stdout (__sF[1]) -#define stderr (__sF[2]) +#define stdin ((FILE *)__sF[0]) +#define stdout ((FILE *)__sF[1]) +#define stderr ((FILE *)__sF[2]) The problem with this is that it carries the baggage into 5.0-RELEASE and beyond... I wish there was a way we could get rid the array entirely and still stay compatable, but I dont see how. :-( A major bump makes it easy. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Mike Smith wrote: On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hac k. The major number has ALREADY BEEN BUMPED. The "gross hack" is a transitional step necessary for the upgrade path to work, and would be removed after it was no longer required. The "gross hack" can *NEVER* be removed and will live on through 5.0-RELEASE and 5.0-STABLE, because we *continue* to compile in the wrong sizes into applications. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Peter Wemm writes: : Personally, I think we place far too much weight on the major number thing. : I think we should be allowed to bump it when the alternative is 'major pain' : to developers. The more I think about this, the more that I think that you are right. I'd go farther and also say that we won't produce a libcompat/libc.so.5.uu or any other "current only" libc versions. : I also object to hacking around like this. I would far prefer that we fix : it properly. We *need* to be able to innovate, especially with locking in : libc in 5.x. I suspect we will have major events like this several more : times before 5.0-R when we add in hooks for KSE or rfork threading. And that's the argument that tipped me over from hacking around it... : http://people.freebsd.org/~peter/stdio.diff3 That looks good. I especially like the coupling of the std* changes to the new major version. I've killed my other build and will try to build this one. : Lets commit that and get on with life. Existing binaries will just keep : on running. : : And if we dont ship libc.so.5, in 5.0-R, then *so what*? I'd like to see a bias against major bumps remain in place, but I think that this change requires one. That is, we still don't generally bump major verions, but are allowed to when the pain is major. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Peter Wemm [EMAIL PROTECTED] writes: : http://people.freebsd.org/~peter/stdio.diff3 : : Except that we bump to 500 instead of 6, and back to 5 before : -RELEASE. I don't think this will work. It is hard to downgrade a major number for libc.so. At least it used to be. : People tracking -CURRENT will end up with a handful of different libc : versions, but they'll avoid the pains we're going through now, and : people upgrading from RELENG_N to RELENG_N+1 will never see a libc : major version increase of more than 1. I don't see why we need only an increment of 1. What does this buy us other than a minor warm fuzzy. OpenBSD bumps libc bunchs of times per release cycle (they are up to libc.so.24 if my sources are current). I've not seen it cause problems there. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:20:51PM -0800, Peter Wemm wrote: It avoids the current problem: - RELENG_4 bumped from 3.0 to 4.0 - this forced a premature 4.0-5.0 bump in -current Actually "NO". I bumped libc.so because Garret said he had changes ready for libc, but was waiting for someone to bump the shared version number. - we missed our chance for major changes. (!!!) In the past, once it was bumped, incompatable changes to libc.so were fair game for -CURRENT. If we had taken -current to 500, we could go to 501, 502, etc as required to stop killing our developers, and prior to entering 5.0-BETA we go back to the next sequentially available major number (be it 5, or 6 if RELENG_4 bumps again). /me wonders if we'll also do something about all the other things we do that kills our developers in -current.. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). Sorry, I meant without the bump. it goes something like this: install -c libc.so.5 /usr/lib install -c libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
Mike Smith wrote: On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hac k. The major number has ALREADY BEEN BUMPED. The "gross hack" is a transitional step necessary for the upgrade path to work, and would be removed after it was no longer required. The "gross hack" can *NEVER* be removed and will live on through 5.0-RELEASE and 5.0-STABLE, because we *continue* to compile in the wrong sizes into applications. Er, no, we wouldn't do this. The "gross hack" ensures binary compatibility with old applications. It's up to you or someone else to fix the source-level implementation of stdin/out/err such that it's not dependant on the size of the new FILE structure. This is the same as, for example, renaming an ioctl to keep an old interface alive. Newly compiled code uses the new interface, not the old one. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 06:21:58PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : Personally, I think we place far too much weight on the major number thing. : I think we should be allowed to bump it when the alternative is 'major pain' : to developers. The more I think about this, the more that I think that you are right. I'd go farther and also say that we won't produce a libcompat/libc.so.5.uu or any other "current only" libc versions. Huh?? We've never made a compat lib of a -current shared lib before. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: I'd like to see a bias against major bumps remain in place, but I think that this change requires one. That is, we still don't generally bump major verions, but are allowed to when the pain is major. We can keep that bias by using temporary three-digit majors in -CURRENT and backing down to a single-digit major right before the first -RELEASE. In this specific case, we'd go from 5 to 500 or 501, then back to 5 right before 5.0-RELEASE; this will still screw people with older-than-feb-10 systems but at least they'll have plenty of time to rebuild their ports and stuff. For 6.0, we'd go straight from 5 to 600 or 601, then down to 6 right before 6.0-RELEASE, and nobody would get screwed. You know it makes sense. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh wrote: In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : Peter Wemm [EMAIL PROTECTED] writes: : http://people.freebsd.org/~peter/stdio.diff3 : : Except that we bump to 500 instead of 6, and back to 5 before : -RELEASE. I don't think this will work. It is hard to downgrade a major number for libc.so. At least it used to be. FYI; this is no longer the case. The numbers in the names mean nothing to ld or ldconfig. The library name is "libc.so.5" as a string with no significance to the naming at all. The versioning is done at link time by the libfoo.so - libfoo.so.N symlink. : People tracking -CURRENT will end up with a handful of different libc : versions, but they'll avoid the pains we're going through now, and : people upgrading from RELENG_N to RELENG_N+1 will never see a libc : major version increase of more than 1. I don't see why we need only an increment of 1. What does this buy us other than a minor warm fuzzy. OpenBSD bumps libc bunchs of times per release cycle (they are up to libc.so.24 if my sources are current). I've not seen it cause problems there. My thoughts exactly. Only do so when it is something big that is going to cause major pain. Minor pain we can live with and is part of -current life. But potential system killers like this sort of thing (my cleanup, not Dan's one) are worth it as long as they are not overdone. Warner Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, 12 Feb 2001, Peter Wemm wrote: Daniel Eischen wrote: Attached is a patch that attempts to work around recent stdio breakage in -current. I've verified it compiles, but won't be able to test it until at least tomorrow. If someone wants to review it and verify it works, I'll commit it. Thanks, __BEGIN_DECLS -extern FILE __sF[]; +extern __old_FILE __sF[]; __END_DECLS -#definestdin (__sF[0]) -#definestdout (__sF[1]) -#definestderr (__sF[2]) +#definestdin ((FILE *)__sF[0]) +#definestdout ((FILE *)__sF[1]) +#definestderr ((FILE *)__sF[2]) The problem with this is that it carries the baggage into 5.0-RELEASE and beyond... No, this hack was to be removed just before 5.0-release, not to stay in throughout the 5.0 cycle. I wish there was a way we could get rid the array entirely and still stay compatable, but I dont see how. :-( A major bump makes it easy. I think there's merit in DES' verion bump to 500, 501, etc. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
* Peter Wemm [EMAIL PROTECTED] [010212 17:28] wrote: Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: Sorry, I made the mistake of looking at this bikeshed and lost my nerve. The patch I was going to commit was: http://people.freebsd.org/~peter/stdio.diff3 .. but this *totally* breaks installworld due to *BAD* brokenness in installworld. No, it doesn't, because you bumped the libc major. Set it to 500 like we discussedm, and commit (or I will, damnit). Sorry, I meant without the bump. it goes something like this: install -c libc.so.5 /usr/lib install -c libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. Er, why isn't /tmp/install.XXX done with static binaries? To fix it, it looks like the best idea is to add the programs in our current /tmp/install.XXX to some target to build them static as well, then install them over... gah, nevermind, signal problems, syscall mess, etc... -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote:
I don't see why we need only an increment of 1. What does this buy us
other than a minor warm fuzzy.
It is hackish.
OpenBSD bumps libc bunchs of times per release cycle (they are up to
libc.so.24 if my sources are current).
They do not always get things right...
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: install -c libc.so.5 /usr/lib install -c libc_pic.a /usr/lib /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. I worked around this (with a fresh, unpatched -CURRENT) by simply running 'make install' manually in /usr/src/usr.bin/ and selected subdirectories of /usr/src/usr.sbin (chown, mtree, zic). The problem I'm facing now is that Somebody[tm] broke locale support, so Perl is spewing error messages about en_US.ISO_8859-1 not being supported. Like Juliana Hatfield says: dumb, dumb, fun. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Peter Wemm writes: : Warner Losh wrote: : significance to the naming at all. The versioning is done at link time : by the libfoo.so - libfoo.so.N symlink. Ah. That's different. If it is that easy, then my objection is withdrawn. I wasted about 3 days trying to untangle a version downgrade, but now that I think about that was in the 2.x days when we had a.out libs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Alfred Perlstein writes: : Er, why isn't /tmp/install.XXX done with static binaries? Because the binaries are host binaries and we have no control over whether they are static or dynmaic. At best we could do is to copy libraries over as well. But I think the major bumps ala Dag's 501 would be better. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 06:31:53PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : If we had taken -current to 500, we could go to 501, 502, etc as : required to stop killing our developers, and prior to entering 5.0-BETA we : go back to the next sequentially available major number (be it 5, or 6 : if RELENG_4 bumps again). I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. In the a.out days, yes. Are you sure you've seen this in the ELF days? What's wrong with shipping with say libc.so.505 in 5.0 and then say libc.so.645 in 6.0? HACK. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
* David O'Brien [EMAIL PROTECTED] [010212 17:35] wrote:
On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote:
I don't see why we need only an increment of 1. What does this buy us
other than a minor warm fuzzy.
It is hackish.
OpenBSD bumps libc bunchs of times per release cycle (they are up to
libc.so.24 if my sources are current).
They do not always get things right...
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
If that's true it doesn't seem like it would be terribly hard to
add a check to the installworld / world target to check for cross
version upgrades and do the magic (or at least print out those
instructions).
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Peter Wemm [EMAIL PROTECTED] writes: at which point any stdio using dynamic binary is hosed, including the *USELESS* copies in /tmp that installworld stashed away. Is it possible to produce a static executable from a dynamic one, provided the right libs are available? In that case, the initial "grab copies of the binaries we need" phase in the installworld target could be changed to "grab staticized copies of the binaries we need". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] "David O'Brien" writes: : What's wrong with shipping with say libc.so.505 in 5.0 and then say : libc.so.645 in 6.0? : : HACK. I think it is an astheitc issue only. It is not a hack, but how ELF shared libarires work. However, since it is easy to move from 505 - 5, there's no need to do it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Alfred Perlstein writes:
: Actually going from libc.so.500 to libc.so.{x500} is easy.
: Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
: libc.so.{x500}, that is the lib version number that will get burned into
: objects. After the first `make world', rm /usr/lib/libc.so.500.
:
: If that's true it doesn't seem like it would be terribly hard to
: add a check to the installworld / world target to check for cross
: version upgrades and do the magic (or at least print out those
: instructions).
Actaully, I think that the libc.so.500 can remain in its place because
of bsd.lib.mk:
...
SHLIB_NAME= lib${LIB}.so.${SHLIB_MAJOR}
SHLIB_LINK?=lib${LIB}.so
...
.if defined(SHLIB_LINK)
@ln -sf ${SHLIB_NAME} ${SHLIB_LINK}
.endif
...
As peter pointed out, it is the libc.so link that makes it the
default.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Warner Losh [EMAIL PROTECTED] writes: I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. What's wrong with shipping with say libc.so.505 in 5.0 and then say libc.so.645 in 6.0? Umm, I dunno, except that it'll look weird, but that's just a matter of taste. Of course, what we really need is "mandatory minor numbers", i.e. minor numbers that are treated as "I need this version", not as "I need this version or newer"... *ducks* *runs* DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. Umm, never mind this gross hack; as Peter pointed out, it's not a problem. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
"David O'Brien" wrote:
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
There is no need to rm /usr/lib/libc.so.500 - once a new libc is installed,
and the symlink points to it, then libc.so.500 will *never* get linked
against.
Remember, the number in the filename means *nothing*. There is no less
than or greater than relationship. We could use 100 digit random numbers
for each bump if we liked. We could use dates, current time_t, anything.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Dag-Erling Smorgrav writes: : When we back down to 5, we add magic to the Makefiles to move : libc.so.5?? to /usr/lib/compat - that way they're only used when : needed at runtime, not for linking new programs. No need. I misunderstood how ELF libraries work. The libc.so link is what makes it default. Peter set me right on this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:44:31PM -0800, Peter Wemm wrote: We could use dates, current time_t, anything. /usr/lib/libc.so.whistler (Sorry, working for MS I couldn't resist :-) -- Jos Backus _/ _/_/_/"Modularity is not a hack." _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 02:42:15AM +0100, Dag-Erling Smorgrav wrote: Warner Losh [EMAIL PROTECTED] writes: I've had problems in the past going backwards on major versions of shared libaries. The major problem is that if I have binaries that refer to libc.so.503, then when the major number is reverted back to 5, it is a nop because ld will use libc.so.503 for new binaries. When we back down to 5, we add magic to the Makefiles to move libc.so.5?? to /usr/lib/compat - that way they're only used when needed at runtime, not for linking new programs. NO! No magic. No polution. If you are using -current when libc.so.5003 exists, you should be able to handle the `mv' yourself manually. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 05:44:53PM -0800, Peter Wemm wrote:
"David O'Brien" wrote:
Actually going from libc.so.500 to libc.so.{x500} is easy.
Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
libc.so.{x500}, that is the lib version number that will get burned into
objects. After the first `make world', rm /usr/lib/libc.so.500.
There is no need to rm /usr/lib/libc.so.500 - once a new libc is installed,
The need is a clean, uncluttered /usr/lib/
and the symlink points to it, then libc.so.500 will *never* get linked
against.
Yes, I know. :-) But it is true that I didn't state that to make sure
others did.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Tue, Feb 13, 2001 at 02:29:54AM +0100, Dag-Erling Smorgrav wrote: We can keep that bias by using temporary three-digit majors in -CURRENT and backing down to a single-digit major right before the first -RELEASE. In this specific case, we'd go from 5 to 500 or 501, Please read your -arch mail to discuss this issue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Matt Dillon writes: :Would compiling the tools -static help? No. The tools that are deployed today are not static, and it is those that we copy. It will also delay discovery of the incompatibility until after the installworld is complete. I'm not sure that would be a feature :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
:In message [EMAIL PROTECTED] Matt Dillon writes: ::Would compiling the tools -static help? : :No. The tools that are deployed today are not static, and it is those :that we copy. It will also delay discovery of the incompatibility :until after the installworld is complete. I'm not sure that would be :a feature :-) : :Warner How about a temporary LD_LIBRARY path to run the tools, pointing into /usr/obj somewhere? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
In message [EMAIL PROTECTED] Matt Dillon writes: : How about a temporary LD_LIBRARY path to run the tools, pointing into : /usr/obj somewhere? We'd have to copy the current libraries to that location, or at least into /tmp. These are *HOST* binaries after all. And the hacking to do that might be, u, difficult at best. We have an invariant in the system right now that one libX.so.N is binary compatible with all other libX.so.N (or at the very least the new one installed is upwardly compatible with the old one). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
