-On [20001102 05:30], Garrett Wollman ([EMAIL PROTECTED]) wrote:
On Wed, 1 Nov 2000 14:43:55 -0800, "David O'Brien" [EMAIL PROTECTED] said:
Any reason to not get [libc ABI changes] in -current now and make
the bump?
Mostly because they're too small to be worth the pain. I'm waiting
for
On Sun, 5 Nov 2000 13:51:09 +0100, Jeroen Ruigrok van der Werven
[EMAIL PROTECTED] said:
I also gather it has to do with the Austin project Garrett?
Yes and no. The errors have been there since the beginning of time,
but I actually noticed them doing review of our implementation wrt the
new
John Polstra wrote:
In article [EMAIL PROTECTED],
Maxim Sobolev [EMAIL PROTECTED] wrote:
John Polstra wrote:
Overall I would lean toward putting the hack into pthread_mutex_lock.
Comments?
Huh, why we can't just bump libc_r version number and put older (buggy) version
into
In article [EMAIL PROTECTED], Maxim Sobolev
[EMAIL PROTECTED] wrote:
John Polstra wrote:
The bug wasn't in libc_r -- it was in libgcc_r. That's a
static library, so it doesn't have a version number. And it is
statically linked into old executables. Nothing we do to libgcc_r
will help
In article [EMAIL PROTECTED],
Max Khon [EMAIL PROTECTED] wrote:
do we still need uthread_autoinit.cc?
It still might be needed by old executables. Anyway I don't see a
good reason to get rid of it.
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
Hi,
I'm not sure what exactly caused this behaviour (I can guess two potential
victims: O'Brien's changes in crt stuff and recent Polstra's changes in
libgcc_r), but it seems that some programs built on the previous -current from
27 October immediately segfault when I'm trying to run then on
On Wed, Nov 01, 2000 at 19:17:26 +0200, Maxim Sobolev wrote:
Hi,
I'm not sure what exactly caused this behaviour (I can guess two potential
victims: O'Brien's changes in crt stuff and recent Polstra's changes in
libgcc_r), but it seems that some programs built on the previous -current from
On Wed, 1 Nov 2000, John Polstra wrote:
In article [EMAIL PROTECTED],
Maxim Sobolev [EMAIL PROTECTED] wrote:
I'm not sure what exactly caused this behaviour (I can guess two potential
victims: O'Brien's changes in crt stuff and recent Polstra's changes in
libgcc_r), but it seems that
In article [EMAIL PROTECTED],
Daniel Eischen [EMAIL PROTECTED] wrote:
Overall I would lean toward putting the hack into pthread_mutex_lock.
Comments?
If that's the lesser evil, then I guess it's OK with me.
Thanks for replying so quickly. I'll test this to make sure it
really works,
John Polstra wrote:
In article [EMAIL PROTECTED],
Maxim Sobolev [EMAIL PROTECTED] wrote:
I'm not sure what exactly caused this behaviour (I can guess two potential
victims: O'Brien's changes in crt stuff and recent Polstra's changes in
libgcc_r), but it seems that some programs built
In article [EMAIL PROTECTED],
Maxim Sobolev [EMAIL PROTECTED] wrote:
John Polstra wrote:
Overall I would lean toward putting the hack into pthread_mutex_lock.
Comments?
Huh, why we can't just bump libc_r version number and put older (buggy) version into
lib/compat as usually? This would
On Wed, 01 Nov 2000 21:09:12 +0200, Maxim Sobolev [EMAIL PROTECTED] said:
Huh, why we can't just bump libc_r version number and put older (buggy) version into
lib/compat as usually? This would not require any ugly hacks at all.
If you want to bump libc_r's version, we should do it to libc as
On Wed, Nov 01, 2000 at 03:19:36PM -0500, Garrett Wollman wrote:
If you want to bump libc_r's version, we should do it to libc as well,
and in that case there are a large number of ABI fixes that I have
queued up which should be done at the same time.
Any reason to not get them in -current
On Wed, 1 Nov 2000 14:43:55 -0800, "David O'Brien" [EMAIL PROTECTED] said:
Any reason to not get [libc ABI changes] in -current now and make
the bump?
Mostly because they're too small to be worth the pain. I'm waiting
for something more significant that I can piggy-back on.
-GAWollman
--
hi, there!
On Wed, 1 Nov 2000, John Polstra wrote:
Here are all the random facts which, when put together, explain what
is going on.
Your old application was (like all -pthread programs) linked
with "/usr/lib/libgcc_r.a". That library contains a function
"__register_frame_info" which
In article [EMAIL PROTECTED],
Maxim Sobolev [EMAIL PROTECTED] wrote:
I'm not sure what exactly caused this behaviour (I can guess two potential
victims: O'Brien's changes in crt stuff and recent Polstra's changes in
libgcc_r), but it seems that some programs built on the previous -current
16 matches
Mail list logo
