Source: glibc
Version: 2.25-2
Hi,
On kfreebsd-* and hurd I'm getting a linker failure that mremap()
doesn't exist. It exists in sys/mman.h.
Kurt
retitle 746516 glibc: Enable -fasynchronous-unwind-tables on more arches.
thanks
> It seems that not all arches have -fasynchronous-unwind-tables
> enabled. I see it enabled on amd64, i386, s390x, but disabled
> on armel/armhf, powerpc.
>
> Could this enable this on more architectures?
>
> I'm
On Sat, Jul 13, 2013 at 04:15:44PM -0700, Jonathan Nieder wrote:
Hi Kurt,
In November, 2012, you wrote (re elfutils's plugin path):
unarchive 632281
reopen 632281
#It doesnt do the right thing in case of non-multi arch now
How should $LIB be set to support this? I'm worried that
On Fri, Jul 01, 2011 at 07:44:01PM +0200, Kurt Roeckx wrote:
Anyway, I think ld.so does what it's supposed to do in case
everything was multiarch, the files would need to be moved
there in that case. But I think it's wrong to only try
the multiarch location.
So the elfutils code does
Package: tzdata
Hi,
I've read today that upstream has taken down the source because
of a law suite against them. From what I understand they have
based some of their historic information on the ACS American
Atlas. Upstream believes that all information is in the public
domain.
Kurt
--
On Fri, Oct 07, 2011 at 09:22:17PM +0200, Julien Cristau wrote:
On Fri, Oct 7, 2011 at 21:17:35 +0200, Kurt Roeckx wrote:
Package: tzdata
Hi,
I've read today that upstream has taken down the source because
of a law suite against them. From what I understand they have
based
Package: libc6
Version: 2.10.2-6
Severity: important
Hi,
It seems that getaddrinfo() now returns EAI_NONAME for a non-permanent
error. Trying to resolve something using host or dig, I get
as error:
;; connection timed out; no servers could be reached
That is clearly different that an error
Package: libc6-dev
Version: 2.10.2-2
Hi,
As already requested in #558314, I would like to see the
following defines in timex.h:
#define MOD_NANOADJ_NANO
#define MOD_MICRO ADJ_MICRO
I don't want anything for TAI support yet, so don't define
NTP_API of MOD_TAI yet, they're not
Source: eglibc
Version: 2.10.2-2
Severity: wishlist
Hi,
Could you please provide support for NTP API 4?
The changes in version 4 is the addition of MOD_TAI (ADJ_TAI)
and a tai member in the ntptimeval struct.
The kernel already supports this since 2.6.26 when ADJ_TAI
got added. The current
Changing the struct ntptimeval means changing the ABI. This has been
done upstream using symbol versioning, using GLIBC_2.12. I am currently
not sure we can already use this version without breaking the binary
compatibility with other distributions.
We're only waiting for this since 2000. A
On Mon, Aug 10, 2009 at 08:23:12PM +0200, Kurt Roeckx wrote:
Source: libc6.1-dev
Version: 2.9-23
Severity: important
Hi,
While building audit on alpha, I get the following error:
gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../auparse -fPIC -DPIC
-D_GNU_SOURCE '-DTABLE_H=actiontab.h
On Fri, Jul 03, 2009 at 02:50:54AM +0200, Aurelien Jarno wrote:
On Thu, Jul 02, 2009 at 08:15:29PM +0200, Kurt Roeckx wrote:
Package: libc6
Version: 2.9-12
Hi,
It seems that libc6 doesn't try the other nameserver anymore when
the first returns 5(REFUSED). If a nameserver returns
Package: libc6
Version: 2.9-12
Hi,
It seems that libc6 doesn't try the other nameserver anymore when
the first returns 5(REFUSED). If a nameserver returns REFUSED,
it's not the same as a permanent error.
Atleast apt-get in stable and testing/unstable react different
to this.
Kurt
--
To
On Sun, Jul 06, 2008 at 05:14:44PM -0700, Steve Langasek wrote:
On Mon, Jul 07, 2008 at 01:39:37AM +0200, Kurt Roeckx wrote:
You don't seem to request ipv4 addresses, you request AF_UNSPEC, which
should get you both ipv4 and ipv6. You get 127.0.0.1 twice, and ::1 one
time.
You'll find
On Sun, Jul 06, 2008 at 03:09:09PM -0700, Steve Langasek wrote:
Hi folks,
I've run across an ipv4/ipv6 configuration issue which I think needs to have
light cast on it so we can try to resolve this in time for lenny (whatever
the right resolution actually is), in order to avoid a pile-up of
On Sun, Apr 06, 2008 at 05:43:06PM +0200, Elmar Hoffmann wrote:
Hi Kurt,
on Tue, Jul 31, 2007 at 01:34:43 +0200, you wrote:
tags 343140 + ipv6
Havig read the bug report, I do think that this was in error. This bug
is not about lacking/non-working IPv6 support.
You're right, and I have
I always have to go and search what the option is to show the current
charmap. It's documented in nl_langinfo(3), but it would be nice that
it was documented in either the locale manpage, or that the locale tool
could show it itself.
By guessing from the same manpage I could atleast find those
Package: libc6-dev, linux-libc-dev
Severity: important
Hi,
When building proftpd-dfsg on amd64 I get the following error:
In file included from /usr/include/asm/types.h:5,
from /usr/include/asm-x86_64/sigcontext.h:4,
from /usr/include/asm/sigcontext.h:5,
On Sun, Oct 07, 2007 at 12:09:51PM +0200, Bastian Blank wrote:
On Sun, Oct 07, 2007 at 11:38:18AM +0200, Kurt Roeckx wrote:
When building proftpd-dfsg on amd64 I get the following error:
In file included from /usr/include/asm/types.h:5,
from /usr/include/asm-x86_64
On Sat, Sep 29, 2007 at 11:56:35AM +0200, Wolf Wiegand wrote:
Hi,
Kurt Roeckx wrote:
I haven't seen anybody claim that any of the *BSDs implemented rule 9
that also says he tested it, I've only seen reported of FreeBSD saying
it didn't.
I just tested this:
~/ uname -sr
FreeBSD
On Fri, Sep 28, 2007 at 06:23:06PM +, Pierre Habouzit wrote:
DNS RR is broken on Windows XP since SP2, Windows Vista, most *BSDs,
Redhat and Fedora, and probably any Linux distribution out there
I've just tested XP SP2 myself in various ways. I've tried things
like internet explorer,
On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
Heedless of the effect on the DNS round-robin functionality I describe
above, the authors of RFC3484 specified (s6 rule 9) that all addresses
should be sorted by proximity to the host making the choice - where
proximity is
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
I've attached a small test program. The results are:
sarge: libc6 2.3.2.ds1-22sarge5: random order
etch: libc6 2.3.6.ds1-13etch2: ordered results
Maybe I should attach it.
Kurt
#include sys/types.h
#include sys/socket.h
#include
On Fri, Sep 07, 2007 at 06:54:21PM +1000, Anthony Towns wrote:
OTOH, getaddrinfo is meant to give a close answer, and doing prefix
matching on NATed addresses isn't the Right Thing. For IPv6, that's fine
because it's handled by earlier scoping rules. For NATed IPv4 though the
prefix we should
Hi,
I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
should sort the results or not. I think the current way it sorts things
does not work at all in IPv4, and I think it hurts more than it does
good.
I'm seeking input from the tech-ctte on how to handle this.
Kurt
On Fri, Sep 07, 2007 at 12:34:10AM +0200, Pierre Habouzit wrote:
the Ctte may want to read:
- http://udrepper.livejournal.com/16116.html
- http://people.redhat.com/drepper/linux-rfc3484.html
The first one makes a point to which I party agree, but also disagree.
It's atleast in the
reopen 438179
thanks
On Thu, Aug 16, 2007 at 08:24:51PM +0200, Aurelien Jarno wrote:
This is a feature, not a bug. getaddrinfo() sorts results according to
RFC3484. You can configure the way they are sorted using /etc/gai.conf.
None of the rules in rfc3484 say anything about this. In fact,
On Thu, Aug 16, 2007 at 10:03:14PM +0200, Aurelien Jarno wrote:
Kurt Roeckx a écrit :
reopen 438179
thanks
On Thu, Aug 16, 2007 at 08:24:51PM +0200, Aurelien Jarno wrote:
This is a feature, not a bug. getaddrinfo() sorts results according to
RFC3484. You can configure the way
On Thu, Aug 16, 2007 at 10:42:20PM +0200, Aurelien Jarno wrote:
Rule 9: Use longest matching prefix.
When DA and DB belong to the same address family (both are IPv6 or
both are IPv4): If CommonPrefixLen(DA, Source(DA))
CommonPrefixLen(DB, Source(DB)), then prefer DA.
Package: glibc
Version: 2.6.1-1
Severity: important
Hi,
It seems that getaddrinfo() seems to sort the results, which defeats the
point of having multiple A-records in the first place.
If I look up 0.pool.ntp.org I (now) get:
0.pool.ntp.org has address 193.39.78.2
0.pool.ntp.org has address
From: Aurelien Jarno [EMAIL PROTECTED]
On Tue, Jul 24, 2007 at 09:00:12AM +0200, Matthias Klose wrote:
severity 433391 grave
clone 433391 -1
reassign -1 glibc
block 433391 by -1
thanks
Building gcj or gcc-snapshot on a system downgraded to glibc-2.5
doesn't show the testsuite
So on amd64, with 2.3.2.ds1-22sarge4 I get:
intrepid:~$ zdump -v /usr/share/zoneinfo/UTC
/etc/localtime -9223372036854775808 = NULL
/etc/localtime -9223372036854689408 = NULL
/etc/localtime 9223372036854689407 = NULL
/etc/localtime 9223372036854775807 = NULL
intrepid:~$ zdump --version
reassign 403658 purelibc
retitle 403658 purelibc: FTBFS: Makes use of glibc internal _IO_MTSAFE_IO.
thanks
Theoretically you should not define _IO_MTSAFE_IO it is reserved for
glibc internals. That's why you get an error there, when using a NPTL libc.
So, I've reassign it to purelibc, because
Package: libc6-dev
Version: 2.3.6.ds1-9
Severity: important
Hi,
While trying to build purelibc on amd64 I get the following error:
In file included from /usr/include/libio.h:171,
from /usr/include/stdio.h:72,
from stdio.c:25:
Hi,
The problem is that the .TH is missing then the '.'. Line 104
looks like:
TH ICONV 1 etch 20/Jun/2004 Debian GNU/Linux
And should be:
.TH ICONV 1 etch 20/Jun/2004 Debian GNU/Linux
After that change it looks normal again.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: libc6
Version: 2.3.6-15
Severity: important
Hi,
It seems that iconv() return -1 and sets errno to EILSEQ on valid
input that it can't convert to the output encoding. It shouldn't be
doing that, since it is valid input.
This can be simple showed using the iconv util, since it reacts
Package: glibc
Version: 2.3.999-1
Severity: serious
Tags: experimental
Hi,
Your package is failing to build on amd64 with a segmentation
fault. From the buildd log:
GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C
On Fri, Mar 10, 2006 at 02:02:04PM +0100, Daniel Schepler wrote:
After some investigation of the failure of kdelibs to build, I found it
appears to be a bug in either libtool, ld, or the dynamic linker, so I'm
CC'ing the maintainers of those packages. The problem is that lt-meinproc is
Package: glibc
Version: 2.3.999-1
Severity: important
Hi,
Your package failed to build on amd64. The amd64 version seems
to have build without problem, but then when it tried to build
the i386 version, it failed with the following error:
running configure fragment for sysdeps/i386/elf
checking
Package: debhelper
Severity: wishlist
Hi,
Some libraries want to restart a list of services when the
library gets upgraded. I currently know of only 2 such libraries
that have code for it: libc6 and libssl0.9.8.
They both have a simular postinst script, but they also have
differences.
For
On Sat, Mar 04, 2006 at 02:23:25PM +0100, Cyril Chaboisseau wrote:
I just built qemu 0.8.0-2 from source but with just a slight change from
usbdevice_fs.h as described here
http://lkml.org/lkml/2005/9/3/60
without this change qemu couldn't build but as the author of the patch
(Harald
On Wed, Feb 22, 2006 at 02:45:20PM +0100, Andreas Jochens wrote:
To fix this, I suggest to add the missing symlink /usr/lib64 - /usr/lib
to the 'libc6-udeb' package in debian/sysdeps/amd64.mk in a similar
way as it is done for the 'libc6' package.
The /lib64 - lib symlink on d-i is created
On Mon, Feb 20, 2006 at 11:10:41AM -0700, Bdale Garbee wrote:
On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote:
If there's
consensus that putting this stuff in /usr/lib32 on amd64 is prettier than
/emul/ia32-linux, I see no reason not to move forward.
My sense is that the
On Sun, Nov 27, 2005 at 12:06:15AM -0500, Daniel Jacobowitz wrote:
On Sat, Nov 26, 2005 at 04:35:45PM +0100, Kurt Roeckx wrote:
I'm planning on doing an NMU for this tommorrow. We currently
don't have a libc6 in testing because of this.
I assume you mean that amd64 doesn't. 2.3.5-8
-amd64 libc6-prof libc6
libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb
libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.5-8.1
Distribution: unstable
Urgency: low
Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
Changed-By: Kurt
I'm planning on doing an NMU for this tommorrow. We currently
don't have a libc6 in testing because of this.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: glibc
Version: 2.3.5-8
Severity: important
Tags: patch
Hi,
glibc is failing to build on amd64 with the following error:
gcc ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S -c -I../include -I.
-I/build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl -I.. -I../libio
Hi,
I'm seeing a simular problem when building openct on amd64 that
is caused by including usbdevice_fs.h.
A buildd log is available at:
http://amd64.ftbfs.de/fetch.php?pkg=openctver=0.6.5-2arch=amd64stamp=1126228644file=logas=raw
The first problem here is that div64.h uses BIT_PER_LONG, which
Package: libc6
Version: 2.3.2.ds1-22
Hi,
It seems that on amd64, all binaries and libraries in the libc6
pacakge have a wrong dynamic linker in the binaries.
ldd /lib/libc.so.6
/lib/ld-linux-x86-64.so.2 (0x002a95556000)
ldd /usr/bin/iconv
libc.so.6 = /lib/libc.so.6
reassign 317946 libc6
severity 317946 serious
merge 317946 318956
thanks
Merging those bugs, since they all obviously are the same.
I'm setting it to serious since the other 2 merge ones are set to
serious too.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
severity 317674 serious
merge 317674 317946
thanks
Yet an other one it seems.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
When building debian-installer, I'm also getting the following
error:
Command failed with status 1 : gcc -nostdlib -nostartfiles -shared
-Wl,-soname=libc.so.6 -uwctomb -ufclose -ufreopen64 -ugetmntent -usleep
-uwcsncasecmp -ustrptime -umktime -u__fxstat -ugetline -ulocaltime -uiopl
reassign 298247 libnss-pgsql
retitle 298247 libnss-pgsql: Uses non-exported libc interface.
thanks
On Sun, Mar 06, 2005 at 11:00:46AM -0500, Daniel Jacobowitz wrote:
On Sun, Mar 06, 2005 at 02:01:12AM +0100, Kurt Roeckx wrote:
Package: libc6-dev
Version: 2.3.2.ds1-20
Hi,
libnss
Package: libc6-dev
Version: 2.3.2.ds1-20
Hi,
libnss-pgsql uses bits/libc-lock.h with _LIBC and NOT_IN_libc
defined to use __libc_lock_*.
On amd64 this is failing because it does this:
#ifdef _LIBC
# include lowlevellock.h
# include tls.h
# include pthread-functions.h
#endif
None of those seem
On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote:
Could you please provide details about the problem of having the
symlinks in glibc?
Is it that glibc has a versioned Replaces: base-files and dpkg removes
the symlink in base-files before installing the one from glibc,
On Sun, Dec 05, 2004 at 06:14:24PM +0100, Santiago Vila wrote:
On Sun, 5 Dec 2004, Kurt Roeckx wrote:
On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote:
Could you please provide details about the problem of having the
symlinks in glibc?
Is it that glibc has
On Sun, Oct 31, 2004 at 10:35:02AM +0100, Thomas Koenig wrote:
int mycomp(void const *p1, void const *p2) {
mydata const *v1, *v2;
v1 = p1;
v2 = p2;
return (v1-key) (v2-key);
}
Change that return to return (v1-key) - (v2-key) and it will
work as expected.
Kurt
--
To
On Sat, Oct 23, 2004 at 09:52:11PM +0200, Andreas Jochens wrote:
+--- ldconfig.h 2002-04-22 11:51:40.0 +
glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldconfig.h2004-10-07
14:47:52.649686928 +
+@@ -20,7 +20,7 @@
+
+ #define SYSDEP_KNOWN_INTERPRETER_NAMES \
+
On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote:
This patch is harmless with respect to any LSB requirement.
The name of the dynamic loader, which is coded into every binary
can only be changed in the gcc package. This patch does not change
that.
I don't know what you all
On Sun, May 09, 2004 at 05:47:00PM -0400, Daniel Jacobowitz wrote:
If the tools support it, and it works, someone should provide a patch
to the debian/sysdeps/ file to enable it. The x86_64 configuration
isn't even in debian-glibc CVS as far as I know, take it up with the
porters.
Putting
On Sun, May 09, 2004 at 05:47:00PM -0400, Daniel Jacobowitz wrote:
If the tools support it, and it works, someone should provide a patch
to the debian/sysdeps/ file to enable it. The x86_64 configuration
isn't even in debian-glibc CVS as far as I know, take it up with the
porters.
Putting
Package: libc6
Version: 2.3.2.ds1-12
It seems that pthread_condattr_setpshared and
pthread_mutexattr_setpshared both return 38 (ENOSYS) when called
on amd64.
Example code:
pthread_condattr_t condattr;
printf(%d\n, pthread_condattr_init(condattr));
printf(%d\n,
On Sun, May 09, 2004 at 04:27:23PM -0400, Daniel Jacobowitz wrote:
Details about the kernel and environment on both test systems?
It's both times on the same machine with the same kernel. It's
an x86_64 2.6.5 kernel.
The i386 part is a chroot with sarge i386 on it, amd64 is a
pure64 amd64
On Mon, May 03, 2004 at 05:13:28PM +0200, Goswin von Brederlow wrote:
Hi,
I'm forwarding this to debian-amd64 since I'm not working on debians
amd64 anymore since the DAM rejected me.
I can't reproduce this on a system with libc6 2.3.2.ds1-11,
coreutils 5.0.91-2 and a 2.6.5 kernel. Neither
On Mon, May 03, 2004 at 05:13:28PM +0200, Goswin von Brederlow wrote:
Hi,
I'm forwarding this to debian-amd64 since I'm not working on debians
amd64 anymore since the DAM rejected me.
I can't reproduce this on a system with libc6 2.3.2.ds1-11,
coreutils 5.0.91-2 and a 2.6.5 kernel. Neither
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
u64 type. That type is __KERNEL__ only.
I think the whole file should be probably be #ifdef'd to
__KERNEL__ but I'm not sure.
This problem causes a build failure for
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
/usr/include/asm/mpspec.h (i386, line 6) does:
#include mach_mpspec.h
Which does not exist.
What does however exist are the following files:
/usr/include/asm/mach-bigsmp/mach_mpspec.h
/usr/include/asm/mach-default/mach_mpspec.h
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/cpumask.h it's using BITS_TO_LONGS which is
__KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Sun, Apr 25, 2004 at 10:40:37PM +0900, GOTO Masanori wrote:
At Sun, 25 Apr 2004 14:25:49 +0200,
Kurt Roeckx wrote:
In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
u64 type. That type is __KERNEL__ only.
I think the whole file should be probably be #ifdef'd
On Sun, Apr 25, 2004 at 11:21:53PM +0900, GOTO Masanori wrote:
Which version did you build sysklogd ?
I'm using 1.4.1-10, which is the latest in testing.
Trying the same with 1.4.1-14 fixes all my problems.
Sorry for all those bugreports about sysklogd.
Kurt
--
To UNSUBSCRIBE, email to
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
u64 type. That type is __KERNEL__ only.
I think the whole file should be probably be #ifdef'd to
__KERNEL__ but I'm not sure.
This problem causes a build failure for
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
/usr/include/asm/mpspec.h (i386, line 6) does:
#include mach_mpspec.h
Which does not exist.
What does however exist are the following files:
/usr/include/asm/mach-bigsmp/mach_mpspec.h
/usr/include/asm/mach-default/mach_mpspec.h
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/bitmap.h it's using BITS_PER_LONG all over
the place but BITS_PER_LONG is __KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
In /usr/include/linux/cpumask.h it's using BITS_TO_LONGS which is
__KERNEL__ only.
Should bitmap.h be ifdef'd to __KERNEL__?
This again causes build problems in sysklogd.
Kurt
On Sun, Apr 25, 2004 at 10:40:37PM +0900, GOTO Masanori wrote:
At Sun, 25 Apr 2004 14:25:49 +0200,
Kurt Roeckx wrote:
In /usr/include/linux/jiffies.h line 16, 20 and 22 it uses the
u64 type. That type is __KERNEL__ only.
I think the whole file should be probably be #ifdef'd
On Sun, Apr 25, 2004 at 11:21:53PM +0900, GOTO Masanori wrote:
Which version did you build sysklogd ?
I'm using 1.4.1-10, which is the latest in testing.
Trying the same with 1.4.1-14 fixes all my problems.
Sorry for all those bugreports about sysklogd.
Kurt
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Here is a small patch that fixes warning/errors about usage of
long long for amd64.
Kurt
--- include/asm-x86_64/types.h.orig 2004-04-22 23:16:11.294209120 +0200
+++ include/asm-x86_64/types.h 2004-04-22 23:16:02.109605392 +0200
@@
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Here is a small patch that fixes warning/errors about usage of
long long for amd64.
Kurt
--- include/asm-x86_64/types.h.orig 2004-04-22 23:16:11.294209120 +0200
+++ include/asm-x86_64/types.h 2004-04-22 23:16:02.109605392 +0200
@@
On Sat, Apr 17, 2004 at 12:14:39PM -0700, Ben Pfaff wrote:
Herbert Xu [EMAIL PROTECTED] writes:
Accordingly, I believe that the pattern in your example means
backslash, followed by a, followed by closing square bracket, not what
you think it means.
You're quite right. This is
On Sat, Apr 17, 2004 at 12:14:39PM -0700, Ben Pfaff wrote:
Herbert Xu [EMAIL PROTECTED] writes:
Accordingly, I believe that the pattern in your example means
backslash, followed by a, followed by closing square bracket, not what
you think it means.
You're quite right. This is
On Fri, Apr 16, 2004 at 12:54:03PM +1000, Herbert Xu wrote:
On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
Accordingly, I believe that the pattern in your example means
backslash, followed by a, followed by
On Sat, Apr 17, 2004 at 07:58:21AM +1000, Herbert Xu wrote:
On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote:
After reading all that you have to get confused about what [\[\]\\] means.
At the highest level it says that the '\' should be discarded,
Not quite. In the context
On Fri, Apr 16, 2004 at 12:54:03PM +1000, Herbert Xu wrote:
On Fri, Apr 16, 2004 at 08:09:05AM +1000, herbert wrote:
On Thu, Apr 15, 2004 at 03:10:58PM +0100, Colin Watson wrote:
Accordingly, I believe that the pattern in your example means
backslash, followed by a, followed by
On Sat, Apr 17, 2004 at 07:58:21AM +1000, Herbert Xu wrote:
On Fri, Apr 16, 2004 at 08:49:14PM +0200, Kurt Roeckx wrote:
After reading all that you have to get confused about what [\[\]\\] means.
At the highest level it says that the '\' should be discarded,
Not quite. In the context
On Sun, Apr 04, 2004 at 07:26:18PM -0400, Daniel Jacobowitz wrote:
On Mon, Apr 05, 2004 at 12:32:29AM +0200, Kurt Roeckx wrote:
It's a problem because configure doesn't find it anymore. It
doesn't include resolv.h so it doesn't know that it gets changed
to __res_*.
That's a bug
Package: libc6
Version: 2.3.2.ds1-11
It seems the weak symbols for res_* are missing on amd64.
in resolv/res_data.c there is:
#if SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)
weak_alias (__res_query, res_query);
It seems the SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)
returns false for some
On Sun, Apr 04, 2004 at 06:22:57PM -0400, Daniel Jacobowitz wrote:
On Sun, Apr 04, 2004 at 11:50:15PM +0200, Kurt Roeckx wrote:
Package: libc6
Version: 2.3.2.ds1-11
It seems the weak symbols for res_* are missing on amd64.
in resolv/res_data.c there is:
#if SHLIB_COMPAT(libresolv
Package: libc6
Version: 2.3.2.ds1-11
When trying to build glibc on amd64 it seems to compile fine, it
even already created glibc-doc_2.3.2.ds1-11_all.deb and
locales_2.3.2.ds1-11_all.deb but then fails with like this:
dpkg-deb: building package `locales' in
`../locales_2.3.2.ds1-11_all.deb'.
88 matches
Mail list logo
