Bug#914492: libc0.1-dev: Has Linux-only mremap in headers on non-Linux
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
Bug#746516: glibc: Enable -fasynchronous-unwind-tables on more arches.
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 currently seeing elfutils test failures on powerpc because > the unwind information is not available. I'll probably also get > this problem on arm64 if it's not enabled there. Elfutils is still broken because of this, on everything but a few architectures. Can you please enable it? As far as I can see, only init/fini should not be build using it and as far as I can see most arches should already support this. Kurt
Bug#632281: elfutils isn't finding its plugins
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 there's no value of ORIGIN and LIB that would make $ORIGIN/../$LIB point to the right place for both plugins using and not using the new filesystem layout. I think it should expand to both the layouts? Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130714070604.ga30...@roeckx.be
Bug#632281: elfutils isn't finding its plugins
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: #define ORIGINDIR $ORIGIN/../$LIB/ LIBEBL_SUBDIR / strcpy (stpcpy (stpcpy (dsoname, ORIGINDIR libebl_), machines[cnt].dsoname), .so); Which gives you something like: $ORIGIN/../$LIB/elfutils/libebl_x86_64.so Which then gets translated to: /usr/bin/../x86_64-linux-gnu/elfutils/libebl_x86_64.so I assume the non-multiarch code generated: /usr/bin/../lib/elfutils/libebl_x86_64.so And I was expecting the new code to generate: /usr/bin/../lib/x86_64-linux-gnu/elfutils/libebl_x86_64.so (The /lib part is missing.) I've uploaded a new elfutils that moves the files to /usr/lib/x86_64-linux-gnu/elfutils/, but it still can't find them. Could you change the code include the lib part? Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224232103.ga15...@roeckx.be
Bug#644650: tzdata: possible copyright violation
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 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007191735.ga5...@roeckx.be
Bug#644650: tzdata: possible copyright violation
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 some of their historic information on the ACS American Atlas. Upstream believes that all information is in the public domain. What do you think filing this bug achieves? I'm just trying to make you aware of the issue. Do with it as you see fit. Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007200158.ga6...@roeckx.be
Bug#582916: libc6: getaddrinfo() returns EAI_NONAME for temporary problem.
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 message like: Host host not found: 3(NXDOMAIN) For that error I would expect to get EAI_NONAME. In case I don't get a reply, I would expect to get back EAI_AGAIN. The version in lenny still returns EAI_AGAIN. Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100524141000.ga16...@roeckx.be
Bug#559482: libc6-dev: Add missing MOD_* for ntp in timex.h
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 useful without the other changes. But we now need to patch ntpd because STA_NANO is defined but MOD_NANO isn't, and for some reason there is a ADJ_NANO that does what MOD_NANO is supposed to do. Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558314: eglibc: Add support for NTP API 4
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 /usr/include/sys/timex.h already has ADJ_TAI and a tai member in struct timex. The struct ntptimeval however didn't get changed, since this is not part of the kernel but implemented only in libc. From ntpd's point of view those changes need to be made: - add long int tai; to struct ntptimeval. This is a long in all known versions I know, but the kernel has an int in the struct timex (for compatibility reasons with the old struct?). - #define NTP_API 4 - Have a MOD_TAI define - ntp_gettime() should fill in the tai member of struct ntptimeval. Note that there is an ADJ_TAI in timex.h, and defines to change from ADJ_* to MOD_*, but there is no such one for TAI, NANO or MICRO. The ntp source does not use any of the ADJ_* names, it only uses MOD_*. The following defines are missing: #define MOD_NANOADJ_NANO #define MOD_MICRO ADJ_MICRO #define MOD_TAI ADJ_TAI (The other 3 ADJ_* defines are not used in ntp.) Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558314: eglibc: Add support for NTP API 4
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 little longer won't hurt. Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540871: /usr/include/bits/socket.h:68: error: expected identifier before numeric constant
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' -Wall -g -O2 -MT gen_actiontabs_h-gen_tables.o -MD -MP -MF .deps/gen_actiontabs_h-gen_tables.Tpo -c -o gen_actiontabs_h-gen_tables.o `test -f 'gen_tables.c' || echo './'`gen_tables.c In file included from /usr/include/sys/socket.h:40, from libaudit.h:33, from gen_tables.c:36: /usr/include/bits/socket.h:68: error: expected identifier before numeric constant A preprocessed file has this in it: 0x4000 = 04000 /usr/include/asm/socket.h has: #define SOCK_NONBLOCK 0x4000 Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535504: libc6: resolving: does not try different nameserver anymore
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 REFUSED, it's not the same as a permanent error. Atleast apt-get in stable and testing/unstable react different to this. Did you tried version 2.9-18 ? A big part of the resolving code has been changed between 2.9-12 and 2.9-18. 2.9-18 behaves the same. Kurt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535504: libc6: resolving: does not try different nameserver anymore
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 UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: correct definition of localhost?
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 that the duplication of 127.0.0.1 is still there if you specify AF_INET instead, because the problematic duplication happens when requesting records for the ipv4 address family. I left it as AF_UNSPEC in the test case to show that the problem exists when using protocol-agnostic best practices, which is what slapd does. I was just confused when reading it, and understood it as only requesting AF_INET. That was just to make it clear. - the ::1 address should *not* be special-cased by nss_files. I really can't perceive any reason why it should be special-cased in the first place; i.e., why should the files backend behave differently than the DNS backend, and why would we want names that were specifically assigned to ::1, including names like ip6-loopback, to be automatically mapped to 127.0.0.1? I can't find any good reason why it should be changing ::1 to 127.0.0.1. So I think that atleast glibc should stop doing that. In any case, it shouldn't return 127.0.0.1 twice when it's not configured to return it twice. What do you mean by configured to return it twice? Would that mean duplicate lines in /etc/hosts (i.e., misconfiguration)? Yes. - we should only set up a single 'localhost' entry in /etc/hosts, pointing at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically. - You could also argue that openldap should get fixed to deal with cases where it tries to bind to the same ip/port twice. On the other hand, I don't think it a normal case, and I think it's unlikely that people would set up dns to have 2 times the same IP address and then try to bind to that hostname. Well, as I said before, I don't think it's the responsibility of callers such as slapd to check that getaddrinfo() hasn't returned duplicate entries [...] so if you have an argument of why extra complexity should be added to the caller to deal with duplicate records which, one way or another, should not exist (IMHO), I'm interested to hear it. The only case I can come up with would be misconfiguration, which I don't think is a good reason. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: correct definition of localhost?
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 /etc/hosts-related kludges as has been known to happen before... In response to bug #427067, the netbase maintainer made a change that adds localhost as an alias for ::1 on new installs. In April of this year, the Debian Installer team followed suit, adding this line in the netcfg udeb. The result of these changes is that since July 2007, any new lenny or sid chroots have had two addresses listed for localhost, and since April of this year, any new installs of lenny done using d-i have had it as well. Now, the problem I ran into is that when I enabled the test suite in the openldap2.3 package, the build failed mysteriously on a seemingly random set of architectures. The reason? The test suite configures slapd to run on a particular port on localhost, and the glibc files NSS backend special-cases the ::1 IPv6 loopback address, so that when you request an IPv4 address, it will map any ::1 entries to 127.0.0.1 for you. But of course we already have an entry for localhost as 127.0.0.1, so now we end up with duplicate addresses returned, and slapd tries to bind twice to the same address and port! 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. A test program showing this behavior is attached - compile and run it on a system with '::1 localhost' set in /etc/hosts, and you'll see 127.0.0.1 returned twice. An alternate test case, which also works on systems with older /etc/hosts and which I think shows the counterintuitiveness of the nss_files special-casing, is to run getent ahostsv4 ip6-localhost. I don't think it's the responsibility of callers such as slapd to check that getaddrinfo() hasn't returned duplicate entries, so I see a couple of solutions here: - the ::1 address should *not* be special-cased by nss_files. I really can't perceive any reason why it should be special-cased in the first place; i.e., why should the files backend behave differently than the DNS backend, and why would we want names that were specifically assigned to ::1, including names like ip6-loopback, to be automatically mapped to 127.0.0.1? I can't find any good reason why it should be changing ::1 to 127.0.0.1. So I think that atleast glibc should stop doing that. In any case, it shouldn't return 127.0.0.1 twice when it's not configured to return it twice. - we should only set up a single 'localhost' entry in /etc/hosts, pointing at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically. - You could also argue that openldap should get fixed to deal with cases where it tries to bind to the same ip/port twice. On the other hand, I don't think it a normal case, and I think it's unlikely that people would set up dns to have 2 times the same IP address and then try to bind to that hostname. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: tagging 343140
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 no idea why I tagged this bug. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314934: locale: document options like charmap
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 additional names that locale supports: d_fmt, d_t_fmt, t_fmt, t_fmt_ampm. I'm guessing there are more. It would be nice if this was better documented somewhere. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445611: conflicting types for 'mode_t'
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, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from /usr/include/sys/wait.h:31, from ../include/conf.h:95, from pr_fnmatch.c:38: /usr/include/asm-x86_64/types.h:6: error: conflicting types for 'mode_t' /usr/include/sys/types.h:72: error: previous declaration of 'mode_t' was here Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445611: conflicting types for 'mode_t'
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/sigcontext.h:4, from /usr/include/asm/sigcontext.h:5, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from /usr/include/sys/wait.h:31, from ../include/conf.h:95, from pr_fnmatch.c:38: /usr/include/asm-x86_64/types.h:6: error: conflicting types for 'mode_t' There is no mode_t defined in asm-x86_64/types.h. Line 6 has umode_t on it: typedef unsigned short umode_t; While /usr/include/sys/types.h line 72 has: typedef __mode_t mode_t; proftpd's configure.in has: AC_CHECK_TYPE(umode_t, mode_t) And config.h.in has: /* Define to `mode_t' if sys/types.h doesn't define. */ #undef umode_t During configure we see: checking for umode_t... no The config.log contains: configure:29869: checking for umode_t configure:29894: gcc -c -O2 -Wall -I/usr/include/postgresql conftest.c 5 conftest.c:122: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ac__type_new_' conftest.c: In function 'main': conftest.c:126: error: 'ac__type_new_' undeclared (first use in this function) conftest.c:126: error: (Each undeclared identifier is reported only once conftest.c:126: error: for each function it appears in.) conftest.c:126: error: expected expression before ')' token So it seems to me that proftpd's configure script is broken somehow. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
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 6.2-STABLE ~/ ping -c 1 ftp.us.debian.org | grep PING PING ftp.us.debian.org (204.152.191.7): 56 data bytes ~/ ping -c 1 ftp.us.debian.org | grep PING PING ftp.us.debian.org (35.9.37.225): 56 data bytes I don't know about ping on FreeBSD, but atleast on Debian, ping does not use getaddrinfo(). Please use one of the test programs that were send on the list that actually do use getaddrinfo(). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
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, ping, Anthony's python script under cygwin. They all fall under the not stable, and use a different IP each time. I let someone test it on Vista, and that does follow rule 9, making it 2 implementations I know of that actually do it. 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. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
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 defined as the length of the common initial address prefix. So if getaddrinfo() has always behaved in this way, I don't see a great deal of justification in changing it. The bug log indicated that there were pre-rfc implementations of getaddrinfo() that behaved more like gethostbyname() at least wrt round-robin DNS; but I've got no way of verifying that. glibc is the only implementation I know of that does this. 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 On other implementations I'm aware of is in libbind. You'll need to run configure with the --enable-libbind for that. It doesn't reorder it. I don't know of any of the other libcs in debian actually provide getaddrinfo(), but I doubt they'll reorder. There are also lots of applications that have a wrapper around gethostbyname() in case the libc doesn't provide it. It's highly unlikely any of those will do any reordering. This may have been a disputed but arguable definition of real network proximity for IPv6 in at the time 3484 was written. But it is clear now that it is not such a measure in the real IPv6 internet, and it has never been such a measure in the IPv4 internet. I hadn't seen any indication it was disputed for IPv6 prior to your mail. The patch in glibc only affected IPv4 addresses, for that matter. I've also stated that it might not work properly for IPv6. It's likely that something in the same /32 is close network wise, it's even more likely for /48 and /64, but you probably don't want to go below the /32. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
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 arpa/inet.h
#include netdb.h
#include stdio.h
int main()
{
struct addrinfo *res, *p, hints;
hints.ai_flags = 0;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
getaddrinfo(0.pool.ntp.org, ntp, hints, res);
for (p = res; p; p = p-ai_next)
{
if (p-ai_family == AF_INET)
{
char ip[INET_ADDRSTRLEN];
if (inet_ntop(p-ai_family,
(*(struct sockaddr_in *)p-ai_addr).sin_addr,
ip, sizeof(ip)) != NULL)
{
printf(%s\n, ip);
}
}
}
freeaddrinfo(res);
return 0;
}
Re: glibc's getaddrinfo() sort order
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 be using is whatever the host is going to be NATed *to*. And that would imply that the Right Thing would be to have an option more like: pretend-that 10/8 is-really 1.2.3.4/32 That doesn't seem likely to work though because it requires extra manual configuration, which won't happen. Giving up on actually getting getaddrinfo to give close answers for NATed boxes leaves the option of trying to avoid getaddrinfo going out of its way to give far answers instead, which would mean turning off prefix-matching for NATed boxes; which could be done by ignoring rule 9 by default for private IPv4 addresses. The problem with IPv4 is not only about NAT. It just happens to show the problem better. With the IPv6 allocation policies, it's likely that the more higher bits match, the closer it is network wise. It is rather unlikly in the IPv4 case, specially if you go above /16. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc's getaddrinfo() sort order
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 signature.asc Description: Digital signature
Re: glibc's getaddrinfo() sort order
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 spirit of the rfc to prefer one that's on the local network. It might be the intention of rule 9, but then rule 9 isn't very well written. In the case the server has 2 addresses assigned, I doubt that you're going to advertise the local one outside. So you're atleast have a different response for an internal and external query. I don't see why the interal query should also return the external address. I already suggested that maybe rule 9 should be limited to the common prefix length of the netmask you're using. An other option is that you extend rule 2 to have the same behaviour with ipv4, and that 10/8, 172.16/12 and 192.168/16 should be considered organization-local. Ulrich Drepper actually called site-local in the second document, but I think organization-local would be the right scope for it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: getaddrinfo() sorts results.
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, the last rule says: Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB. Also, I don't see an option to prevent it from sorting the list. If you don't want results to be sorted, don't use getaddrinfo(). Do you have a suggestion for an other interface that works with different address types other than getipnodebyname()? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: getaddrinfo() sorts results.
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 they are sorted using /etc/gai.conf. None of the rules in rfc3484 say anything about this. In fact, the last rule says: Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB. Rule 9 comes before: 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. Similarly, if CommonPrefixLen(DA, Source(DA)) CommonPrefixLen(DB, Source(DB)), then prefer DB. That's a rule that might work for IPv6, but not for IPv4. But even when using IPv6, I think you want the CommonPrefixLen to be atleast 24 bit, maybe even 32, or even 64. So, because I happen to have a 10.0.0.0/8 address, it prefers addresses which as many as possible 0's at the front. This is unlikely to give me an address that's going to be close network-wise, since none of the returned addresses are actually in 10.0.0.0/8. Anyway if you don't want to sort to the returned addresses, you only want to do that for IPv4, and thus need two different interfaces. I think rule 9 shouldn't be use for IPv4 addresses, or be changed that the minimum CommonPrefixLen should be the that of the netmask of the source address. Kurt
Bug#438179: getaddrinfo() sorts results.
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. Similarly, if CommonPrefixLen(DA, Source(DA)) CommonPrefixLen(DB, Source(DB)), then prefer DB. That's a rule that might work for IPv6, but not for IPv4. But even when using IPv6, I think you want the CommonPrefixLen to be atleast 24 bit, maybe even 32, or even 64. So, because I happen to have a 10.0.0.0/8 address, it prefers addresses which as many as possible 0's at the front. This is unlikely to give me an address that's going to be close network-wise, since none of the returned addresses are actually in 10.0.0.0/8. The fact you have a 10.0.0.0/8 does not changes anything to the way the list is sorted in rule 9. Only the returned addresses are taken into account. It sorts the list in such a way that the top most bits are the same. So it first sorts by: 10.0.0.0/8 then: 10.0.0.0/7 8.0.0.0/6 8.0.0.0/5 0.0.0.0/4 0.0.0.0/3 0.0.0.0/2 0.0.0.0/1 And then finaly the rest (128.0.0.0/1) The first of those makes sense for me, the rest doesn't. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438179: getaddrinfo() sorts results.
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 195.34.187.132 0.pool.ntp.org has address 202.73.37.27 0.pool.ntp.org has address 212.24.114.156 0.pool.ntp.org has address 217.116.227.3 0.pool.ntp.org has address 62.75.136.76 0.pool.ntp.org has address 62.245.224.171 0.pool.ntp.org has address 64.5.1.129 0.pool.ntp.org has address 66.180.136.186 0.pool.ntp.org has address 80.86.83.133 0.pool.ntp.org has address 81.169.172.219 0.pool.ntp.org has address 85.25.252.58 0.pool.ntp.org has address 88.198.8.101 0.pool.ntp.org has address 91.121.13.62 But getaddrinfo() will always return ip's in this order: 62.75.136.76 62.245.224.171 64.5.1.129 [...] There seems to be some variation in the list, but the first 4 or 5 are always the same. I only care about the first one. It should keep the order of the A-records the same as they were returned by the dns server. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434484: Bug#433391 closed by Aurelien Jarno [EMAIL PROTECTED] (Re: gij-4.1: Runs out of memory)
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 failures in libjava. This is actually a bug in java's unwinder, the fix I commited is wrong. I am therefore closing this bug, leaving the one on gcj opened. Are you sure you closed the right bug? You've closed the one assigned to gij-4.1 (#433391) and the one in glibc (#434484) is still open. PS: They both are forwarded upstream to gcc, so the forwarded on #434484 atleast seems wrong too. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412569: libc6: zdump -v segfaults
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 @(#)zdump.c 7.64 Upgrading to 2.3.2.ds1-22sarge5 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC Segmentation fault intrepid:~$ zdump --version zdump: invalid option -- - zdump: usage is zdump [ -v ] [ -c cutoff ] zonename ... I think it broke on 64 bit arches. With 2.3.6.ds1-13 (unstable) I still 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 @(#)zdump.c 7.66 On i386 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:52 1901 UTC isdst=0 gmtoff=0 /etc/localtime Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:52 1901 UTC isdst=0 gmtoff=0 /etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 UTC isdst=0 gmtoff=0 /etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 UTC isdst=0 gmtoff=0 On amd64, it never seems to show 1901 / 2038 properly. If I use a different timezone, and not using 2.3.2.ds1-22sarge5 the first 2 and last lines still look the same, but the rest between them look normal. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403658: lowlevellock.h missing on amd64.
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 it shouldn't be using it. (It seems you tried to merge bugs, but I guess control never got those, so I've just reassigned one of them to purelibc instead of cloning one.) I will try to find a hack to ignore all occurences of _IO_MTSAFE_IO from the headers installed by the glibc. At which point purelibc won't be able to build on any arch, so they really should look at it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403658: lowlevellock.h missing on amd64.
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:
/usr/include/bits/stdio-lock.h:24:26: error: lowlevellock.h: No such file or
directory
stdio.c: In function '__overflow':
stdio.c:238: warning: control reaches end of non-void function
stdio.c: In function '_pure_assign_file':
stdio.c:261: error: 'LLL_LOCK_INITIALIZER' undeclared (first use in this
function)
stdio.c:261: error: (Each undeclared identifier is reported only once
stdio.c:261: error: for each function it appears in.)
stdio.c: In function '_pure_freopen':
stdio.c:314: error: '_IO_lock_t' has no member named 'mutex'
stdio.c:320: error: '_IO_lock_t' has no member named 'mutex'
[...]
purelibc's stdio.c looks like:
#define _IO_MTSAFE_IO
#include stdio.h
on i386 we have:
#include bits/libc-lock.h
__libc_lock_define_recursive (typedef, _IO_lock_t)
Which results in:
typedef struct { pthread_mutex_t mutex; } __libc_lock_recursive_t;
typedef __libc_lock_recursive_t _IO_lock_t;
on amd64 we have:
#include bits/libc-lock.h
#include lowlevellock.h
typedef struct { int lock; int cnt; void *owner; } _IO_lock_t;
It looks to me like the version on amd64 currently isn't really working,
since the functions/defines in stdio-lock.h atleast don't work with
itself.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372510: libc6: iconv(1) man page has syntax errors
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 subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372515: iconv(): Returns EILSEQ when it can't convert to the output encoding.
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 the same. An simple latin1 file: $ cat test.txt tést $ iconv -f latin1 -t ASCII test.txt /dev/null iconv: illegal input sequence at position 1 $ iconv -f latin1 -t UTF-8 test.txt /dev/null $ From the manpage: EILSEQ An invalid multibyte sequence has been encountered in the input. From Single Unix Specification 3: [EILSEQ] Input conversion stopped due to an input byte that does not belong to the input codeset. It also says: If iconv() encounters a character in the input buffer that is valid, but for which an identical character does not exist in the target codeset, iconv() shall perform an implementation-defined conversion on this character. Instead of doing an implementation-defined conversion, it's returning an error, and saying the input is invalid, while the input is clearly valid. I would rather have that it actually follows the standard, and does some conversion, even if it just turns it in a '?' or something. Kurt
Bug#356382: glibc: FTBFS in experimental on amd64: segmantation fault.
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 LOCPATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/localedata /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer --utf8 rxspencer/tests /build/buildd/ glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer.out /bin/sh: line 1: 13309 Segmentation fault GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C LOCPATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/localedata /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer --utf8 rxspencer/tests /build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspencer.out make[3]: *** [/build/buildd/glibc-2.3.999/build-tree/amd64-libc/posix/tst-rxspe ncer.out] Error 139 I think there are some other errors in the log: GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-mqueue8 /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-mqueue8.out make[3]: *** [/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-mqueue5.out] Error 1 And: GCONV_PATH=/build/buildd/glibc-2.3.999/build-tree/amd64-libc/iconvdata LC_ALL=C /build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /build/buildd/glibc-2.3.999/build-tree/amd64-libc:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/math:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/elf:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/dlfcn:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nss:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nis:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/resolv:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/crypt:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl:/build/buildd/glibc-2.3.999/build-tree/amd64-libc/nptl /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-cputimer2 /build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-cputimer2.out make[3]: *** [/build/buildd/glibc-2.3.999/build-tree/amd64-libc/rt/tst-cputimer 1.out] Error 1 And finally it stopped with: make[2]: Target `check' not remade because of errors. make[2]: Leaving directory `/build/buildd/glibc-2.3.999/build-tree/glibc-2.4' make[1]: *** [check] Error 2 make[1]: Leaving directory `/build/buildd/glibc-2.3.999/build-tree/amd64-libc' make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs make: *** wait: No child processes. Stop. Build killed with signal 15 after 50 minutes of inactivity Note that it seems to have hang for 50 minutes without printing anything to stdout/stderr. Full buildd log is available at:
Re: Bug #355099: kdelibs FTBFS
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 getting linked with a NEEDED entry pointing to libkdecore.so because it directly uses symbols from that library, which is indirectly brought in by the -lkio argument, but the RPATH on the resulting binary only includes the directory containing libkio.so. I think the commands you're talking about being issued here are: /bin/sh ../libtool --tag=CXX --mode=link g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -DDEBIAN_VERSION=4:3.5.1-3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib -o meinproc meinproc.o xslt_pure.o libkbzipfilter_dummy.la -L/usr/lib -lxslt -lxml2 -lz -lm -L/usr/lib -lxml2 -lz -lm ../kio/libkio.la -lbz2 g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align-Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -DDEBIAN_VERSION=4:3.5.1-3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o .libs/meinproc meinproc.o xslt_pure.o -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib ./.libs/libkbzipfilter_dummy.a /usr/lib/libxslt.so /usr/lib/libxml2.so -lz -lm ../kio/.libs/libkio.so -lbz2 So basicly, there isn't a -lkdecore, while there should have been one. I consider this to be a bug in the package. The linker however adds in case it can detect it, as you seem to be aware of. See http://sourceware.org/ml/binutils/2005-09/msg00200.html for those who don't. As you say later in the mail adding kdecore to the link line solves this, and I think this should be done in any case. Looking at the result of an ldd on lt-meinproc I see: [...] libkdecore.so.4 = not found [...] libkdecore.so.4 = /usr/src/kdelibs-3.5.1/obj-x86_64-linux-gnu/kdecore/.libs/libkdecore.so.4 (0x2e6dc000) Where the first one comes from the executable itself, which doesn't have an rpath, and the second one comes from libkwalletclient.so.1 (thru libkio.so.4) Then the dynamic linker can't find where libkdecore.so is, despite the fact that libkio.so's RPATH includes the directories containing its dependencies, and one of those libraries has the RPATH needed for libkdecore.so. So I can see a few different ways to fix this: * Make libtool include all indirect rpath's directly on the link command line. But I find this ugly, and in fact a step backwards from recent improvements, and it really doesn't solve the general problem either. I've been pondering wether libtool should always add rpaths to libraries/binaries as long as they're not installed, but that has a few problems. One of them is, you'll always need to relink when you want to install it to remove the rpath's that you don't need. An other is that it's probably not very portable. One of the reasons I thought about this is #320698. * Make the dynamic loader able to find libraries within rpath's from already loaded libraries. But this doesn't totally solve the case outside libtool -- what if that other library then gets relinked in such a way that it doesn't indirectly include that rpath anymore? I think that 2 libraries with the same soname should be considered the same file. However, I think the problem is that in the executable (lt-meinproc) there is no rpath, so it can't find it at that time. Then later some other libraries get loaded, and one of them needs the same library again, but this time has an rpath. I think it's reasonable to expect it to fail. I think if it tried to load them in a different order, it would have worked, but I don't think it should. * Make ld add the required directory to RPATH when it automatically adds a NEEDED entry due to direct usage of symbols from the library involved. Somewhat ugly, though. I already find it ugly that it adds the NEEDED by itself, please don't make it automaticly add RPATH's too. But if it wouldn't have added the NEEDED in the first place, you would have known that you needed to link to kdecore sooner, and wouldn't have this problem. I'm still for removing this feature from the linker. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356306: glibc: FTBFS on experimental / amd64: biarch i386 failed to build.
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 for i386 TLS support... yes running configure fragment for nptl/sysdeps/pthread checking for forced unwind support... no configure: error: forced unwind support is required make: *** [/build/buildd/glibc-2.3.999/stamp-dir/configure_i386] Error 1 Full buildd log is available at http://amd64.ftbfs.de/fetch.php?pkg=glibcver=2.3.999-1arch=amd64stamp=1141959515file=logas=raw Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debhelper: Standard way to restart services on library upgrade.
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 instance, libc6 has a workaround for exim4 that libssl0.9.8 is missing, and probably should also have. And that is my biggest problem. libc6 doesn't use debconf, libssl0.9.8 does, but probably not as it should. But maybe libc6 can't used debconf? There are other problems with it like neither of them is using invoke-rc.d, as they probably should be doing. I'm looking for a more standard way to restart services, so I don't have worry about all those special cases. I was wondering if a debhelper script could help with part of this. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326561: qemu 0.8.0 in amd64
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 Welte), I cannot tell wether or not it has been done the right way That would be http://bugs.debian.org/326561, so I'll Cc them. If you could please apply that fix. It seems to be fixed in linux-headers-2.6.15-rc5-amd64-k8 but not in linux-kernel-headers. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64
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 by the rootskel.udeb. Please atleast keep things in the same package. I wouldn't have a problem with moving this to the glibc package, and I think we should do that. But we should probably coordinate this with the d-i people. Anyway, I think we shouldn't need a /usr/lib64. The only reason we need a /lib64 is because that is where the dynamic linker is. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
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 concensus that exists is around FHS compliance. While I personally consider /usr/lib32 pretty ugly, I am sensitive to the fact that we have always tried to be FHS compliant in Debian. FHS actually has a libqual in it, where qual can be things like 32 or 64. For PPC64, s390x, sparc64 and AMD64 it says that 64 bit libraries should be put in /lib64 and 32 bit version in /lib. For IA64, it says 64 bit libraries should be put in /lib, but doesn't say where 32 bit versions belong. It says: IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture. I think 32 bit it makes sense to actually put 32 bit libraries on ia64 in /lib32 too, instead of the current /emul/ia32-linux/, and think it would be more inline with the FHS. Is there a reason it's using /emul/ia32-linux/ ? So I would like both ia64 and amd64 to use /lib32. Looking over the open bug reports, it's well past time for another general update of ia32-libs. I'll try to make time for it this week. In the end, I'd like to get rid of ia32-libs, and have it be a dummy package. But on the other hand, I don't want to make a biarch version of things like the X libraries. PS: Does this really have to be on -release? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339389: glibc: FTBFS on amd64: sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
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 migrated to testing just fine. It's not our fault that the archive scripts and the separate amd64 archive don't get along. The archive scripts have some problems with this, and you could agrue that they should get fixed to handle it. I think it's a useless effort. The patch in this bug is fine, if you want to do the NMU. I don't have time for another glibc upload and someone _needs_ to look at sparc64 before the next one anyway. Patch for the NMU is attached. Kurt diff -u glibc-2.3.5/debian/patches/00list glibc-2.3.5/debian/patches/00list --- glibc-2.3.5/debian/patches/00list +++ glibc-2.3.5/debian/patches/00list @@ -93,0 +94 @@ +amd64_sem_trywait diff -u glibc-2.3.5/debian/changelog glibc-2.3.5/debian/changelog --- glibc-2.3.5/debian/changelog +++ glibc-2.3.5/debian/changelog @@ -1,3 +1,12 @@ +glibc (2.3.5-8.1) unstable; urgency=low + + * Non-maintainer upload. + * Rename sem_trywait to __new_sem_trywait in amd64 nptl code +so the alias works properly, and it can be build. +(Closes: #339389) + + -- Kurt Roeckx [EMAIL PROTECTED] Sun, 27 Nov 2005 11:22:03 +0100 + glibc (2.3.5-8) unstable; urgency=low * Add missing build dependency on libc6-dev-ppc64 on powerpc. only in patch2: unchanged: --- glibc-2.3.5.orig/debian/patches/amd64_sem_trywait.dpatch +++ glibc-2.3.5/debian/patches/amd64_sem_trywait.dpatch @@ -0,0 +1,35 @@ +#! /bin/sh -e + +# DP: Give sem_trywait a different name, so we can add an +# DP: alias to it. + +if [ $# -ne 2 ]; then +echo 2 `basename $0`: script expects -patch|-unpatch as argument +exit 1 +fi +case $1 in +-patch) patch -d $2 -f --no-backup-if-mismatch -p1 $0;; +-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1 $0;; +*) +echo 2 `basename $0`: script expects -patch|-unpatch as argument +exit 1 +esac +exit 0 + + +--- glibc-2.3.5/nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S.old 2005-11-15 23:09:31.0 +0100 glibc-2.3.5/nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S 2005-11-15 23:10:09.0 +0100 +@@ -29,10 +29,10 @@ + + .text + +- .globl sem_trywait +- .type sem_trywait,@function ++ .globl __new_sem_trywait ++ .type __new_sem_trywait,@function + .align 16 +-sem_trywait: ++__new_sem_trywait: + movl(%rdi), %eax + 2:testl %eax, %eax + jz 1f
Fixed in NMU of glibc 2.3.5-8.1
tag 339389 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 27 Nov 2005 11:22:03 +0100 Source: glibc Binary: libc6-dev-amd64 libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc6-ppc64 libc0.3-dbg libc6-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 Roeckx [EMAIL PROTECTED] Description: glibc-doc - GNU C Library: Documentation libc6 - GNU C Library: Shared libraries and Timezone data libc6-amd64 - GNU C Library: 64bit Shared libraries for AMD64 libc6-dbg - GNU C Library: Libraries with debugging symbols libc6-dev - GNU C Library: Development Libraries and Header Files libc6-dev-amd64 - GNU C Library: 64bit Development Libraries for AMD64 libc6-i686 - GNU C Library: Shared libraries [i686 optimized] libc6-pic - GNU C Library: PIC archive library libc6-prof - GNU C Library: Profiling Libraries libc6-udeb - GNU C Library: Shared libraries - udeb (udeb) libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb) libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb) locales- GNU C Library: National Language (locale) data [support] nscd - GNU C Library: Name Service Cache Daemon Closes: 339389 Changes: glibc (2.3.5-8.1) unstable; urgency=low . * Non-maintainer upload. * Rename sem_trywait to __new_sem_trywait in amd64 nptl code so the alias works properly, and it can be build. (Closes: #339389) Files: 76777c22c40c68fec26fd0900dab4d1f 1840 libs required glibc_2.3.5-8.1.dsc 37f4b6ec393fd85ca0a150f2ba8f6d9b 313414 libs required glibc_2.3.5-8.1.diff.gz 4a6427fa5d118c5a730c1538f13e8ac1 3332026 doc optional glibc-doc_2.3.5-8.1_all.deb ebdbe9db5b8d68cd890f2faf3b958fe7 4060290 base standard locales_2.3.5-8.1_all.deb 5961fc298fe450c21cd2e1f51b34b251 5021164 base required libc6_2.3.5-8.1_i386.deb c1b4a7b3f10e730f0677d967f8e798fc 2684380 libdevel standard libc6-dev_2.3.5-8.1_i386.deb d3b7940b219fd972ce97ac28d3fe53dc 1268444 libdevel extra libc6-prof_2.3.5-8.1_i386.deb 7010d9b99319ea42fa6ad0d14d59551f 1012864 libdevel optional libc6-pic_2.3.5-8.1_i386.deb 34d84841865b00b8d3ccfcfd8886e7e1 1064072 libs extra libc6-i686_2.3.5-8.1_i386.deb 4897d5cfc78b48be0d39812a8cd6f73d 3255640 base required libc6-amd64_2.3.5-8.1_i386.deb 3c08a4c0caa1916f796269628131c516 2000694 libdevel standard libc6-dev-amd64_2.3.5-8.1_i386.deb 3955debb1cefe31f322f8db3cf7fcf54 124972 admin optional nscd_2.3.5-8.1_i386.deb 865c34fe764aef79052b2a95fd9636d6 6530202 libdevel extra libc6-dbg_2.3.5-8.1_i386.deb 9f466c18672e9d4969e0cd7db9cbf08f 704028 debian-installer extra libc6-udeb_2.3.5-8.1_i386.udeb da92f062711281e8b25c8ba3973a406d 8276 debian-installer extra libnss-dns-udeb_2.3.5-8.1_i386.udeb f9d63952af2252cad14d7c02535c6242 14778 debian-installer extra libnss-files-udeb_2.3.5-8.1_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDiaq3QdwckHJElwsRAsJEAJ4tAK3CFdBnDD1mndQyE8KCXxJOtQCdGZ6+ VSjdMewmDm93MgBRtyOOakM= =jty8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339389: glibc: FTBFS on amd64: sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
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]
Bug#339389: glibc: FTBFS on amd64: sem_trywait.S:59: Error: symbol `sem_trywait' is already defined
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 -I/build/buildd/glibc-2.3.5/build-tree/amd64-libc -I../sysdeps/x86_64/elf -I../libidn/sysdeps/unix -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.0.3/include -isystem /build/buildd/glibc-2.3.5/debian/include -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -DIS_IN_libpthread=1 -DASSEMBLER -g -Wa,--noexecstack -o /build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl/sem_trywait.o -MD -MP -MF /build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl/sem_trywait.o.dt -MT /build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl/sem_trywait.o ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S: Assembler messages: ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S:59: Error: symbol `sem_trywait' is already defined make[3]: *** [/build/buildd/glibc-2.3.5/build-tree/amd64-libc/nptl/sem_trywait.o] Error 1 make[3]: Leaving directory `/build/buildd/glibc-2.3.5/build-tree/glibc-2.3.5/np tl' I believe the attached patch should fix it. It now does the same as on i386, and have the real symbol named __new_sem_trywait, and add the weak alias as sem_trywait. With the attached patch it builds, and seems to work fine. Kurt --- nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S.old 2005-11-15 23:09:31.0 +0100 +++ nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S 2005-11-15 23:10:09.0 +0100 @@ -29,10 +29,10 @@ .text - .globl sem_trywait - .type sem_trywait,@function + .globl __new_sem_trywait + .type __new_sem_trywait,@function .align 16 -sem_trywait: +__new_sem_trywait: movl(%rdi), %eax 2: testl %eax, %eax jz 1f
Bug#326561: linux-kernel-headers usbdevice_fs.h broken on amd64
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 is __KERNEL__ only. The rest is probably simular. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325226: libc6: Wrong dynamic linker on amd64.
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 (0x002a9566e000) /lib/ld-linux-x86-64.so.2 (0x002a95556000) ... The ABI says that it should be /lib64/ld-linux-x86-64.so.2, and every other binary and lib does have that, except for things in the libc6 package. Note that that we have a /lib64 - lib symlinks, and that everything should get installed in /lib, it's just that the path in the binaries itself is wrong. I don't think it's really important, but it's probably nice to have this fixed. If you're going to fix this, could you please provide a patch for this so I can test it before you upload it? This bug exists in both sarge (2.3.2.ds1-22) and sid (2.3.5-4). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317946: glibc: causes static builds to fail.
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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317674: libc6: can't link a program with -static
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]
Bug#317946: TLS section mismatch.
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 -ugetppid -uutime -ustrnlen -usiglongjmp -urecvfrom -uopendir -u__strdup -ustderr -uklogctl -usnprintf -uoptind -umemset -uwcschr -usync -uobstack_free -u__stpcpy -ustrcasestr -u__ctype_get_mb_cur_max -uwcrtomb -uindex -ustrcspn -u_nss_files_parse_spent -uopenlog -uaccess -ugrantpt -usetlogmask -uioperm -umunmap -ugetnetbyaddr -umbsinit -uwait -ugetgrnam -upopen -uinet_network -usendmsg -uiswalnum -urename -urealloc -uhasmntopt -uunlockpt -u__strcasecmp -ugetnameinfo -uselect -ugetchar -uscandir64 -urindex -uendservent -ustrdup -uunlink -uisatty -utdelete -ustatfs64 -uwarn -ugettimeofday -uherror -uchdir -uxdecrypt -u__errno_location -ustrerror -uisspace -ufnmatch -usysconf -uaccept -uabort -ufprintf -ustrtoll -ustrlen -ustrncat -uchroot -uclearerr -ugetgroups -ufeof -u__mempcpy -uwrite -urewind -uvasprintf -uopen64 -upwrite64 -u__cxa_finalize -ugethostbyname -uioctl -ugetopt_long -utcgetpgrp -usigdelset -ubind -ustdin -u__rawmemchr -u__xstat -umlockall -u__res_ninit -usetrlimit64 -ubasename -u__sigsetjmp -uuname -ubtowc -ustrtoul -uswapoff -u__xpg_basename -uexeclp -ugetsubopt -ufwrite -ugetpid -usetgid -ufeof_unlocked -ugetpwnam -uexecl -ugetdelim -u_res_hconf -usendto -uexecv -umemchr -umkfifo -usys_siglist -uconnect -ufgets_unlocked -uflock -udirname -u_nss_files_parse_pwent -uendpwent -ureboot -uunsetenv -usetsid -usprintf -u__ctype_b_loc -ustrrchr -uregexec -ugethostbyaddr -ustrchrnul -uasprintf -uferror -ugetcwd -ufree -utfind -urecv -uputchar -u__strtol_internal -utimes -usigsetmask -ugetservbyname -urand -uqsort -ubcopy -u__xstat64 -u__libc_start_main -uopen -ustrncpy -uusleep -unftw -umkdir -usystem -ustrcasecmp -udcgettext -untohs -umemcmp -udprintf -umkstemp64 -ulisten -uswapon -ualphasort64 -usyslog -ustatfs -uvsnprintf -u__assert_fail -ustrtok_r -uwcswidth -usigfillset -ustpcpy -ubindtextdomain -ugeteuid -ufseek -ugetrlimit64 -utsearch -u_obstack_newchunk -urealpath -utolower -utcgetattr -uglob -ustrpbrk -ualarm -upipe -usetvbuf -uscandir -ustrncasecmp -ure_compile_pattern -urandom -u_IO_putc -ulseek64 -usetmntent -ustrtol -ufputc -upause -ustrtok -ustrtod -uumask -ufputs -ufchmod -uregcomp -udup2 -utwalk -uinet_ntop -ustrsep -uinet_ntoa -umemcpy -ufileno -uperror -usrandom -ufscanf -uumount -ustrncmp -umbtowc -ustrcat -ugetsockname -uclose -ustrchr -ufgetpos -uposix_memalign -uvdprintf -ufcntl -u__getdelim -u__lxstat64 -umemalign -usigaction -usetsockopt -ure_match -umallopt -ucloselog -ustrftime -uchmod -utoupper -uhtonl -u_obstack_begin -usigprocmask -uraise -uputs -udup -ureaddir64 -ufread -ustrsignal -uexecvp -u__strtod_internal -umbsrtowcs -uexecve -untohl -umount -ugetrusage -ugetpwuid -uvsprintf -usetuid -umalloc -ustdout -usrand -uwcwidth -urecvmsg -utowlower -uwaitpid -uoptarg -ulongjmp -u__strtok_r -u__ctype_tolower_loc -ucalloc -usetbuf -usetitimer -useekdir -utextdomain -ufopen64 -umempcpy -ulseek -ugetpwent -umallinfo -u__lxstat -ukill -ufflush -ummap64 -u__xmknod -usethostname -ummap -uptsname -usetpriority -ulchown -u_setjmp -uread -udaemon -uustat -ustrstr -uctime -ufsync -umemmove -usignal -uiswpunct -umblen -ufreopen -ustrcmp -ushutdown -urpmatch -ufgetc -upclose -uprintf -uftruncate64 -ureaddir -uglobfree -ugetgid -uendmntent -u_nss_files_parse_grent -uregfree -ufsetpos -u__h_errno_location -uftell -uexit -uasctime -umbstowcs -usetrlimit -ugetpagesize -ugmtime -usymlink -u__strtoul_internal -ugethostname -uregister_printf_function -usysinfo -umunlockall -usocket -ugetpriority -usiginterrupt -ustrcpy -ubsearch -ureadlink -u_exit -usetlocale -uumount2 -uwcscasecmp -usigemptyset -u__fxstat64 -ufopen -uputenv -ufdopen -uvsyslog -uwcslen -urmdir -u__res_state -u__strtoll_internal -ufork -uvprintf -ualphasort -ugetenv -uatoi -ulink -uvfprintf -uatol -uiswblank -ugetnetbyname -uwait4 -u_IO_getc -usbrk -uwait3 -u__cxa_atexit -ustrspn -uungetc -usscanf -ustrndup -usyscall -umbrtowc -uinet_pton -ufgets -upread64 -uhtons -usetenv -ugetopt -umkstemp -uinet_aton -u__strtoull_internal -utcsetattr -uregerror -u__ctype_toupper_loc -usigaddset -uclosedir -ugetegid -uwcsdup -ugetuid -uchown -utime -o ./tmp/monolithic/tree/lib/libc.so.6-so /usr/lib/libc_pic/soinit.o /usr/lib//libc_pic.a /usr/lib/libc_pic/sofini.o /lib//ld-linux-x86-64.so.2 -u __dso_handle -Wl,--version-script=/usr/lib//libc_pic.map -lgcc -L ./tmp/monolithic/tree/lib -L./tmp/monolithic/tree/usr/lib -L./tmp/monolithic/udeblibs -L/lib/ -L/usr/lib/ -L/usr/X11R6/lib/ -L./tmp/monolithic/tree//usr/lib/cdebconf -L./tmp/monolithic/tree//usr/lib/cdebconf -L./tmp/monolithic/tree//usr/lib/cdebconf -L./tmp/monolithic/tree//usr/lib/cdebconf -L./tmp/monolithic/tree//usr/lib/cdebconf
Bug#298247: glibc: Including bits/libc-lock.h for __libc_lock_* fails on nptl system.
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-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 to exist on amd64, probably because we do not have tls and only have nptl. libnss-pgsql builds fine if those 3 includes are removed. That is a bug in libnss-pgsql; __libc_lock_* are not an exported interface, do not use them. So I'm reassigning this to libnss-pgsql. You do have TLS, but tls.h is not and will never be an installed header; ditto the others. Right, I got a little confused about that. The version on i386 seems to look completely different anyway. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298247: glibc: Including bits/libc-lock.h for __libc_lock_* fails on nptl system.
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 to exist on amd64, probably because we do not have tls and only have nptl. libnss-pgsql builds fine if those 3 includes are removed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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, creating a big window during which /lib64 does not exist at all? glibc (libc6) does not replace base-files. Why should it? Last time I looked getting it into glibc I couldn't figure out where to change the rules files to put it in the package so I've never really tried this. Maybe Andreas still knows how he patched it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 a versioned Replaces: base-files and dpkg removes the symlink in base-files before installing the one from glibc, creating a big window during which /lib64 does not exist at all? glibc (libc6) does not replace base-files. Why should it? Because otherwise the upgrade from an already running amd64 system (which has a modified base-files containing the symlink) would result in dpkg complaining about a file conflict. A Replaces field would allow dpkg to move the ownership of the symlink from base-files to libc in a clean way. However, it there is a time window during which /lib64 does not exist at all it will not work that way. I've patched the latest glibc to to provide the symlink. This is what I get: apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded: libc6 libc6-dev 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/8813kB of archives. After unpacking 135kB of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 10369 files and directories currently installed.) Preparing to replace libc6-dev 2.3.2.ds1-18 (using .../libc6-dev_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6-dev ... Preparing to replace libc6 2.3.2.ds1-18 (using ..././libc6_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6 ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/lib64', which is also in package base-files Setting up libc6 (2.3.2.ds1-19) ... Current default timezone: 'Europe/Brussels'. Local time is now: Sun Dec 5 23:19:17 CET 2004. Universal Time is now: Sun Dec 5 22:19:17 UTC 2004. Run 'tzconfig' if you wish to change it. Setting up libc6-dev (2.3.2.ds1-19) ... (Note that is a patched 2.3.2.ds1-19, didn't change the version number yet.) At that point the /lib64 symlink it owned by the libc6 package. Now I just need to be sure how to package this properly so nobody has problems updating libc6 and base-files at the same time. Any hint welcome. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279044: libc6: qsort() doesn't sort for large size
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 UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
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 \
+ { /lib/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
+- { /lib64/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
++ { /lib/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
+ #define SYSDEP_KNOWN_LIBRARY_NAMES \
+ { libc.so.6, FLAG_ELF_LIBC6 }, \
+ { libm.so.6, FLAG_ELF_LIBC6 },
Atleast part of the patch looks totaly wrong to me. Please do
not change the location of the dynamic loader. This is LSB
requirement that it's placed in /lib64. We've argued over this
more than once.
+--- ldd-rewrite.sed 2002-04-09 08:39:14.0 +
glibc-2.3.2/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2004-10-20
12:56:17.929716960 +
+@@ -1,3 +1,3 @@
+ /LD_TRACE_LOADED_OBJECTS=1/a\
+ add_env=$add_env LD_LIBRARY_VERSION=\\$verify_out
+-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \264\4\5\6_
++s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \2\4\5\6_
I have no idea what this does, but I think it's about the same as
the previous one.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
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 changed in the gcc-3.4 archive. But this is what I now get with something I just compiled: ldd test libc.so.6 = /lib/libc.so.6 (0x002a9566d000) /lib/ld-linux-x86-64.so.2 = /lib/ld-linux-x86-64.so.2 (0x002a95556000) While with the pure64 archive with either gcc-3.3 of 3.4 it's still pointing to /lib64/ld-linux-x86-64.so.2 Furthermore, there is no LSB requirement which requires the dynamic loader to be installed in '/lib64' or to be accessible as '/lib64/ld-linux-x86-64.so.2'. The LSB requires that the dynamic loader is accessible through '/lib64/ld-lsb-x86-64.so.2' (note the 'lsb' instead of 'linux' in the You seem to be right on that: | Program Interpreter/Dynamic Linker | | The LSB specifies the Program Interpreter to be /lib64/ld-lsb-x86-64.so.2. middle). This is being taken care of by the 'lsb' package which installs a symlink '/lib64/ld-lsb-x86-64.so.2' which points to '/lib/ld-linux-x86-64-so.2' (actually, the current ^ Should probably atleast be a . version of the 'lsb' package still has a bug which lets the symlink point to '/lib/ld-linux.so.2' instead). I just notices that same bug too. The LSB does not specify anything else regarding the location of the dynamic loader besides that is must be accessible through '/lib64/ld-lsb-x86-64.so.2'. Well, it seems that atleast it doesn't change anything with compliance to the LSB. But I still think it's wrong. Either glibc or gcc, whichever places that hardcoded path, should point to either /lib64/ld-lsb-x86-64.so.2 or /lib64/ld-linux-x86-64.so.2. And since the LSB says it should be /lib64/ld-lsb-x86-64.so.2 I would even say it should be changed to that. Anything else is going to cause problems running our binaries on an other distribution. We should also make sure that programs build on an other distro can be run on debian so I think we also need to have a /lib64/ld-linux-x86-64.so.2 provided in some way. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248192: setpshared on amd64 not working?
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 this to debian/sysdeps/amd64.mk fixes the problem and doesn't seem to be causing any problems so far: GLIBC_PASSES += nptl I'm not sure if any of the other options are needed? Things like adding --with-tls also seem to compile without problems. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248192: setpshared on amd64 not working?
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 this to debian/sysdeps/amd64.mk fixes the problem and doesn't seem to be causing any problems so far: GLIBC_PASSES += nptl I'm not sure if any of the other options are needed? Things like adding --with-tls also seem to compile without problems. Kurt
Bug#248192: setpshared on amd64 not working?
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, pthread_condattr_setpshared(condattr, PTHREAD_PROCESS_SHARED)); prints: 0 38 The same test on i386 returns: 0 0 I find it rather strange because the code says: /* For now it is not possible to shared a conditional variable. */ if (pshared != PTHREAD_PROCESS_PRIVATE) return ENOSYS; Am I missing something? Kurt
Bug#248192: setpshared on amd64 not working?
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 chroot. Presumably setpshared is supported by NPTL and not by LinuxThreads. Right. And I only looed at the linuxthread sources. So the question becomes isn't NPTL build for amd64? It atleast has an x86_64 dir in it. Kurt
Bug#218657: Still problems with df
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 using 64bit or 32bit applications. I don't have an older kernel handy to test if this is a kernel bug or not. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218657: Still problems with df
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 using 64bit or 32bit applications. I don't have an older kernel handy to test if this is a kernel bug or not. Kurt
Bug#245784: Undefined u64 in jiffies.h.
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 sysklogd and should therefor probably be tagged as RC. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245789: Wrong include for mach_mpspec.h and mach_apicdef.h.
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 /usr/include/asm/mach-es7000/mach_mpspec.h /usr/include/asm/mach-generic/mach_mpspec.h /usr/include/asm/mach-numaq/mach_mpspec.h /usr/include/asm/mach-summit/mach_mpspec.h /usr/include/asm/smp.h (i386, line 73) does: #include mach_apicdef.h Which has the same problem. This causes an other build failure for sysklogd. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245797: BITS_TO_LONGS undefined in linux/cpumask.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 subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245784: Undefined u64 in jiffies.h.
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 to __KERNEL__ but I'm not sure. This problem causes a build failure for sysklogd and should therefor probably be tagged as RC. For me, sysklogd_1.4.1-14 is buildable. BTW, why is jiffies.h included? On current sarge? ksys_mod.c includes linux/modules.h and that includes linux/sched.h and that includes linux/jiffies.h. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245784: Undefined u64 in jiffies.h.
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245784: Undefined u64 in jiffies.h.
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 sysklogd and should therefor probably be tagged as RC. Kurt
Bug#245789: Wrong include for mach_mpspec.h and mach_apicdef.h.
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 /usr/include/asm/mach-es7000/mach_mpspec.h /usr/include/asm/mach-generic/mach_mpspec.h /usr/include/asm/mach-numaq/mach_mpspec.h /usr/include/asm/mach-summit/mach_mpspec.h /usr/include/asm/smp.h (i386, line 73) does: #include mach_apicdef.h Which has the same problem. This causes an other build failure for sysklogd. Kurt
Bug#245792: BITS_PER_LONG undefined in linux/bitmap.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
Bug#245797: BITS_TO_LONGS undefined in linux/cpumask.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
Bug#245784: Undefined u64 in jiffies.h.
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 to __KERNEL__ but I'm not sure. This problem causes a build failure for sysklogd and should therefor probably be tagged as RC. For me, sysklogd_1.4.1-14 is buildable. BTW, why is jiffies.h included? On current sarge? ksys_mod.c includes linux/modules.h and that includes linux/sched.h and that includes linux/jiffies.h. Kurt
Bug#245784: Undefined u64 in jiffies.h.
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
Bug#245387: Usage of long long on amd64.
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
@@ -19,8 +19,10 @@
typedef __signed__ int __s32;
typedef unsigned int __u32;
+#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
-typedef unsigned long long __u64;
+typedef unsigned long long __u64;
+#endif
#endif /* __ASSEMBLY__ */
--- include/asm-x86_64/byteorder.h.orig 2004-04-22 23:15:06.162110704 +0200
+++ include/asm-x86_64/byteorder.h 2004-04-22 23:17:36.556247320 +0200
@@ -5,11 +5,13 @@
#ifdef __GNUC__
+#if !defined (__STRICT_ANSI__)
static __inline__ __u64 ___arch__swab64(__u64 x)
{
__asm__(bswapq %0 : =r (x) : 0 (x));
return x;
}
+#endif
static __inline__ __u32 ___arch__swab32(__u32 x)
{
Bug#245387: Usage of long long on amd64.
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
@@ -19,8 +19,10 @@
typedef __signed__ int __s32;
typedef unsigned int __u32;
+#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
-typedef unsigned long long __u64;
+typedef unsigned long long __u64;
+#endif
#endif /* __ASSEMBLY__ */
--- include/asm-x86_64/byteorder.h.orig 2004-04-22 23:15:06.162110704 +0200
+++ include/asm-x86_64/byteorder.h 2004-04-22 23:17:36.556247320 +0200
@@ -5,11 +5,13 @@
#ifdef __GNUC__
+#if !defined (__STRICT_ANSI__)
static __inline__ __u64 ___arch__swab64(__u64 x)
{
__asm__(bswapq %0 : =r (x) : 0 (x));
return x;
}
+#endif
static __inline__ __u32 ___arch__swab32(__u32 x)
{
Bug#243885: Bug#240887: Package building problem.
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 reaffirmed by the POSIX document for
basic regular expressions, which is what POSIX uses to define
shell patterns.
Therefore tetex-bin and autoconf will need to be fixed instead to
not use backslashes in [] expressions.
I read through the entire bug log for 240887 and couldn't figure
out what actual bug in Autoconf is being pointed out. Can anyone
help me out? I can't fix a bug if no one tells me what the bug
is.
configure calls itself in subdirs and tries to pass the
same arguments again.
In configure there is this code:
# Strip out --no-create and --no-recursion so they do not pile
# up.
# Also quote any args containing shell metacharacters.
ac_configure_args=
for ac_arg
do
case $ac_arg in
-no-create | --no-create | --no-creat | --no-crea | --no-cre \
| --no-cr | --no-c) ;;
-no-recursion | --no-recursion | --no-recursio | --no-recursi \
| --no-recurs | --no-recur | --no-recu | --no-rec | --no-re |
--no-r) ;;
* *|* *|*[\[\]\~\#\$\^\\*\(\)\{\}\\\|\;\\\?]*)
ac_configure_args=$ac_configure_args '$ac_arg' ;;
*) ac_configure_args=$ac_configure_args $ac_arg ;;
esac
done
Using dash it's not properly requoting
'--mandir=${prefix}/share/man', it gets turned into
--mandir=${prefix} at the first level and --mandir=/usr/share/man
at the next level.
Using bash it stays '--mandir=${prefix}/share/man'.
I'm not really sure who's to blame for it not working. I think
there is atleast a bug in glibc's fnmatch(). That regex might
also need fixing. But I really don't know what needs to be done.
If I understand Herbert Xu correctly, he's saying the regex
should be written as:
*[][~#$^*(){}\|;?]*
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243885: Bug#240887: Package building problem.
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 reaffirmed by the POSIX document for
basic regular expressions, which is what POSIX uses to define
shell patterns.
Therefore tetex-bin and autoconf will need to be fixed instead to
not use backslashes in [] expressions.
I read through the entire bug log for 240887 and couldn't figure
out what actual bug in Autoconf is being pointed out. Can anyone
help me out? I can't fix a bug if no one tells me what the bug
is.
configure calls itself in subdirs and tries to pass the
same arguments again.
In configure there is this code:
# Strip out --no-create and --no-recursion so they do not pile
# up.
# Also quote any args containing shell metacharacters.
ac_configure_args=
for ac_arg
do
case $ac_arg in
-no-create | --no-create | --no-creat | --no-crea | --no-cre \
| --no-cr | --no-c) ;;
-no-recursion | --no-recursion | --no-recursio | --no-recursi \
| --no-recurs | --no-recur | --no-recu | --no-rec | --no-re |
--no-r) ;;
* *|* *|*[\[\]\~\#\$\^\\*\(\)\{\}\\\|\;\\\?]*)
ac_configure_args=$ac_configure_args '$ac_arg' ;;
*) ac_configure_args=$ac_configure_args $ac_arg ;;
esac
done
Using dash it's not properly requoting
'--mandir=${prefix}/share/man', it gets turned into
--mandir=${prefix} at the first level and --mandir=/usr/share/man
at the next level.
Using bash it stays '--mandir=${prefix}/share/man'.
I'm not really sure who's to blame for it not working. I think
there is atleast a bug in glibc's fnmatch(). That regex might
also need fixing. But I really don't know what needs to be done.
If I understand Herbert Xu correctly, he's saying the regex
should be written as:
*[][~#$^*(){}\|;?]*
Kurt
Re: Bug#240887: Package building problem.
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 closing square bracket, not what
you think it means.
You're quite right. This is reaffirmed by the POSIX document for
basic regular expressions, which is what POSIX uses to define
shell patterns.
For fnmatch it says:
The fnmatch() function shall match patterns as described in the
Shell and Utilities volume of IEEE Std 1003.1-2001, Section 2.13.1,
Patterns Matching a Single Character, and Section 2.13.2, Patterns
Matching Multiple Characters.
Which says:
The pattern matching notation described in this section is used to
specify patterns for matching strings in the shell. Historically,
pattern matching notation is related to, but slightly different from,
the regular expression notation described in the Base Definitions
volume of IEEE Std 1003.1-2001, Chapter 9, Regular Expressions. For
this reason, the description of the rules for this pattern matching
notation are based on the description of regular expression notation,
modified to include backslash escape processing.
[...]
A backslash character shall escape the following character.
The escaping backslash shall be discarded.
[...]
The description of basic regular expression bracket expressions in the
Base Definitions volume of IEEE Std 1003.1-2001, Section 9.3.5, RE
Bracket Expression shall also apply to the pattern bracket expression
That says:
The
right-bracket ( ']' ) shall lose its special meaning and represent
itself in a bracket expression if it occurs first in the list
(after an initial circumflex ( '^' ), if any).
[...]
The special characters '.' , '*' , '[' , and '\' (period, asterisk,
left-bracket, and backslash, respectively) shall lose their
special meaning within a bracket expression.
After reading all that you have to get confused about what [\[\]\\] means.
At the highest level it says that the '\' should be discarded,
so you end up with [[]\] and look at that as a normal regular
expression? Atleast that is how I interpret things.
But testing this shows that this program:
#include fnmatch.h
int main()
{
printf(%d\n, fnmatch([\\]a], a, 0));
printf(%d\n, fnmatch([\\]a], \\, 0));
printf(%d\n, fnmatch([\\]a], ], 0));
printf(%d\n, fnmatch([]a], a, 0));
printf(%d\n, fnmatch([]a], ], 0));
return 0;
}
returns:
1
1
0
0
0
This does _not_ make sense to me in any way. If the 3rd line says
there is a match, I would think it's interpreting it as []a],
but then the first line should match too.
Ps: On other platforms I get:
0
1
0
0
0
One returned:
1
1
1
0
0
Which atleast make a little more sense.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243885: Bug#240887: Package building problem.
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 of case patterns and fnmatch, quote removal is not performed. You mean fnmatch() gets called with the FNM_NOESCAPE flag? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
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 closing square bracket, not what
you think it means.
You're quite right. This is reaffirmed by the POSIX document for
basic regular expressions, which is what POSIX uses to define
shell patterns.
For fnmatch it says:
The fnmatch() function shall match patterns as described in the
Shell and Utilities volume of IEEE Std 1003.1-2001, Section 2.13.1,
Patterns Matching a Single Character, and Section 2.13.2, Patterns
Matching Multiple Characters.
Which says:
The pattern matching notation described in this section is used to
specify patterns for matching strings in the shell. Historically,
pattern matching notation is related to, but slightly different from,
the regular expression notation described in the Base Definitions
volume of IEEE Std 1003.1-2001, Chapter 9, Regular Expressions. For
this reason, the description of the rules for this pattern matching
notation are based on the description of regular expression notation,
modified to include backslash escape processing.
[...]
A backslash character shall escape the following character.
The escaping backslash shall be discarded.
[...]
The description of basic regular expression bracket expressions in the
Base Definitions volume of IEEE Std 1003.1-2001, Section 9.3.5, RE
Bracket Expression shall also apply to the pattern bracket expression
That says:
The
right-bracket ( ']' ) shall lose its special meaning and represent
itself in a bracket expression if it occurs first in the list
(after an initial circumflex ( '^' ), if any).
[...]
The special characters '.' , '*' , '[' , and '\' (period, asterisk,
left-bracket, and backslash, respectively) shall lose their
special meaning within a bracket expression.
After reading all that you have to get confused about what [\[\]\\] means.
At the highest level it says that the '\' should be discarded,
so you end up with [[]\] and look at that as a normal regular
expression? Atleast that is how I interpret things.
But testing this shows that this program:
#include fnmatch.h
int main()
{
printf(%d\n, fnmatch([\\]a], a, 0));
printf(%d\n, fnmatch([\\]a], \\, 0));
printf(%d\n, fnmatch([\\]a], ], 0));
printf(%d\n, fnmatch([]a], a, 0));
printf(%d\n, fnmatch([]a], ], 0));
return 0;
}
returns:
1
1
0
0
0
This does _not_ make sense to me in any way. If the 3rd line says
there is a match, I would think it's interpreting it as []a],
but then the first line should match too.
Ps: On other platforms I get:
0
1
0
0
0
One returned:
1
1
1
0
0
Which atleast make a little more sense.
Kurt
Bug#243885: Bug#240887: Package building problem.
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 of case patterns and fnmatch, quote removal is not performed. You mean fnmatch() gets called with the FNM_NOESCAPE flag? Kurt
Bug#242122: No weak symbol for res_* on amd64.
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 in the affected configure scripts, then. I believe
autoconf 2.5x is capable of handling this correctly.
Openssh 3.8p1-2 is using autoconf 2.52 and has the problem, krb5
1.3.2 is even using 2.59.
krb5 for instance returns this:
checking for res_search... no
checking for res_search in -lresolv... no
configure: error: Cannot find resolver support routine res_search in -lresolv.
make: *** [configure-stamp] Error 1
The test program looks like:
| char res_search ();
| int
| main ()
| {
| res_search ();
| ;
| return 0;
| }
Without resolv.h it will not find __res_search, with resolv.h it
will fail to compile because of too few arguments to function.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242122: No weak symbol for res_* on amd64.
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 reason. If I remove that #if then I properly get the weak symbols. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242122: No weak symbol for res_* on amd64.
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, 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 reason. If I remove that #if then I properly get the weak symbols. Why do you believe the weak symbols should be there? 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_*. I see 2 ways of fixing this, either fix all packages that depend on libresolv or add the weak symbols. PS: I've also found this post: http://mail.gnu.org/archive/html/bug-hurd/2002-05/msg00256.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#240726: Packaging failed during build.
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'. touch /usr/src/glibc-2.3.2.ds1/stamp-dir/binaryinst_locales Running debhelper for libc6 dh_testroot dh_installdirs -plibc6 dh_install -plibc6 cp: cannot stat `./debian/tmp-libc/usr/lib/gconv/gconv-modules': No such file or directory dh_install: command returned error code 256 make: *** [/usr/src/glibc-2.3.2.ds1/stamp-dir/binaryinst_libc6] Error 1 Build command 'cd glibc-2.3.2.ds1 dpkg-buildpackage -b -uc' failed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
