Bug#490530: libc6: gethostbyaddr() times out if reverse dns not found
This one time, at band camp, Thue Janus Kristensen said:
I noticed that when I tried pinging kalus.dk (which does not have
reverse DNS at the time of writing), ping would only send a packet
every 5 seconds.
connect(4, {sa_family=AF_FILE, path=/var/run/avahi-daemon/socket}, 110) = 0
write(4, RESOLVE-ADDRESS 89.233.27.15\n, 29) = 29
read(4,
[***Here there is a 5 second wait***]
-15 Timeout reached\n, 1024) = 20
close(4)= 0
Not that glibc doesn't have similar problems, but surely that's an avahi
bug?
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: tzdata 2007i
This one time, at band camp, José Ildefonso Camargo Tolosa said: Hi! Is there a chance that you include tzdata 2007i. I live in Venezuela, and on Sunday, December 9, we will have a new hour (dumb government ideas). Anyway, I saw that the new tz data is in tzdata 2007i. That seems reasonable to me. Ccing the tzdata maintainers on this reply. Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: tzdata 2007i
This one time, at band camp, Clint Adams said: On Sun, Dec 09, 2007 at 12:08:10PM +, Stephen Gran wrote: This one time, at band camp, José Ildefonso Camargo Tolosa said: Is there a chance that you include tzdata 2007i. I live in Venezuela, and on Sunday, December 9, we will have a new hour (dumb government ideas). Anyway, I saw that the new tz data is in tzdata 2007i. That seems reasonable to me. Ccing the tzdata maintainers on this reply. Actually, 2007j is the one to use. 2007i is about 3 weeks incorrect. Would you (the plural you, the glibc maintainers) be willing to prepare an upload to volatile for this issue, and send a patch to this list? Thanks very much, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#425404: nscd: free's invalid pointer, causing calling program to abort
Package: nscd Version: 2.3.6.ds1-13 Severity: important So I get this output: *** glibc detected *** free(): invalid pointer: 0x2ae2a531bf80 *** /usr/bin/da-backup: line 184: 360 Aborted (core dumped) rsync -varzH -e ssh -i /root/.ssh/da_svn --delete --delete-after --ignore-errors /srv/svn.debian.org/svn/ [EMAIL PROTECTED]:irrelevant/ A backtrace of the core file shows: #0 0x2ae2a511107b in raise () from /lib/libc.so.6 No symbol table info available. #1 0x2ae2a511284e in abort () from /lib/libc.so.6 No symbol table info available. #2 0x2ae2a5147629 in __libc_message () from /lib/libc.so.6 No symbol table info available. #3 0x2ae2a514e193 in _int_free () from /lib/libc.so.6 No symbol table info available. #4 0x2ae2a514e21e in free () from /lib/libc.so.6 No symbol table info available. #5 0x2ae2a51d974a in nscd_getpw_r () from /lib/libc.so.6 No symbol table info available. #6 0x2ae2a51d97e6 in __nscd_getpwuid_r () from /lib/libc.so.6 No symbol table info available. #7 0x2ae2a5173066 in getpwuid_r@@GLIBC_2.2.5 () from /lib/libc.so.6 No symbol table info available. #8 0x2ae2a517293f in getpwuid () from /lib/libc.so.6 No symbol table info available. #9 0x00427397 in uid_to_name (uid=36855) at uidlist.c:68 pass = (struct passwd *) 0x4a99bafb5 #10 0x004279bb in add_uid (uid=36855) at uidlist.c:249 list = (struct idlist *) 0x0 #11 0x0041db93 in send_file_entry (file=0x2ae2a99b8ad8, f=4) at flist.c:424 So it appears the breakage is in nscd. Let me know you if there is any more information I can supply. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-xen-amd64 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Versions of packages nscd depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries nscd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421037: libc6: SIGILL on upgrade on netwinder
This one time, at band camp, Aurelien Jarno said: | Preparing to replace libc6 2.3.6.ds1-11 (using .../archives/libc6_2.5-4_arm.deb) ... | Unpacking replacement libc6 ... | dpkg: error processing /var/cache/apt/archives/libc6_2.5-4_arm.deb (--unpack): | dpkg: warning - old post-removal script killed by signal (Illegal instruction) This is on a netwinder (SA-110) running 2.6.xx. Would it be possible to get access to such a machine? Or at least get the illegal instruction with gdb. Without that much information I won't be able to debug it, as it seems to be SA-110 specific, I mean it works correctly here and also on tbm machine. Contact Vince Sanders [EMAIL PROTECTED] or Steve MacIntyre [EMAIL PROTECTED] - they both have netwinders, IIRC. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#419480: locales: bad dependency; uninstallable
Package: locales Version: 2.5-2 Severity: serious locales Depends line is: Depends: glibc-2.5-1, debconf | debconf-2.0 Thanks, -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) (ignored: LC_ALL set to en_US.utf8) (ahem) Shell: /bin/sh linked to /bin/bash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy pn glibc-2.3.6.ds1-1 none (no description available) And the missing one that the broken dependencies don't notice: ii libc6 2.5-1 GNU C Library: Shared libraries locales recommends no packages. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
This one time, at band camp, Sven Luther said:
The code yielding to this was of the kind of :
struct tm tm;
time_t t;
t = time(NULL);
localtime (t, tm);
This is in a fr_FR.utf8 locale, on a powerpc box. The same code on an x86 box
just segfaults without error message.
That doesn't even compile here:
#include time.h
#include stdlib.h
int main (void) {
struct tm tm;
time_t t;
t = time(NULL);
localtime (t, tm);
exit(0);
}
[EMAIL PROTECTED]:~$ gcc -Wall t.c
t.c: In function ‘main’:
t.c:8: error: too many arguments to function ‘localtime’
[EMAIL PROTECTED]:~$
This code works fine, though:
#include time.h
#include stdlib.h
int main (void) {
struct tm *tm;
time_t t;
t = time(NULL);
tm = localtime (t);
exit(0);
}
[EMAIL PROTECTED]:~$ gcc -Wall t.c
[EMAIL PROTECTED]:~$ LC_ALL=fr_FR.utf8 ./a.out
[EMAIL PROTECTED]:~$
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed
This one time, at band camp, Sven Luther said:
And indeed, like i said, it worked fine 100s of times, and then died. Try :
int main (void) {
struct tm tm;
time_t t;
while (1) {
t = time(NULL);
localtime_r (t, tm);
}
exit(0);
}
[EMAIL PROTECTED]:~$ cat t.c
#include time.h
#include stdlib.h
int main (void) {
struct tm tm;
time_t t;
while (1) {
t = time(NULL);
localtime_r (t, tm);
}
exit(0);
}
[EMAIL PROTECTED]:~$ gcc -Wall t.c
[EMAIL PROTECTED]:~$ time LC_ALL=fr_FR.utf8 ./a.out
real1m21.381s
user1m1.716s
sys 0m18.985s
No crash. This is x86, but ppc is the same.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Bug#416442: libc6: Wrong groups applied to user
This one time, at band camp, Fabio Pugliese Ornellas said: Oh, sorry. I guess I should bug report on groupadd that let me add groups that would not work... It's not a bug in groupadd. It's a limitation in sarge's glibc. It is now fixed. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#416442: libc6: Wrong groups applied to user
This one time, at band camp, Fabio Pugliese Ornellas said: Hello, I have been expiriencing some gorup problems. The best way to explain, is showing this: [snip] As you can see, the group list differs. And the list that is actually applying is the shortest one. So, the user have not enough rights to work. In theory, both command should output exactly the same groups. Yes, sarge's glibc had a fixed length of 32 for group membership. There is still a fixed length in etch, but it is much bigger. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#330105: libc6-dev: __FD_SETSIZE equals to 1024 is too small
This one time, at band camp, Pierre HABOUZIT said: I also have a hard time understanding why having 1000+ virtualhosts in apache would create such problems (except if you listen of 1000+ different ports btw, but I don't think it would be a very clever setup anyway :]) Because you have an open fd per virtual host for logfiles. Whether apache has all the fd's open itself, or it pushes the logs to a named pipe that does the splitting for apache, something still has all those fd's open and you can run into this fairly quickly. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#355916: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
This one time, at band camp, Frans Pop said: On console I had the following lines from the upgrade: INIT: version 2.86 reloading __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) VM: killing process localedef That is the kernel killing a process because you ran out of memory. This is nothing to do with locales. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#349610: Processed: severity of 354856 is important
I didn't notice this go by earlier, sorry. I already filed this as #349610, severity normal at the time since amd64 wasn't a release candidate. I actually filed it against linux-kernel-headers/glibc since that's where the real problem seems to be, butwhichever way it's handled is fine so long as it's fixed. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#349610: linux-kernel-headers: conflicting types for int64_t and u_int64_t on amd64
Package: linux-kernel-headers Version: 2.6.13+0rc3-2 Severity: normal In file included from /usr/include/asm/types.h:8, from /usr/include/linux/fb.h:4, from video.c:38: /usr/include/asm-x86_64/types.h:23: error: conflicting types for 'int64_t' /usr/include/sys/types.h:194: error: previous declaration of 'int64_t' was here /usr/include/asm-x86_64/types.h:24: error: conflicting types for 'u_int64_t' /usr/include/sys/types.h:200: error: previous declaration of 'u_int64_t' was here If you feel that libc is wrong, feel free to reassign it. If you need additional information, plesae ask. Thanks, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339482: patch to fix dpkg usage in glibc when /usr isnt mounted yet
This one time, at band camp, higuita said:
Hi
tested in debian mips, works fine in my machines
replaced all (but one already commented) dpkg call with plain and old
if tests
in the end, checking if the machine is running the correct architecture
is hard to check and should be extremely rare, so i tweak it up and
comment it
I think your logic in the checks is off. Imagine this:
ver=2.6.14
if [ ${K_MAJOR} -lt 2 ] || [ ${K_MINOR} -lt 4 ] || [ ${K_REV} -lt 19 ] || [
${ver[4]} == -pa17 ]
false falsetrue
false
evaluates to true, I would think.
This particular test is a little difficult6 to rewrite so
straightforwardly (evaluating the string bit at the end is not trivial)
The other tests are fairly straightforward and could be replaced things
like:
if [ ${K_MAJOR} -le 2 ] [ ${K_MINOR} -le 4 ] [ ${K_REV} -lt 19 ]
This tests pretty accurately that the numeric part is less than 2.4.19.
Once you start also testing for extensions like -pa17, it will get much
harder to handle. Additionally, the == construct is a bashism. Better
to use = for string tests or -eq for integer tests.
Take care,
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
This one time, at band camp, Edward Buck said: In this case, the algorithm does not match the specification. Therefore, it's a bug. Quoting the man page: Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. IPv6 queries are not excluded from this description. The fact is that with this bug, resolver queries with MORE than ndots are ALWAYS attempted using each component of the search path. Yes, the queries are IPv6 but that does not matter. If you read further down the man page: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. There's no ambiguity in the term 'absolute query'. A lookup for the IPv6 address example.com.domain.in.search.path is NOT an initial absolute query no matter how you look at it. Unless of course you missed the part of the report where the query under discussion has greater than ndots in it. The original query under discussion was mx1.hotmail.com, and ndots was unset, so defaulted to 1. There are 2 dots in mx1.hotmail.com, so the search order was correctly used. That it defaulted to ipv6 first is the only thing really left for discussion, it seems to me. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. HTH, and take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
This one time, at band camp, Edward Buck said: If you do a 'strace telnet mx1.hotmail.com 25' on a woody machine, you'll see that it works according to the documentation. Sarge does not. I can forward you more strace output if it will help. Maybe all my woody machines are weird. I don't know. But as I said, this functionality is new with sarge. I took the easy way out, and turned on query logging in my local caching nameserver (since that also helps to see exactly what the load is on the nameserver, the point of this bug, really). This is what I see: Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com IN Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com.lobefin.net IN Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com IN A [ followed by normal PTR lookups for the records returned ] Which is exactly what it should be. This is a sarge system. Maybe you didn't notice that the extra lookups were IPv6? IIRC woody didn't have a working IPv6 stack out of the box, so this would explain the behavior you're seeing. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
This one time, at band camp, Steve Langasek said:
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote:
When looking at the assembly code generated with gcc-3.3/gcc-3.4 and
with gcc-4.0, I see some differences:
I also don't speak hppa assembly, but it is obvious that the code does
not use the same registers. Maybe the bug is in gcc which generates
wrong code? At least the same source code built with gcc-3.3 and gcc-3.4
is working correctly.
No, it isn't:
glibc (2.3.5-6.0.1) unstable; urgency=low
* On hppa, build using gcc-3.4.
-- Matthias Klose [EMAIL PROTECTED] Sat, 17 Sep 2005 10:55:42 +
This is the version of libc6 running on the buildd and in paer's unstable
chroot where I reproduced the error. So glibc is known to have problems on
hppa when built with gcc-4.0, but this doesn't appear to be one of them.
I think you are misunderstanding him, Steve, or I am misunderstanding
the whole thing (which is not unlikely). I think Aurelian is saying
that the same source code that you supplied builds and runs fine with
gcc-3.4, but not with gcc-4.0:
[EMAIL PROTECTED]:~$ dchroot sid
Executing shell in chroot: /org/paer.debian.org/chroot/sid
[EMAIL PROTECTED]:~$ cat test.c
#include fenv.h
int main() {
int foo;
fenv_t fenv;
feholdexcept(fenv);
}
[EMAIL PROTECTED]:~$ gcc-3.4 -lm test.c -o test.3.4
[EMAIL PROTECTED]:~$ gcc-4.0 -lm test.c -o test.4
[EMAIL PROTECTED]:~$ ./test.3.4
[EMAIL PROTECTED]:~$ ./test.4
Bus error
This certainly smells more like a compiler bug than anything. The same
library and the same header files, 2 different compiler versions, 2
results.
Take care,
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Bug#203303: This is not grave
Package: libc6-dev Version: 2.3.2.ds1-10 Severity: normal Followup-For: Bug #203303 It looks like the problem is that these various KDE programs are using -ansi, and -ansi implies -fno-asm. This in itself wouldn't be the problem, but: The -ansi option does not cause non-ISO programs to be rejected gratuitously. For that, -pedantic is required in addition to -ansi. - taken from the FM. It appears that at least my program is building fine on many arches that it previously failed on once I removed the -ansi and -pedantic lines. I have not yet tested kdemultimedia. So, I would say that while it would be great if the linux-kernel-headers package could provide ansi compliant headers, I realize that that will not be trivial to implement, and as there appears to be a functional workaround, I suggest downgrading to important or normal. If you agree, please do so. I will cc: Chris on this as well, so he knows that there are wokrarounds at least. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux busybox 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-9 Linux Kernel Headers for developme -- no debconf information -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#203303: Reopening - not fixed for many non-i386 arches
This one time, at band camp, GOTO Masanori said: Hi, At Thu, 6 Nov 2003 22:33:33 -0500, Stephen Gran wrote: This bug is fixed on i386, and it looks like hppa as well. However it is still broken on ia64, alpha and powerpc At Fri, 7 Nov 2003 09:20:05 -0500, Stephen Gran wrote: It looks like it is also a problem on mipsel, arm and sparc. This bug is caused by kdemultimedia compilation flag -pedantic + -ansi. If I removed these flags from all configure settings on alpha, then the compilation becomed ok. (But it failed at kmidi.cpp on alpha if I removed -pedantic - it's another bug of kdemultimedia?): Actually, I maintain kcdlabel, a KDE program that #includes linux/cdrom.h and so gets bitten by the same bugs as kdemultimedia. I will try without -pedantic and see if that helps. BTW, I would like to know why ISO C++ forbits braced-groups. The thing is, they managed to fix this for at least i386 by making sure that some pieces of asm/byteorder.h (IIRC) weren't pulled in in userspace apps, but were reserved for kernel level things - I think this is ultimately the smart way to go for all arches. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp5Hlxj0aRJ5.pgp Description: PGP signature
Bug#203303: Reopening - not fixed for many non-i386 arches
This one time, at band camp, GOTO Masanori said: Hi, At Thu, 6 Nov 2003 22:33:33 -0500, Stephen Gran wrote: This bug is fixed on i386, and it looks like hppa as well. However it is still broken on ia64, alpha and powerpc At Fri, 7 Nov 2003 09:20:05 -0500, Stephen Gran wrote: It looks like it is also a problem on mipsel, arm and sparc. This bug is caused by kdemultimedia compilation flag -pedantic + -ansi. If I removed these flags from all configure settings on alpha, then the compilation becomed ok. (But it failed at kmidi.cpp on alpha if I removed -pedantic - it's another bug of kdemultimedia?): Actually, I maintain kcdlabel, a KDE program that #includes linux/cdrom.h and so gets bitten by the same bugs as kdemultimedia. I will try without -pedantic and see if that helps. BTW, I would like to know why ISO C++ forbits braced-groups. The thing is, they managed to fix this for at least i386 by making sure that some pieces of asm/byteorder.h (IIRC) weren't pulled in in userspace apps, but were reserved for kernel level things - I think this is ultimately the smart way to go for all arches. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Bug#203303: More architectures
expressions /usr/include/linux/byteorder/swab.h: In function `__u16 __swab16p(__u16*)': /usr/include/linux/byteorder/swab.h:137: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:137: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `void __swab16s(__u16*)': /usr/include/linux/byteorder/swab.h:141: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:141: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `const __u32 __fswab32(unsigned int)': /usr/include/linux/byteorder/swab.h:146: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:146: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `__u32 __swab32p(__u32*)': /usr/include/linux/byteorder/swab.h:150: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:150: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `void __swab32s(__u32*)': /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions Thanks again, -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux busybox 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-8 Linux Kernel Headers for developme -- no debconf information -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#203303: More architectures
expressions /usr/include/linux/byteorder/swab.h: In function `__u16 __swab16p(__u16*)': /usr/include/linux/byteorder/swab.h:137: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:137: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `void __swab16s(__u16*)': /usr/include/linux/byteorder/swab.h:141: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:141: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `const __u32 __fswab32(unsigned int)': /usr/include/linux/byteorder/swab.h:146: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:146: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `__u32 __swab32p(__u32*)': /usr/include/linux/byteorder/swab.h:150: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:150: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `void __swab32s(__u32*)': /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions Thanks again, -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux busybox 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-8 Linux Kernel Headers for developme -- no debconf information -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#203303: Reopening - not fixed for many non-i386 arches
/usr/include/linux/byteorder/swab.h:150: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `void __swab32s(__u32*)': /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions Thanks so much for working on this, -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux busybox 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-8 Linux Kernel Headers for developme -- no debconf information -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#203303: Reopening - not fixed for many non-i386 arches
/usr/include/linux/byteorder/swab.h:150: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h: In function `void __swab32s(__u32*)': /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions /usr/include/linux/byteorder/swab.h:154: error: ISO C++ forbids braced-groups within expressions Thanks so much for working on this, -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux busybox 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to en_US.ISO-8859-1) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-8 Linux Kernel Headers for developme -- no debconf information -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#203303: glibc: gcc3.3 complains swab.h fails to conform to ISO standard
This one time, at band camp, Stephen Gran said:
Could you try new glibc 2.3.2-2?
Still fails. -fpermissive downgrades it to a warning, allowing the
build to complete, though, so at least there's a workaround.
Scratch that. -fpermissive no longer allows it to build - I just didn't
wait long enough to get to the part that fails. It seems that the ISO
C++ issue has been resolved, only to be replaced by a new one. Some
change in this version gives me a new error:
In file included from /usr/include/linux/cdrom.h:14,
from audiocd.h:33,
from cddbaccessdialog.h:31,
from cddbaccessdialogdata.cpp:10:
/usr/include/asm/byteorder.h:38: error: syntax error before `(' token
/usr/include/asm/byteorder.h:42: error: '__u64' is used as a type, but is not
defined as a type.
/usr/include/asm/byteorder.h:43: error: syntax error before `}' token
/usr/include/asm/byteorder.h:44: error: syntax error before `.' token
/usr/include/asm/byteorder.h:50: error: syntax error before `.' token
/usr/include/asm/byteorder.h:51: error: syntax error before `.' token
/usr/include/asm/byteorder.h:52: error: syntax error before `:' token
In file included from /usr/include/linux/byteorder/little_endian.h:11,
from /usr/include/asm/byteorder.h:65,
from /usr/include/linux/cdrom.h:14,
from audiocd.h:33,
from cddbaccessdialog.h:31,
from cddbaccessdialogdata.cpp:10:
/usr/include/linux/byteorder/swab.h:199: error: syntax error before `(' token
/usr/include/linux/byteorder/swab.h:209: error: syntax error before `(' token
/usr/include/linux/byteorder/swab.h:213: error: `__u64' was not declared in
this scope
/usr/include/linux/byteorder/swab.h:213: error: `addr' was not declared in this
scope
/usr/include/linux/byteorder/swab.h:214: error: variable or field `__swab64s'
declared void
/usr/include/linux/byteorder/swab.h:214: error: `__swab64s' declared as an
`inline' variable
/usr/include/linux/byteorder/swab.h:214: error: syntax error before `{' token
The relevant lines from byteorder.h are (lines 38-53):
static inline __u64 ___arch__swab64(__u64 val)
{
union {
struct { __u32 a,b; } s;
__u64 u;
} v;
v.u = val;
#ifdef CONFIG_X86_BSWAP
asm(bswapl %0 ; bswapl %1 ; xchgl %0,%1
: =r (v.s.a), =r (v.s.b)
: 0 (v.s.a), 1 (v.s.b));
#else
v.s.a = ___arch__swab32(v.s.a);
v.s.b = ___arch__swab32(v.s.b);
asm(xchgl %0,%1 : =r (v.s.a), =r (v.s.b) : 0 (v.s.a), 1 (v.s.b));
#endif
and swab.h (lines 198-216):
#ifdef __BYTEORDER_HAS_U64__
static __inline__ __const__ __u64 __fswab64(__u64 x)
{
# ifdef __SWAB_64_THRU_32__
__u32 h = x 32;
__u32 l = x ((1ULL32)-1);
return (((__u64)__swab32(l)) 32) | ((__u64)(__swab32(h)));
# else
return __arch__swab64(x);
# endif
}
static __inline__ __u64 __swab64p(__u64 *x)
{
return __arch__swab64p(x);
}
static __inline__ void __swab64s(__u64 *addr)
{
__arch__swab64s(addr);
}
I must say I don't immediately see the problem there. Perhaps we're
barking up the wrong tree here, and this is a problem with g{cc,++}
barfing on perfectly good code?
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgp0.pgp
Description: PGP signature
Bug#203303: glibc: gcc3.3 complains swab.h fails to conform to ISO standard
This one time, at band camp, GOTO Masanori said: At Mon, 4 Aug 2003 19:31:31 -0400, Stephen Gran wrote: FWIW, I'm getting exactly the same behavior here, trying to build a new version of one of my packages that #include's linux/cdrom.h ii libc6-dev 2.3.1-17 GNU C Library: Development Libraries and Hea Could you try new glibc 2.3.2-2? Still fails. -fpermissive downgrades it to a warning, allowing the build to complete, though, so at least there's a workaround. And I think it's not glibc problem. If you still get errors with 2.3.2-2, please reassign it to kernel-headers-2.4.21-3. I see why you say that - it is a kernel header, but it's getting installed by libc6-dev. steve:~$ dpkg -S /usr/include/linux/cdrom.h libc6-dev: /usr/include/linux/cdrom.h I am building in a pbuilder chroot, no kernel headers installed there. However, if you think that because the header originally comes from the kernel, that's where it belongs, you can reassign. Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Bug#203303: glibc: gcc3.3 complains swab.h fails to conform to ISO standard
FWIW, I'm getting exactly the same behavior here, trying to build a new version of one of my packages that #include's linux/cdrom.h ii libc6-dev 2.3.1-17 GNU C Library: Development Libraries and Hea Thanks for the good work, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpv1AvgPIhxL.pgp Description: PGP signature
Bug#183081: libc6-dev: hppa: bug in byteorder.h and swab.h
On Mon, Mar 03, 2003 at 07:30:15AM +1100, Herbert Xu said: Stephen Gran [EMAIL PROTECTED] wrote: Ah, I see that now. I checked with dpkg -S, but didn't look further. Because of what appear to be largely syntactic errors in these two headers, the build failed, but only on hppa. I guess this needs to be reassigned to the kernel. Sorry about that. No you should close this. User space programs must not include kernel headers. I'm happy to close it here, but it's not the user space program explicitly including these headers - they're being brought in by recursive #includes: In file included from /usr/include/linux/cdrom.h:14, from audiocd.h:33, from cddbaccessdialog.h:31, from cddbaccessdialogdata.cpp:10: /usr/include/asm/byteorder.h: cddbaccessdialogdata.cpp includes cddbaccessdialog.h, which includes audiocd.h, and so forth until /usr/include/asm/byteorder.h is finally brought in. It's not an error in this program, and it builds fine on other architectures - there's clearly some problem with the headers on hppa. It's only that the headers do not come from your package (although dpkg -S reported tat they did), and so I apologize for bugging the wrong package. I will close this. -- -- | Stephen Gran | This is a good time to punt work. | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | -- pgp0.pgp Description: PGP signature
