om /usr/include/linux/sched.h:23,
> from /usr/include/linux/module.h:10,
> from kfusd.c:83:
What are you compiling that needs in userspace? In
general this header is not useful for applications.
--
Daniel Jacobowitz
gt; Is it normal?
>
> Many thanks for your help, and sorry for the disturb if it is
> not a libc6 issue.
Do you not have /usr/include/wchar.h? Suggest you reinstall libc6-dev
in that case.
--
Daniel Jacobowitz
an adequate process for handling bugs in
their tests, that's not glibc's problem. Even SPEC can manage this...
--
Daniel Jacobowitz
On Mon, Feb 14, 2005 at 12:05:09PM -0800, Kevin A. Burton wrote:
> 1. Is there an ETA for a release of glibc 2.3.4?
After sarge is released. We're trying not to upgrade glibc in unstable
unnecessarily.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
gt;
> Thread race conditions seems like a big issue :-/
Sorry, but building glibc is not for the faint of heart. If you
download the source package, you may be able to add patches to
debian/patches/00series and see if that works.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCR
; (because there can't be
> a NULL group), then I think that returning NULL is the correct behaviour.
No, it's not at all the same thing. None of the library functions are
required to be robust against NULL input; there's no point making an
exception for getgrnam wit
his can be fixed quickly. As a temporary
> workaround, just doing:
>
> # mv /lib/tls/ld-2.3.2.so /lib/
>
> should cure the problem.
ISTR that Red Hat has a patch for this in their glibc RPMs already.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROT
> Also, the bug says that is fixed upstream. If, as Daniel says in
> > #207872, the patch was rejected upstream, you should remove the tag.
>
> I guess upstream did the another way to fix this issue. Daniel, did
> you know about it more?
No, sorry - I don't kn
t break other applications too.
Sounds like a bug in valgrind. dlerror's result is only guaranteed
until the next call to a dl* function.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d
interface, do not use them.
You do have TLS, but tls.h is not and will never be an installed
header; ditto the others.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
werpc64 target.
If this is FP related, I think the relevant patch is:
2005-02-22 James E Wilson <[EMAIL PROTECTED]>
* toplev.c (backend_init): Don't call init_adjust_machine_modes here.
(do_compile): Do call it here.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
On Tue, Mar 15, 2005 at 08:46:01PM +0100, Bastian Blank wrote:
> On Tue, Mar 15, 2005 at 02:19:32PM -0500, Daniel Jacobowitz wrote:
> > If this is FP related, I think the relevant patch is:
>
> What do you mean with FP?
Floating point.
>
> > 2005-02-22 James E W
0e0 RW 0x4
> STACK 0x00 0x 0x 0x0 0x0 RWE 0x4
Why is this a bug in glibc 2.3.4? Why is it even related to glibc
2.3.4? Those libraries are not part of glibc.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/story41890.html
> and be getting many complaints from PaX users because their system is
> now unusable.
Guess what? Debian does not support PaX.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
with fixing problems than
> being an asshole that I can talk to about this problem?
If you aren't interested in being civil, I'm certainly not interested
in helping you. You haven't given a convincing reason for glibc to
change, only for the applications to be fixed. Have y
v) is only long and IMHO both should
> match.
>
> The same applies to some other 64 bit types defined as long long.
Can you explain why you want to make this change? Long long is still
correct for these types, and consistent within the kernel. The kernel
types don't need to
On Tue, Mar 29, 2005 at 05:30:00PM +0200, André Wöbbeking wrote:
> On Tuesday 29 March 2005 17:01, Daniel Jacobowitz wrote:
>
> > Can you explain why you want to make this change? Long long is still
> > correct for these types, and consistent within the kernel. The
> >
thers may be added later:
> - /etc/ld.so.capabilities
> - environment variable: LD_CAPABILITIES
No way. An additional data source with a grammar that needs to be
parsed at every application's startup?
What are you trying to accomplish with this proposal?
--
Daniel Jacobowitz
C
On Fri, Apr 01, 2005 at 07:11:04PM +0200, Bastian Blank wrote:
> On Fri, Apr 01, 2005 at 11:35:49AM -0500, Daniel Jacobowitz wrote:
> > You need to be a lot more specific than that. It works. I use it every
> > day.
>
> So? Than please show me how to ask it to enable s
On Fri, Apr 01, 2005 at 08:57:56PM +0200, Bastian Blank wrote:
> On Fri, Apr 01, 2005 at 01:27:26PM -0500, Daniel Jacobowitz wrote:
> > On Fri, Apr 01, 2005 at 07:11:04PM +0200, Bastian Blank wrote:
> > > So? Than please show me how to ask it to enable sse optimized libs and
On Fri, Apr 01, 2005 at 10:40:51PM +0200, Bastian Blank wrote:
> On Fri, Apr 01, 2005 at 03:29:06PM -0500, Daniel Jacobowitz wrote:
> > On Fri, Apr 01, 2005 at 08:57:56PM +0200, Bastian Blank wrote:
> > > On Fri, Apr 01, 2005 at 01:27:26PM -0500, Daniel Jacobowitz wrote:
>
VATE, and
nothing needs to be compatible with GLIBC_PRIVATE outside the glibc
packages. I don't think it will actually affect GLIBC_PRIVATE, either,
but I'd have to play around with it to make sure.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t;, it should not make a
> problem.
>
> I'm rathar a bit nervous of supporting this special situation (ex:
> distro compatibility and so on) because -21 should be the last call
> for sarge stuff...
Could you explain what it is you're worried about? We absolutely
ought to have
libc6 (<= 2.3.2.ds1-21), libc6.1 (<= 2.3.2.ds1-21)
I think that'll work... but make sure apt can cope.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
to
> explain, it lacks the version GLIBC_2.3.3 symbol (it does have 2.3.2
> and 2.3.4 and libc6 itself has them all).
>
> This prevents running some binaries built on other distros like fedora
And what GLIBC_2.3.3 symbols does Fedora have?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To
On Sat, May 07, 2005 at 02:06:15PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2005-05-06 at 23:09 -0400, Daniel Jacobowitz wrote:
> > On Sat, May 07, 2005 at 12:42:02PM +1000, Benjamin Herrenschmidt wrote:
> > > Package: libc6
> > > Version: 2.3
ing 3.4 nowadays? Smart choice I guess.
I think that's right but I haven't looked at the packaging in about a
year now.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sat, May 07, 2005 at 04:20:16PM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2005-05-07 at 01:37 -0400, Daniel Jacobowitz wrote:
>
> > /usr/bin/gcc still doesn't have PPC TLS support. Does glibc default to
> > using 3.4 nowadays? Smart choice I guess.
> >
&
his problems seems to be widely spread, but I have only
> seen one reasonable solution: A patch by Daniel Jacobowitz from MontaVista
> software. His explanations of what his patch does are detailed and
> well-founded. So why is this patch not included in the debian glibc package
> (spea
: Dpatch author: Daniel Jacobowitz <[EMAIL PROTECTED]>
+# DP: Patch author: Daniel Jacobowitz, Roland McGrath, Jakub Jelinek
+# DP: Upstream status: In CVS
+# DP: Status Details: Backported
+# DP: Date: 2005-05-08
+
+PATCHLEVEL=1
+
+if [ $# -ne 2 ]; then
+echo >&2 "`basename $0`:
On Sun, May 08, 2005 at 01:35:27PM -0400, Daniel Jacobowitz wrote:
> At the bottom of this message is a diff against glibc 2.3.2.ds1-21 which
> fixes merged bugs 207872, 210840, 274852, and 276384. I spoke with Colin on
> IRC and he seemed amenable to this as a last-minute fix for sar
RSYM)] != NULL);
#else
The problem is not going to be anywhere near there. That is a check on
the ld.so binary, which works elsewhere. Probably your mmap is busted.
I do not see anything that would cause this in -21 either.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I don't think we could even rebuild glibc -21. The hppa
machines are configured with ulimit -s set to 1GB. This makes
LinuxThreads use 1GB thread stacks. Which is, um, pretty bad.
Anyone know why this was done?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL
On Fri, May 13, 2005 at 05:38:33PM +0100, Matthew Wilcox wrote:
> On Fri, May 13, 2005 at 12:17:18PM -0400, Daniel Jacobowitz wrote:
> > 27319 mmap(NULL, 1073741824, PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0
> > 27319 <... mmap resumed>
On Fri, May 13, 2005 at 12:17:18PM -0400, Daniel Jacobowitz wrote:
> Hi debian-hppa (and -admin),
>
> I tried building glibc manually on paer. It didn't work any better.
> It turns out that ex1 hanging was not the first problem in the build;
> make crashes building
On Fri, May 13, 2005 at 06:45:35PM +0100, Matthew Wilcox wrote:
> On Fri, May 13, 2005 at 01:21:48PM -0400, Daniel Jacobowitz wrote:
> > On Fri, May 13, 2005 at 05:38:33PM +0100, Matthew Wilcox wrote:
> > > On Fri, May 13, 2005 at 12:17:18PM -0400, Daniel Jacobowitz wrote:
>
y uptime and did not have this problem building glibc a month
ago for -21.
If you want to change glibc at this point, discuss with Carlos; I can't
take care of it. Just getting -22 built has taken most of my free time
for this week.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE
t;
> The disk wasn't full (6Gb available).
What kind of system is this? Am I reading you right to say that you
unpacked the same -22 debs and then things worked again?
If you dare, could you try to reproduce the problem?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE,
On Wed, May 18, 2005 at 10:42:08AM +1000, Hamish Moffatt wrote:
> On Tue, May 17, 2005 at 11:34:58AM -0400, Daniel Jacobowitz wrote:
> > On Wed, May 18, 2005 at 01:09:16AM +1000, Hamish Moffatt wrote:
> > > Package: libc6
> > > Version: 2.3.2.ds1-22
> > > Se
On Wed, May 18, 2005 at 10:51:09AM +1000, Hamish Moffatt wrote:
> On Wed, May 18, 2005 at 10:42:08AM +1000, Hamish Moffatt wrote:
> > On Tue, May 17, 2005 at 11:34:58AM -0400, Daniel Jacobowitz wrote:
> > > If you dare, could you try to reproduce the problem?
> >
> >
from /usr/include/linux/ext2_fs_sb.h:20,
> from /usr/include/linux/ext2_fs.h:20,
> from test.c:1:
Don't do that then.
e2fsprogs supplies a version of this header which is suitable for
userspace. Use that instead.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSC
ls
/usr/share/locale/en/LC_MESSAGES | wc
3 3 29
Normally, you get the final fallback, which is C. Like so:
[EMAIL PROTECTED]:~% LANG=en_US LANGUAGE=en_US:de_DE:en_US cat -h
cat: Ungültige Option -- h
,,cat --help" gibt weitere Informationen.
[EMAIL PROTECTED]:~% LA
D]:~% LANG=en_US LC_ALL=en_US LANGUAGE=en_US:de_DE:en_US cat -h
cat: Ungültige Option -- h
,,cat --help" gibt weitere Informationen.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nset)
I would have expected LANGUAGE to set LC_MESSAGES, and it doesn't.
That's what needs to be documented, since it is a deliberate choice.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sat, Jun 04, 2005 at 10:43:41PM +0200, Denis Barbier wrote:
> On Fri, Jun 03, 2005 at 04:56:18PM -0400, Daniel Jacobowitz wrote:
> > Except that the problem is that (if everything but LANGUAGE is unset)
> > I would have expected LANGUAGE to set LC_MESSAGES, and it doesn't.
>
> Yes, LANGUAGE is only checked to select message catalogs, nothing else.
This is also not documented. And it's surprising - to me anyway. The
documentation presents it as an extension to LANG.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
X.
Yes, I realize all this now. The bug is that I can't figure _any_ of
this out from the manual.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gt;
> http://www.linux.lk/~anuradha/
> http://www.gnu.org/philosophy/no-word-attachments.html
>
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
trdup; it's a (very
common) extension. -std=c99 requests strict C99 conformance.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nce should affect that header. I think
> it is a bug.
In addition to what Lars wrote, strict compliance affects time.h
because is specified in the ISO C99 standard: it provides
time_t, struct tm, clock(), mktime(), et cetera.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email
ve.
This package was meant to be transitional, anyway. In your opinion,
should we fix it, or should we remove it and make the affected library
packages build biarch on i386? I believe that's just glibc, ncurses, and
libbz2 (plus linux-kernel-headers). Ncurses and glibc already support
ror 1
> > make[1]: Leaving directory `/tmp/buildd/kbd-chooser-1.15'
> > make: *** [build-stamp] Error 2
Where is being included from? Is it necessary?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Jul 14, 2005 at 09:31:24PM -0700, Matt Kraai wrote:
> On Thu, Jul 14, 2005 at 02:42:23PM -0400, Daniel Jacobowitz wrote:
> > On Mon, Jul 11, 2005 at 09:47:11AM -0700, Matt Kraai wrote:
> > > Package: libc6-dev
> > > Version: 2.3.2.ds1-22
> > > Severi
On Fri, Jul 15, 2005 at 08:37:20AM -0700, Matt Kraai wrote:
> loadkeys.y should inline the macro definitions that it needs from
> instead of removing the include from
> ? loadkeys.y appears to use the following macros:
Yes, in general this is correct.
--
Daniel Jacobowitz
CodeSour
variant of these. Again, because they are so large.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Jul 24, 2005 at 04:27:47PM +0200, Kurt Roeckx wrote:
> And I was wondering if anybody knows if this is fixed in
> the experimental version too. I'll try and tests this
> later.
Yes, this should be fixed in experimental.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSU
ost of the binary
> packages, such as -dbg) takes over half an hour. Is there any way of
> making this faster without buying faster hardware?
Not really. I do a lot of things by running make in object
directories, instead. I also work on multiple bugs at a time and build
them together.
--
eniencing people. What's really
blocking us from uploading 2.3.5 now, and working in unstable?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t!
> During debconf5, I could devote my all time to Debian and FOSS, but
> it's hard to do so here unfortunatelly.
Yes. Right now, you're the only person who knows how the conversion to
2.3.5 is going; I don't want to get in the way. Afterwards, I hope
that the rest of
ase this will
break TLS for dynamic binaries, too.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sing something, but what loads debian/locales-depver?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
s or defines.
> >
> > What is the enum needed for?
>
> enums are generally a good think and underestimated. They for example
> allow the compiler to check switch() statements if all possible input is
> handled there.
Not generally relevant for unnamed enums.
--
Daniel Jaco
These errors indicate bugs in those libraries (pam_ldap, pam_krb5).
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
an you
> confirm? I'll open a bug report about this.
Please try the version currently in unstable, instead.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wait for them to get fixed, or go ahead and install the
> newer glibc. my gut tells me i should stick to the former route, and
> wait.
Try filing bugs on the affected modules?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "un
y specific error is applyed to Apache or to libc6 (so
> sorry if I am filling this bug against libc6 and not Apache).
>
> I have installed the package libc6-i686 too, if this helps.
Are libc6-i686 and libc6 the same version? Have they been upgraded
since you last restarted apache?
se let us know if restarting apache fixes the problem.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Aug 08, 2005 at 10:46:40PM +0900, GOTO Masanori wrote:
> At Sun, 7 Aug 2005 10:43:43 -0400,
> Daniel Jacobowitz wrote:
> > Are libc6-i686 and libc6 the same version? Have they been upgraded
> > since you last restarted apache?
>
> Note that during glibc 2.3.5-
her,
the EFAULT is the problem. At a guess, this is the case that we expect
ENOMEM for in dl-execstack.c, but 2.4.18 is returning EFAULT instead
for the same case.
This whole thing looks a bit fishy, since it could be making random
other bits writable... but that won't happen in recent ke
ween these two
> > versions.
>
> Does this problem already identify the culprit (thus nss), and is
> restaring services all ok?
In my opinion, yes, but I haven't tested it.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
- in
which case this is, simply, wrong - or else it doesn't and whatever is
causing it to be tagged as needing one should be fixed. IIRC it is
usually a matter of annotating assembly files in some way.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
ost platforms. On ia32
it will if you've got amd64-libs-dev installed. Sparc does this in
l-k-h already.
You're right that we should do the same for ia32/amd64 and ppc/ppc64 as
we do for sparc.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
other PAM module, similar to another reported bug, but restarting
> the software doesn't help.
How did you get a libpthread.so.0 that does not match your ld.so?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> glibc version in unstable?
>
> glibc in sid doesn't seem to provide NTPL yet on ppc.
That's correct. It's now fixable, but not yet fixed.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
have resources to resolve tough and rare
> problems but at least we try to keep list of known problems. Look at
> http://bugs.debian.org/hurd
That's not relevant. Has anyone reproduced this bug since then? If
not, Nathanael's right; it should be closed. The code has c
On Fri, Aug 12, 2005 at 08:32:59PM +0200, Matthias Klose wrote:
> Daniel Jacobowitz writes:
> > On Fri, Aug 12, 2005 at 03:55:52PM +0200, Matthias Klose wrote:
> > Content-Description: message body text
> > > Package: ncurses
> > >
> > > Trying to build
ink to get it to work we'd need to install the x86_64 headers
instead of the i386 ones.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
owever; I suspect that Simon has somehow managed to
get the old libdl with the new ld.so. Probably there is a stray copy
in /usr or some directory in /etc/ld.so.conf.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Aug 15, 2005 at 01:48:36PM +0900, GOTO Masanori wrote:
> At Mon, 8 Aug 2005 10:09:38 -0400,
> Daniel Jacobowitz wrote:
> > > 08:47 mprotect(0xb000, 4096,
> > > PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid
> > > argument)
> &
eleases. Is it really worth trying
> to maintain compatibility with that kernel?
>
> AIUI, glibc 2.3.5 is currently compatible with the sarge and etch 2.4
> kernels. That seems sufficient to me; why not just mark glibc in the
> preinst as being incompatible with old 2.4 kernels?
228931 /var/db/nscd/passwd
[Is /var/db even FHS?]
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What's the point? Almost 100% of the time, if we need
to complain about a kernel version, things are going to break so badly
that the #!/bin/sh at the top of the script isn't going to work. So
you're adding more work to the boot process that will pretty much never
do any good...
--
On Fri, Aug 26, 2005 at 09:47:51AM +0900, GOTO Masanori wrote:
> At Thu, 25 Aug 2005 17:57:00 -0400,
> Daniel Jacobowitz wrote:
> > On Thu, Aug 25, 2005 at 05:53:05PM +0200, Zlatko Calusic wrote:
> > > GOTO Masanori <[EMAIL PROTECTED]> writes:
> > >
> &
have libc6.preinst scripts that checks kernel
> version? Don't you use your own compiled kernel or old kernel?
> /etc/init.d/glibc.sh just extends it to each kernel boot time. It's
> simple, and useful for not only libc6 installation time but also each
> boot time.
It's
E
Note: this means that LC_ALL is already set in your environment.
LC_ALL is documented to override all the other environment variables.
So it's completely expected that changing LC_NUMERIC has no effect.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.3.5-5
Severity: normal
/etc/init.d/glibc.sh uses dpkg --compare-versions extensively.
[EMAIL PROTECTED]:~% which dpkg
/usr/bin/dpkg
Init scripts, at least this early, can't use /usr. It isn't mounted yet!
-- System Information:
Debian Release: testing/unstable
APT p
ocess /usr/bin/dpkg returned an error code (1)
>
> Attempting to run ldconfig yields the following output:
>
> dmcnet:~# ldconfig
> Illegal instruction
>
> I am using kernel 2.2.20
This is why it's nice to use reportbug... what platform is this? i386?
In general no one tests 2.
from mysys_priv.h:17,
> > from my_new.cc:22:
> > /usr/include/asm/system.h:247: error: expected `,' or `...' before "new"
Don't include then. That's the standard response to
FTBFS bugs involving linux-kernel-headers.
On many architectures is not usab
, no? Now I seeno more NPTL in 2.3.5 or even the
> current 2.3.2. Maybe I'm missing something.
No, it never did. Run /lib/tls/libc.so.6 instead.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
no fault, but PD hangs. I traced it down to the use of
> pthread_join() which is where the code hangs. (I've been doing a
> backtrace after manually killing the application)
Why do you think it's pthread_join's fault? pthread_join will wait for
a thread to complete. Is the
bug occurs with both LinuxThreads and NPTL, then it's not a bug
in glibc. You will have to debug the application itself.
Try playing with "info threads", "thread ", and the GDB manual.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wit
2.2.20 kernel.
Sorry, but sid doesn't support 2.2 very well. I don't know if anyone
will be able to figure out this problem. In the mean time, and since
there is no security support for 2.2 any more, I highly recommend an
upgrade.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUB
w to make this any clearer...
It is a private interface. Therefore it is subject to ABI-incompatible
changes and sudden removal, which indeed has happened; it is no longer
available. Whatever you're using __libc_stack_end for, don't.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To U
in order to
> get more info.
>
> Now I get *no* python or libxml2/libxslt symbols in the stack
> traces.
What does the backtrace look like without libc6-dbg installed? What
does it look like with?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rmation back however, even if I uninstall
> libc6-dbg. I tried removing libc6-dbg and then reinstalling libc6 but
> to no avail.
Then I'm afraid it's something unrelated to glibc in your environment,
and we can't help you.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
4 or 3.3 and
> the error is always the same.
>
> -- CODE START --
> #include
>
> int main()
> {
> return 0;
> }
> -- CODE END --
Do not do that, then. This is one of many Linux headers which should
not be used from userspace programs.
--
Daniel Jacobowitz
C
e on i386. I'm going to try to look at the
MIPS syscall.h bug too. I'm not sure what else, but I'll make a pass
over the bug list; we need to get moving again, so my main goal here is
to pick up a little momentum.
Let me know if you have any fixes you want included in the ne
t think that's what is happening at all: I think that in one of
these cases, your test file's on-stack fenv_t is aligned, and on the
other it isn't. The code you posted for gcc 4.0 looks fine. I think
the assembly is broken or the definition of fenv_t.
--
Daniel Jacobowitz
CodeSourcer
0 looks fine. I think
> >the assembly is broken or the definition of fenv_t.
>
> drow is right, as usual. our fenv_t needs to be defined with
> __attribute__((aligned(8))) or similar.
I'd recommend "fixing" the asm instead: that's an ABI change and would
re
about, since they ought to be in /lib64.
I've verified that it won't complain about properly installed 64-bit
libraries on i386.
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 1134 matches
Mail list logo
