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
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
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
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
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
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
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]
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
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
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
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
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
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
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,
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
-CURRENT is bad for me...
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
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 ===
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.
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
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 :
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
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.
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
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
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
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
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
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.
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
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
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
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. :
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 :
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
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
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,
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
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
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,
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
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
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
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
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. : :
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
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
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,
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. --
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
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
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
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
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
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 -
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
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
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
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.
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
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." _/ _/ _/
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
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
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
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
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
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
