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
On Mon, Feb 12, 2001 at 01:57:49PM +0700, John Indra wrote:
BTW, today I saw post from John Baldwin to remove device random from the
kernel config. Then, other post replied that this is a good thing, mpg123
playing went a lot better for him, well at least, that's what he said.
If this is
Peter Wemm wrote:
Argh... We are in far worse shape than I thought...
It seems that the "temporary" copies of the host tools like install etc
are getting clobbered by the non-version-bump of libc.
It is sheer luck that only the sed thing died before. It could have been
a lot worse.
Doug Barton wrote:
Peter Wemm wrote:
Argh... We are in far worse shape than I thought...
It seems that the "temporary" copies of the host tools like install etc
are getting clobbered by the non-version-bump of libc.
It is sheer luck that only the sed thing died before. It could
Please help me to overcome this. My world is totally broken. ps and top
don't work. fetchmail, and other program seems to lost STDOUT. After failed
installworld, I reboot my machine, blew away /usr/obj and make clean in
/usr/src. Now when I want to rebuild the world, make just don't want to do
On Mon, Feb 12, 2001 at 04:19:57PM +0700, John Indra wrote:
Please help me to overcome this. My world is totally broken. ps and top
don't work. fetchmail, and other program seems to lost STDOUT. After failed
installworld, I reboot my machine, blew away /usr/obj and make clean in
/usr/src. Now
On Mon, 12 Feb 2001 16:19:57 +0700, John Indra wrote:
Please help me to overcome this. My world is totally broken. ps and top
don't work. fetchmail, and other program seems to lost STDOUT. After failed
installworld, I reboot my machine, blew away /usr/obj and make clean in
/usr/src. Now
+---[ Sheldon Hearn ]--
|
| Seriously, now's not the time to run CURRENT "for fun".
Well if now isn't when is? It's been pretty boring up until now :-)
--
Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton
The Internet (Aust) Pty Ltd |
On Sun, 11 Feb 2001, Peter Wemm wrote:
Matt Dillon wrote:
:
: This is a major change to libc. The library maj must be bumped if you
: intend to change the sizeof(FILE), or every single third party applicatio
n
: that uses stdio will break.
:
:
I have been trying to talk to a laserprinter but whenever I try
cat file /dev/lpt0
the system panics
(if the printer is online)
Feb 12 02:36:56 jules /boot/kernel/kernel: kernel trap 9 with interrupts disable
d
Feb 12 02:36:56 jules /boot/kernel/kernel:
Feb 12 02:36:56 jules
On Mon, Feb 12, 2001 at 03:49:04AM -0800, Julian Elischer wrote:
I'm going to try absolutely current now but have seen nothing about such a
problem
in the last 2 weeks in the lists. Is everyone using ethernet attached printers?
This system prints fine for me:
FreeBSD cicely8.cicely.de
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
===
Julian Elischer wrote:
I have been trying to talk to a laserprinter but whenever I try
cat file /dev/lpt0
the system panics
(if the printer is online)
Feb 12 02:36:56 jules /boot/kernel/kernel: kernel trap 9 with interrupts disable
d
Feb 12 02:36:56 jules /boot/kernel/kernel:
Feb 12
Jake Burkholder [EMAIL PROTECTED] writes:
As I mentioned in the commit message, this changes the size and layout
of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
I thought the whole point with kinfo_proc was to avoid this kind of
situation...
DES
--
Dag-Erling
../../dev/ata/ata-all.c:96: elements of array `ata_ids' have incomplete type
../../dev/ata/ata-all.c:97: warning: excess elements in struct initializer
../../dev/ata/ata-all.c:97: warning: (near initialization for `ata_ids[0]')
../../dev/ata/ata-all.c:97: warning: excess elements in struct
With a buildworld from two hours ago, i got the following message while
playing an MP3:
pcm1: play interrupt timeout, channel dead
After which the player process hangs. Interrupting (CTRL-C) and restarting
the player works. It happened only once so far, so I can't tell much more.
--
Theo van
It seems Michael Harnois wrote:
Fixed.
-Sren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On 12 Feb, Julian Elischer wrote:
the system panics
(if the printer is online)
Same here.
Feb 12 02:36:56 jules /boot/kernel/kernel: kernel trap 9 with interrupts disable
d
Feb 12 02:36:56 jules /boot/kernel/kernel:
Feb 12 02:36:56 jules /boot/kernel/kernel:
Feb 12 02:36:56 jules
On 12 Feb 2001, Dag-Erling Smorgrav wrote:
Jake Burkholder [EMAIL PROTECTED] writes:
As I mentioned in the commit message, this changes the size and layout
of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
I thought the whole point with kinfo_proc was to avoid
On 12 Feb, Michael Harnois wrote:
../../dev/ata/ata-all.c:96: elements of array `ata_ids' have incomplete type
[...]
Workaround (compile in progress): remove the #if / #endif pair
which tests "NISA 0"
Bye,
Alexander.
--
Where do you think you're going today?
But I remember some posts about a lpt panic some days ago. I tried to
compile a new kernel because I think this is resolved, but I have to
solve some problems with my system at the moment.
My -CURRENT used to crash every time lpr has been used but the panic went away
when John Baldwin
> -Original Message-
> From: Phil Simms
> Sent: Tuesday, February 9, 2001 4:14 PM
> To: Barry Sanders
> Cc: Steve Hartman, Rhonda Smalley, Jimmy Ward, Big Dave, Dean
Fletcher
> Subject: FW: -- 3 New Hilarious Video Clips and some more jokes.
> Joke Lovers,
>
Hi,
I'm not sure whether it's related to ata driver, but starting from several days
ago (my previous kernel was from 30 January) my kernel panices on every more or
less active ad0 usage (for example, dd if=/dev/ad0 of=/dev/null kills it
perfectly). The system in question is Toshiba Satellite Pro
It seems Maxim Sobolev wrote:
[Charset koi8-r unsupported, filtering to ASCII...]
Hi,
I'm not sure whether it's related to ata driver, but starting from several days
ago (my previous kernel was from 30 January) my kernel panices on every more or
less active ad0 usage (for example, dd
Soren Schmidt wrote:
It seems Maxim Sobolev wrote:
[Charset koi8-r unsupported, filtering to ASCII...]
Hi,
I'm not sure whether it's related to ata driver, but starting from several days
ago (my previous kernel was from 30 January) my kernel panices on every more or
less active ad0
"Alexander N. Kabaev" wrote:
But I remember some posts about a lpt panic some days ago. I tried to
compile a new kernel because I think this is resolved, but I have to
solve some problems with my system at the moment.
My -CURRENT used to crash every time lpr has been used but the panic
On Sun, 11 Feb 2001 16:51:29 -0800, Kris Kennaway [EMAIL PROTECTED] said:
The major number has already been bumped, I thought. If this is true
then we've only broken compatibility with older versions of -current
after the version number was bumped but before this change, right?
However, this
Bruce Evans [EMAIL PROTECTED] writes:
On Fri, 9 Feb 2001, John W. De Boskey wrote:
I've been using the disklabel.c patch which allows easier
configuration by being able to specify a new disklabel of
the form:
I'd like to commit these if no one sees any major problems
with them.
These
At 11:47 AM 2/12/2001 -0500, Garrett Wollman wrote:
On Sun, 11 Feb 2001 16:51:29 -0800, Kris Kennaway [EMAIL PROTECTED] said:
The major number has already been bumped, I thought. If this is true
then we've only broken compatibility with older versions of -current
after the version number was
In message [EMAIL PROTECTED] John Indra writes:
: Is -CURRENT in bad shape?
Yes. Life sucks in current - current upgrade land.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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.
"Justin T. Gibbs" [EMAIL PROTECTED] wrote:
It is not necessarily sufficient since the media may be changed after
open on certain types of devices that don't have a media lock.
But don't you risk a panic if you do that?
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
THAMES
"Justin T. Gibbs" [EMAIL PROTECTED] wrote:
It is not necessarily sufficient since the media may be changed after
open on certain types of devices that don't have a media lock.
But don't you risk a panic if you do that?
By pulling the media out and flipping off the hardware write protect?
Even
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
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
:
Hey this may be a spot where the FILE change is felt - my installworld bombed
in the perl/library install with a sed error.
I went to usr.bin/sed and did a make install to put in the new sed and then
make installworld completed ok.
FYI
Mark Hittinger
Earthlink
[EMAIL PROTECTED]
To
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
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.
On Mon, Feb 12, 2001 at 01:20:36PM +0700, John Indra wrote:
Now I'm in the middle of make -j10 buildworld. Is -CURRENT in bad shape?
First thing to do when you're having problems building world is to STOP
using -j. If you aren't hitting a race condition, you won't get able to
figure out what
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
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
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
Hello,
I have been playing with PnP and device hints. Using a device.hints
with hints for all the drivers, some "PNPxxx can't assing resources"
messages showed up at boot. Then I removed hints one by one, until
I ended up with these:
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
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
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
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.
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
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
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
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.
:
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
:
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
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
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,
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
On Sun, Feb 11, 2001 at 04:44:21PM -0800, Matt Dillon wrote:
This is a major change to libc. The library maj must be bumped if you
intend to change the sizeof(FILE), or every single third party application
that uses stdio will break.
For -stable this would be true. We've already
On Mon, Feb 12, 2001 at 11:47:04AM -0500, Garrett Wollman wrote:
However, this may turn out to be so painful that we need to bump it
again.
That is (1) against Handbook documented policy, (2) too hackish (we
aren't Linux).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
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
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,
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
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
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
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
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
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.
:
:
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
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
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,
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.
--
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
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
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
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
On Sun, Jan 28, 2001 at 01:27:04AM -0800, Julian Elischer wrote:
This is the single most flagrant lack of cooperation I have experienced
while working with the FreeBSD Project. I'm truly dumbfounded.
It's not a lack of co-operation.. it's a lack of communication. I didn't
see an any
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
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
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
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
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
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
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
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
* 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
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).
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
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
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
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
* 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
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
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 -
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
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
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
"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.
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
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."
_/ _/ _/
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
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
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
1 - 100 of 111 matches
Mail list logo
