Bug#1067760: libc6: Curious behavior of inet_pton() on IPv4 mapped numbers
On Tue, Mar 26, 2024 at 12:53:42PM +0100, Alessandro Vesely wrote: > I compiled the example program given in the inet_pton(3) man page, and obtain > the following: > $ ./a.out i6 0:0:0::5.6.7.8 > Not in presentation format This is no valid IPv6 address. Where did you find that? Bastian -- "Get back to your stations!" "We're beaming down to the planet, sir." -- Kirk and Mr. Leslie, "This Side of Paradise", stardate 3417.3
gcc displaying bullshit allocation numbers? (was: Re: Ability to further support 32bit architectures)
Hi On Thu, Jan 11, 2024 at 10:25:39AM +0100, Bastian Blank wrote: > Linux 6.7 fails to build on at least i386 and armhf. Even it now > manages to make the compiler fail to allocate memory: > | cc1: out of memory allocating 135266296 bytes after a total of 235675648 > bytes I just tried to find out what this numbers actually mean. The first on is the allocation amount, so correct. The printf spec is however wrong, as the variable is a size_t (%zu) and not unsigned long (%lu). The second one is the return value of "sbrk(0) - $saved sbrk value". https://github.com/gcc-mirror/gcc/blob/master/libiberty/xmalloc.c#L125-L132 The glibc malloc(3), which seems to be used in the background, uses both brk(2) and malloc(2), so you can't really see how much you have ever allocated using this technique. Am I right in this? Bastian -- "Life and death are seldom logical." "But attaining a desired goal always is." -- McCoy and Spock, "The Galileo Seven", stardate 2821.7
Bug#1060202: glibc - autopkgtest flacky on arm64
Package: glibc Version: 2.37-13 Severity: important Currently the autopkgtest on arm64 fails sometimes. Timeout while building: https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/ Failed test: https://ci.debian.net/packages/g/glibc/testing/arm64/40439311/ -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Bug#1040140: libc6: upgrade libc6 to version 2.37-3 break plasma desktop (X11/Wayland)
Hi On Sun, Jul 02, 2023 at 03:12:21PM +0200, antonio wrote: > Kernel: Linux 6.3.11-2-liquorix-amd64 (SMP w/24 CPU threads; PREEMPT) This is no Debian. You have to verify that on Debian. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, "The Omega Glory", stardate unknown
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote: > Some stupid questions that I couldn't answer by reading the man page > or doing a quick google search > * How does ld.so --preload *work*? ld.so is the ELF interpreter. If you run a normal binary, the kernel rewrites this request to load and execute /lib64/ld-linux-x86-64.so.2 instead. This interpreter then loads the real binary, the libraries and jumps to the real code. If you run ld.so directly, that kernel redirection is just not done. The rest of it's tasks however are done just as usual. --preload is just as if the interpreter would see LD_PRELOAD set. > * Does it modify /bin/ls, so that all users running /bin/ls get the > preloaded library? No, preload does not modify binary files, just the loaded binary in memory. > * Does it modify something in the user's home directory? No. > * How do you undo the effects ld.so --preload? You just don't use ld.so and don't set LD_PRELOAD. Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote: > Right, thanks for providing a concrete example. A (somewhat) portable > version would look like this: > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl You mean ld.so --preload libeatmydata.so.1.3.0 /bin/ls ? ld.so is able to find the correct path itself. So only looking up the correct ld.so implementation would be needed. Bastian -- Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
Bug#966173: libc6: __atan2_finite reference in dlopened module no longer found in executable linked to libm
On Fri, Jul 24, 2020 at 10:11:04AM +0100, Simon McVittie wrote:
> The bug (#966150) is that a version of uix86_64.so compiled with a slightly
> older (2020-02-18) toolchain fails to load on an up-to-date sid system, with:
> undefined symbol: __atan2_finite
Because the binary was not linked with -lm, the linker never saw the
real symbol __atan2_finite@GLIBC2_16, so the linke only emitted a reference
to __atan2_finite. At least dpkg-shlibdeps or so should warn about that.
> I've been trying to put together a standalone reproducer that only uses
> libdl and libm, but so far I have not been successful.
Something like that?
| % cat test.c
| void __atan2_finite(void);
| void test(void) {
| __atan2_finite();
| }
| % gcc --shared -o test.so test.c -Wall -W
| % objdump -x test.so | grep atan
| *UND* __atan2_finite
Regards,
Bastian
--
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Sun, Nov 26, 2017 at 09:13:52AM +0100, Bastian Blank wrote: > It seems that ldconfig does not force the collation to a value that > would make it use the claimed sorting. ldconfig: -> setlocale (LC_ALL, "") -> glob() -> qsort(strcoll-equiv) Other occurances of similar bugs: https://bugs.debian.org/600310 Bastian -- One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Sun, Nov 26, 2017 at 01:03:58AM +0100, Aurelien Jarno wrote: > I am still unable to reproduce this problem. On my system > lib/x86_64-linux-gnu/ is preferred over lib64. ldconfig uses glob to to > interpret the "*.conf" in /etc/ld.so.conf, so the files are sorted > alphabetically and thus the zz_amd64-biarch-compat.conf should appear > last. There exists locales where this claim is false: | $ LC_COLLATE=et_EE.UTF-8 ls -al /etc/ld.so.conf.d | total 20 | drwxr-xr-x 2 root root 4096 Nov 26 08:07 . | drwxr-xr-x 82 root root 4096 Nov 21 09:34 .. | -rw-r--r-- 1 root root 38 Jun 26 2016 fakeroot-x86_64-linux-gnu.conf | -rw-r--r-- 1 root root 44 Mär 20 2016 libc.conf | -rw-r- 1 root root0 Nov 26 08:07 zz.conf | -rw-r--r-- 1 root root 68 Jul 26 2016 x86_64-linux-gnu.conf It seems that ldconfig does not force the collation to a value that would make it use the claimed sorting. Bastian -- Actual war is a very messy business. Very, very messy business. -- Kirk, "A Taste of Armageddon", stardate 3193.0
Bug#817988: libc6-dev: libm.so no longer a symlink in 2.22-2 ; break dlopen() in mpi4py
On Sat, Mar 12, 2016 at 11:51:32AM +, Alastair McKinstry wrote: > /usr/lib/$ARCH/libm.so is no longer a symlink in 2.22-2, thus breaking > packages > which try to use it. *.so is for use by ld, and is a linker script in this case. It have been the case for libc.so for ages. > In particular, mpi4py dynamically links libm.so leading an FTBFS #817884 Dynamic linking uses the _abiname_, which is libm.so.6 in this case, but is may be libm.so.6.1 or libm.so.0.3 in other cases. Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board
On Wed, May 13, 2015 at 04:23:42PM +0200, Aurelien Jarno wrote: Alternatively as it triggers a segmentation fault, this could probably be trapped and emulated in the kernel, just like it's done for the FPU on some architectures. The official erata list[1] tells us: | Problem: When a memory instruction with LOCK prefix executes and if it | encounters a page fault (#PF) the state of the CPU could potentially get | corrupted. There is no documented other outcome of such an operation, so can't be fixed up. The Intel SDK just stripped generating LOCK prefixes in the compiler. Bastian [1]: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/quark-x1000-spec-update.pdf -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, The Enemy Within, stardate unknown -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150514150040.ga7...@mail.waldi.eu.org
Bug#755734: libc-bin - ldconfig fails if dirent-d_type is not correct
Package: libc-bin Version: 2.19-7 Severity: normal ldconfig uses the d_type field in the readdir(2) result as optimization. If the field wrongly identifies symlinks as regular files, ldconfig assumes that lstat(2) returns the same than stat(2) and aborts if it is not the case. It does - call lstat, use this information to search the cache, - call stat in readelf.c#process_file and override the old information, - try to insert the new entry; this entry already exists and it calls abort. The 9p filesystem wrongly reports symlinks as regular files, so it triggers this condition. Bastian -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc-bin depends on: ii libc62.19-7 ii libcap2 1:2.22-1.2 libc-bin recommends no packages. libc-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722205613.25423.62560.report...@rockhammer.waldi.eu.org
Bug#753084: locales: wish it would take advantage of multiple cores
On Sun, Jun 29, 2014 at 03:11:28PM +1000, Russell Coker wrote: The process of generating all locales takes a huge amount of time. It would be good if it could run multiple processes to take advantage of multi-core systems. Also it would be good if there was an option to generate one locale for each language. Did you miss the existence on locales-all, which includes all locales already? Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140629082817.ga23...@mail.waldi.eu.org
Bug#722217: dead in the water
Control: reassign -1 libgl1-nvidia-legacy-173xx-glx On Tue, Oct 08, 2013 at 09:11:46AM -0400, Brent S. Elmer Ph.D. wrote: On Mon, 2013-10-07 at 00:16 +0200, Bastian Blank wrote: On Sun, Oct 06, 2013 at 05:52:01PM -0400, Brent S. Elmer Ph.D. wrote: emacs, and sensord are segfaulting in libnvidia-tls. And what happens without this weird library? I don't know what the library is or what happens without it or even how to get rid of it. It is part of the binary-only nvidia driver. I'm reassigning this bug to the correct package. Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, Requiem for Methuselah, stardate 5842.8 -- 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/20131219063352.ga28...@mail.waldi.eu.org
Bug#727841: powl() inaccurate but only at runtime
On Sun, Oct 27, 2013 at 03:57:14PM +, Zefram wrote: Version: 2.13-38 The current version of libc6 is 2.17-93. On amd64, powl() is generating inaccurate results when called at runtime, but if a call to it gets constant-folded at compile time (by gcc 4.7) then the constant-folded result is much more accurate. The current version of gcc used by the main architectures is 4.8. $ gcc t0.c -lm $ echo | ./a.out 0x8.5f0468293f0ebc30p-993 0x8.5f0468293f0eb4e0p-993 | $ gcc-4.8 -o t0 -Wall -W -O2 t0.c -lm | $ echo | ./t0 | 0x8.5f0468293f0eb4e0p-993 | 0x8.5f0468293f0eb4e0p-993 Bastian -- We Klingons believe as you do -- the sick should die. Only the strong should live. -- Kras, Friday's Child, stardate 3497.2 -- 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/20131027161231.ga13...@mail.waldi.eu.org
Bug#722217: dead in the water
On Sun, Oct 06, 2013 at 05:52:01PM -0400, Brent S. Elmer Ph.D. wrote: emacs, and sensord are segfaulting in libnvidia-tls. And what happens without this weird library? Bastian -- Every living thing wants to survive. -- Spock, The Ultimate Computer, stardate 4731.3 -- 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/20131006221618.gc26...@mail.waldi.eu.org
Re: Fwd: Bug report on eperl: eperl crashes with exit status 139 [origin: alexan...@cmu.edu]
On Thu, Jun 27, 2013 at 01:07:13AM +0200, Axel Beckert wrote: #3 0x770e5783 in getopt_long (argc=1, argv=0x7fffe228, options=0x0, long_options=0x1, opt_index=0x0) at getopt1.c:66 Why are the options and long_options arguments shown with nonsense contents? Bastian -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, Wolf in the Fold, stardate 3615.4 -- 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/20130626231125.ga23...@mail.waldi.eu.org
Bug#712899: libc6 - Inconsistency detected by ld.so on s390/s390x
Package: libc6
Version: 2.17-6
Severity: important
Some part of the dynlinker produces an assertion:
| Inconsistency detected by ld.so: rtld.c: 1307: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_libname-next == ((void *)0)' failed!
Not all binaries are affected. apt-get, dpkg, sudo and zsh still work, so
installation of packages is still possible. strace and all the maintainer
scripts of libc6 fail in various states:
| subprocess new post-removal script returned error exit status 127
| Inconsistency detected by ld.so: rtld.c: 1307: dl_main: Assertion
`_rtld_local._dl_rtld_map.l_libname-next == ((void *)0)' failed!
| dpkg: error while cleaning up:
| subprocess installed pre-installation script returned error exit status 127
strace output for a maintainer script:
| execve(/var/lib/dpkg/info/libc6:s390.postrm,
[/var/lib/dpkg/info/libc6:s390.po..., upgrade, 2.17-3], [/* 32 vars */])
= 0
| brk(0) = 0x78f000
| writev(2, [{Inconsistency detected by ld.so:..., 33}, {rtld.c, 6}, {: ,
2}, {1307, 4}, {: , 2}, {dl_main, 7}, {: , 2}, {Assertion `, 11},
{_rtld_local._dl_rtld_map.l_libna..., 55}, {' failed!\n, 10}], 10) = 132
| exit_group(127) = ?
Bastian
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
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/20130620165425.2650.5468.report...@rockhammer.waldi.eu.org
Bug#712899: libc6 - Inconsistency detected by ld.so on s390/s390x
Control: retitle -1 libc6 - Inconsistency detected by ld.so on s390 On Thu, Jun 20, 2013 at 06:54:25PM +0200, Bastian Blank wrote: Not all binaries are affected. apt-get, dpkg, sudo and zsh still work, so installation of packages is still possible. strace and all the maintainer scripts of libc6 fail in various states: Ah. The s390 ld.so is broken. s390x works fine. strace is still s390 on one system and the other is completely s390. Bastian -- Beam me up, Scotty! -- 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/20130620195011.ga27...@mail.waldi.eu.org
Bug#712899: libc6 - Inconsistency detected by ld.so on s390/s390x
Control: retitle -1 libc6 - Inconsistency detected by ld.so on s390/s390x On Thu, Jun 20, 2013 at 09:50:11PM +0200, Bastian Blank wrote: Ah. The s390 ld.so is broken. s390x works fine. strace is still s390 on one system and the other is completely s390. Wrong. Both are broken. This looks like a problem with non-null bss. Bastian -- Mind your own business, Spock. I'm sick of your halfbreed interference. -- 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/20130620195313.gb27...@mail.waldi.eu.org
Bug#649265: provide coordinated mechanism to manage /etc/nsswitch.conf among packages
On Sat, Apr 13, 2013 at 04:42:30PM -0700, C.J. Adams-Collier wrote: I am working on a project to migrate a number of NIS machines to use Active Directory user and group management, authentication and authorization. The following is an excerpt from a script we are using to update the CentOS 5 hosts, and I will likely use most of it for Debian and Ubuntu since there is not really a better option: There is. It is called augeas. Bastian -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, Where No Man Has Gone Before, stardate 1312.9. -- 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/20130414101428.ga29...@waldi.eu.org
Bug#149452: libc: Need OpenBSD's bcrypt password hashing support for dovecot
Please fix your line length. On Sun, Mar 24, 2013 at 07:33:49PM -0700, Joel Lopes Da Silva wrote: I would like to use bcrypt (BLF-CRYPT) for my password scheme in Dovecot, but I can't because bcrypt support doesn't seem to have been integrated into the Debian libc. Why do you want bcrypt? glibc support sha256 und sha512, which uses several thousand rounds of hashing and should be good enough. Here's the list of supported password schemes by Dovecot on my Debian Wheezy machine: # doveadm pw -l CRYPT MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN CLEARTEXT PLAIN-TRUNC CRAM-MD5 HMAC-MD5 DIGEST-MD5 PLAIN-MD4 PLAIN-MD5 LDAP-MD5 LANMAN NTLM OTP SKEY RPA SHA256-CRYPT SHA512-CRYPT Please explain what this should tell us. Bastian -- Change is the essential process of all existence. -- Spock, Let That Be Your Last Battlefield, stardate 5730.2 -- 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/20130325101354.gb5...@waldi.eu.org
Bug#684794: getaddrinfo sorts IPv4 before IPv6
On Mon, Aug 13, 2012 at 10:54:28PM +0200, Per Olofsson wrote: I recently configured IPv6 connectivity on my system using 6to4 on my router. It works, except that getaddrinfo() sorts IPv4 addresses before IPv6 addresses, which means that IPv4 is used if the remote host has both IPv4 and IPv6. This is expected behaviour if you are using 2002::/16 addresses: |Rule 7: Prefer native transport. |If DA is reached via an encapsulating transition mechanism (e.g., |IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB |is reached via encapsulation and DA is not, then prefer DA. $ getent ahosts www.debian.org 86.59.118.148 STREAM www.debian.org 86.59.118.148 DGRAM 86.59.118.148 RAW 2001:858:2:2:214:22ff:fe0d:7717 STREAM 2001:858:2:2:214:22ff:fe0d:7717 DGRAM 2001:858:2:2:214:22ff:fe0d:7717 RAW | $ getent ahosts www.debian.org | 2001:858:2:2:214:22ff:fe0d:7717 STREAM www.debian.org | 2001:858:2:2:214:22ff:fe0d:7717 DGRAM | 2001:858:2:2:214:22ff:fe0d:7717 RAW | 86.59.118.148 STREAM | 86.59.118.148 DGRAM | 86.59.118.148 RAW Bastian -- Vulcans do not approve of violence. -- Spock, Journey to Babel, stardate 3842.4 -- 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/20120814103823.ga8...@wavehammer.waldi.eu.org
Bug#659064: libc6 - Includes file in /lib64
On Wed, Feb 08, 2012 at 12:09:31AM +0100, Aurelien Jarno wrote: On Wed, Feb 08, 2012 at 12:05:20AM +0100, Bastian Blank wrote: On Tue, Feb 07, 2012 at 11:36:09PM +0100, Aurelien Jarno wrote: And I don't see the relation with #514015, given the /lib64 - /lib has disappeared. It exists in the filesystem as relict from the old package. We have a preinst script making sure it is replaced from a symlink to a directory. There is not preinst script running in the early stages of the bootstrap. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, The Menagerie, stardate 3012.4 -- 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/20120208091434.gb7...@wavehammer.waldi.eu.org
Bug#659064: full story
Okay, here the whole story as I understand it. The OP bootstrapped a Squeeze system. This includes the ./lib64 - /lib symlink. After that, the OP bootstrapped a Wheezy system over the existing Squeeze root. This includes the dir ./lib64 and the symlink ./lib64/ld-linux-x86-64.so.2 in the tar file of the libc6 package. After the bootstrap, the system dynamic linker was overwritten. The old tar accepts that ./lib64 exists and overwrites /lib/ld-linux-x86-64.so.2 in the process. Current tar seems to remove the symlink first if it wants to extract a directory, so this should not longer happen with the tar in Wheezy. Because neither dpkg, nor any of the bootstrap tools handles the case of symlink vs. directory correctly, there was an informal decision, including the release team, that base packages just should not do that. Now I'm told that you decided to change the variables of this problem by actually turning lib64 into a directory. Bastian -- History tends to exaggerate. -- Col. Green, The Savage Curtain, stardate 5906.4 -- 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/20120208094201.ga8...@wavehammer.waldi.eu.org
Bug#659064: libc6 - Includes file in /lib64
Package: libc6 Version: 2.13-24 Severity: important libc6 includes the file /lib64/ld-linux-x86-64.so.2. It was decided that this should not happen, because neither dpkg nor any of the bootstrap tools handles this properly. See #514015 for further informations. Bastian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-24 ii libgcc1 1:4.6.2-12 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.41 ii glibc-doc none ii locales2.13-24 -- debconf information excluded -- 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/20120207221342.30918.12804.report...@lumphammer.waldi.eu.org
Bug#659064: libc6 - Includes file in /lib64
On Tue, Feb 07, 2012 at 11:36:09PM +0100, Aurelien Jarno wrote: And I don't see the relation with #514015, given the /lib64 - /lib has disappeared. It exists in the filesystem as relict from the old package. However tar in Wheezy handles this better by first removing the symlink while extracting a directory. Bastian -- Without followers, evil cannot spread. -- Spock, And The Children Shall Lead, stardate 5029.5 -- 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/20120207230520.ga32...@wavehammer.waldi.eu.org
Bug#603102: After update of libc6 from 2.7-18lenny4 to 2.7-18lenny6, virtual machines (VirtualBox) unable to start.
On Wed, Nov 10, 2010 at 11:20:06PM +0100, Ján Rusnák wrote: VM is started with command: nohup VBoxHeadless -startvm machine --vrdp config After update of libc6 to 2.7-18lenny6, starting virtual machine return this error: VBoxHeadless: supR3HardenedMainGetTrustedMain: dlopen(/opt/virtualbox/VBoxHeadless.so,) failed: VBoxXPCOM.so: cannot open shared object file: No such file or directory. After donwgrade libc6 to 2.7-18lenny4 machines start succesfully. VirtualBox used the mechanism that proofed unsafe. Use the packaged version. Bastian -- Fascinating, a totally parochial attitude. -- Spock, Metamorphosis, stardate 3219.8 -- 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/2010115920.gc22...@wavehammer.waldi.eu.org
Bug#600310: wrong collation(?) order for et_EE.UTF-8 causes regexps to fail matching randomly
On Sat, Oct 16, 2010 at 01:47:42AM +0400, Michael Tokarev wrote: There's a bug in et_EE.UTF-8 locale definition causing some latin chars to be treated as non-letters. These are at least in range t..y inclusive, i.e. [t-y]. Like this: Are you sure that the letters t to y a valid in the alphabet used by the estonian language? Wikipedia shows the following alphabet: a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, š, z, ž, t, u, v, w, õ, ä, ö, ü, x, y So a-z matches only half the alphabet. t to y are _after_ z. I.e., the latin letter t does not match [a-z] regexp. As expected. Use the character classes if you want all small characters. This is a critical issue unfortunately, because it makes various regex failing to match, breaking random components. In the actual problem case the issue were that many cron jobs were not running on the system for a mysterious reason, and the problem was because cron uses a regexp to filter invalid cronjob names, which is /^[a-zA-Z0-9_-]+$/. If you want ascii rules, force LC_ALL=C or at least LC_COLLATE=C. So cron is the culprit. Bastian -- Landru! Guide us! -- A Beta 3-oid, The Return of the Archons, stardate 3157.4 -- 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/20101016100501.ga25...@wavehammer.waldi.eu.org
Bug#579917: mkhomedir segfaults within ld.so on startup
On Sun, May 02, 2010 at 11:44:56AM +0200, Andreas Barth wrote: on an squeeze machine: LD_DEBUG=all /lib/ld-2.10.2.so ./mkhomedir_helper 6625: file=/tmp/mkhomedir_helper [0]; generating link map 6625: dynamic: 0x004001c0 base: 0x size: 0x000139e0 6625: entry: 0x004008f0 phdr: 0x00400034 phnum: 9 6625: Segmentation fault | gabrielli% LD_DEBUG=all /lib/ld.so.1 /sbin/mkhomedir_helper | 10223: file=/sbin/mkhomedir_helper [0]; generating link map | 10223: dynamic: 0x004001c0 base: 0x size: 0x000139e0 | 10223: entry: 0x004008f0 phdr: 0x00400034 phnum: 9 | 10223: | zsh: segmentation fault LD_DEBUG=all /lib/ld.so.1 /sbin/mkhomedir_helper | gabrielli% ls -al /sbin/mkhomedir_helper | -rwxr-xr-x 1 root root 16384 18. Feb 11:49 /sbin/mkhomedir_helper The reported size (0x000139e0) is much larger than the actual binary size. Bastian -- The idea of male and female are universal constants. -- Kirk, Metamorphosis, stardate 3219.8 -- 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/20100502102332.ga18...@wavehammer.waldi.eu.org
Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails
severity 563882 important
retitle 563882 ia64: memchr overshots
thanks
On Tue, Jan 26, 2010 at 01:48:34PM -0600, Jonathan Nieder wrote:
severity 563882 critical
Please explain. git is neither unrelated to glibc nor does this cause
serious data loss.
That is, it maps the file into memory and looks for null bytes.
No, the kernel always maps complete pages, so this maps several null
bytes.
Then this program would lie to you and say “M.out is binary”
The test program does not properly show what is going on.
The following program shows the cause:
| #include sys/stat.h
| #include sys/mman.h
| #include fcntl.h
|
| int main(int argc, const char * const argv[])
| {
| struct stat st;
| lstat(argv[1], st);
|
| int fd = open(argv[1], O_RDONLY);
| void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
| void *t = memchr(data, 0, st.st_size);
| printf(ptr: %p, ret: %p, len: 0x%zx\n, data, t, st.st_size);
| return 0;
| }
Example output:
| % ./test /etc/passwd
| ptr: 0x2005, ret: 0x2005040e, len: 0x40e
The found location is already after the buffer. memchr is AFAIK expanded
by gcc.
Bastian
--
Where there's no emotion, there's no motive for violence.
-- Spock, Dagger of the Mind, stardate 2715.1
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545179: libc6: postinst must run telinit u
On Mon, Sep 07, 2009 at 12:36:08AM +0200, Piotr Kaczuba wrote: W dniu 06.09.2009 13:25, Bastian Blank pisze: On Sat, Sep 05, 2009 at 04:20:55PM +0200, Piotr Kaczuba wrote: The postinst script must run telinit u so that init re-executes itself. Otherwise, on reboot, the old libc won't be properly deleted. Please show your test results. This would mean that the kernel is not able to properly deallocate inodes in use by init. See also bug #25444. This bug is over 10 years and many, many kernel and glibc releases old. Please explain why the behaviour is still the same. [...] No sophisticated test results are needed, really. Just do an upgrade of libc and see what happens on reboot. Init is still using the old libc and the read-only remount of / fails with mount: / is busy. That is expected as there are writes pending. However you have to show that this is a real problem. I really can't explain you why the behaviour is still the same. The mentioned bug shows a different problem. Anyway, before removing telinit u from the postinst script, you should have checked yourself that it's not needed any more. No. You have to show that it is a bug in the first place. Bastian -- That unit is a woman. A mass of conflicting impulses. -- Spock and Nomad, The Changeling, stardate 3541.9 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545179: libc6: postinst must run telinit u
On Sat, Sep 05, 2009 at 04:20:55PM +0200, Piotr Kaczuba wrote: The postinst script must run telinit u so that init re-executes itself. Otherwise, on reboot, the old libc won't be properly deleted. Please show your test results. This would mean that the kernel is not able to properly deallocate inodes in use by init. See also bug #25444. This bug is over 10 years and many, many kernel and glibc releases old. Please explain why the behaviour is still the same. Bastian -- Oblivion together does not frighten me, beloved. -- Thalassa (in Anne Mulhall's body), Return to Tomorrow, stardate 4770.3. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544145: libc6-i686 - Segfaults on amd64/xen
reassign 544145 linux-2.6 2.6.30-1 thanks On Sat, Aug 29, 2009 at 10:57:40PM +0200, Bastian Blank wrote: On Sat, Aug 29, 2009 at 11:31:43AM +0200, Bastian Blank wrote: Hmm, just below the dynlinker, we have the vdso. vdso was the point. I'm pretty sure that it is a problem either in the kernel or in the hypervisor. A check in the Xen source show the following changeset, which is missing in this hypervisor: | user:Keir Fraser keir.fra...@citrix.com | date:Fri Dec 05 15:21:59 2008 + | files: xen/arch/x86/x86_64/compat/entry.S | description: | x86/32on64: adjust address when converting syscall to fault Looks like the problem is caught. Will check this tomorrow. Was not a fix. Also it is still broken in Xen 3.4.1. Bastian -- It is more rational to sacrifice one life than six. -- Spock, The Galileo Seven, stardate 2822.3 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544145: libc6-i686 - Segfaults on amd64/xen
Package: libc6-i686 Version: 2.9-25 Severity: important The last upgrade of my i386 chroot pulled in libc6-i686. After that all binaries started to segfault: | [ 38.652407] sh[3131]: segfault at 0 ip (null) sp ffb9a138 error 14 in bash[8048000+be000] | [ 236.958701] ls[3650]: segfault at af7f22000 ip 000af7f22000 sp ff992390 error 14 | [ 252.066863] ls[3651]: segfault at af7fde000 ip 000af7fde000 sp ff8745f0 error 14 A removal of libc6-i686 or disabling via /etc/ld.so.nohwcap got the system into a usable state again. The system uses a amd64 kernel and userland on Xen. Bastian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.31-rc8-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-i686 depends on: ii libc6 2.9-25 GNU C Library: Shared libraries libc6-i686 recommends no packages. libc6-i686 suggests no packages. -- It is more rational to sacrifice one life than six. -- Spock, The Galileo Seven, stardate 2822.3 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544145: libc6-i686 - Segfaults on amd64/xen
On Sat, Aug 29, 2009 at 10:33:24AM +0200, Aurelien Jarno wrote:
On Sat, Aug 29, 2009 at 09:14:40AM +0200, Bastian Blank wrote:
The system uses a amd64 kernel and userland on Xen.
This flavour works perfectly on a non-Xen system. is there also some
requirements on the compilation of glibc on Xen amd64, like on i386?
Not that I'm aware of. But the memory layout may be different.
Debugging a live binary is impossible as it already breaks before the
debugging setup.
A core file shows:
| #0 0xf7fb1000 in ?? ()
| #1 0xf7e0bdc8 in _init () at
/build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:24
This seems to come from /lib/i686/cmov/libpthread.so.0
| #2 0xf7fbf284 in call_init (l=0xf7dfd720, argc=1, argv=0xffa03094,
env=0xffa0309c) at dl-init.c:70
| #3 0xf7fbf416 in _dl_init (main_map=0xf7fce670, argc=1, argv=0xffa03094,
env=0xffa0309c) at dl-init.c:100
| #4 0xf7fb188f in _dl_start_user () from /lib/ld-linux.so.2
| (gdb) up
| #1 0xf7e0bdc8 in _init () at
/build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:24
| 24
/build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:
No such file or directory.
| in
/build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S
| Current language: auto; currently asm
| (gdb) disassemble
| Dump of assembler code for function _init:
| 0xf7e0bdc0 _init+0: push %ebp
| 0xf7e0bdc1 _init+1: mov%esp,%ebp
| 0xf7e0bdc3 _init+3: call 0xf7e0c380
__pthread_initialize_minimal_internal
| 0xf7e0bdc8 _init+8: call 0xf7e0c2c0 frame_dummy
| 0xf7e0bdcd _init+13: call 0xf7e18040 __do_global_ctors_aux
| 0xf7e0bdd2 _init+18: pop%ebp
| 0xf7e0bdd3 _init+19: ret
| End of assembler dump.
| (gdb) disassemble 0xf7e0c2c0
| Dump of assembler code for function frame_dummy:
This function seems to come from gcc.
| 0xf7e0c2c0 frame_dummy+0: push %ebp
| 0xf7e0c2c1 frame_dummy+1: mov%esp,%ebp
| 0xf7e0c2c3 frame_dummy+3: push %ebx
| 0xf7e0c2c4 frame_dummy+4: call 0xf7e0c230 __i686.get_pc_thunk.bx
| 0xf7e0c2c9 frame_dummy+9: add$0x11d2b,%ebx
| 0xf7e0c2cf frame_dummy+15:sub$0x4,%esp
| 0xf7e0c2d2 frame_dummy+18:mov-0x214(%ebx),%edx
| 0xf7e0c2d8 frame_dummy+24:test %edx,%edx
| 0xf7e0c2da frame_dummy+26:je 0xf7e0c2f1 frame_dummy+49
| 0xf7e0c2dc frame_dummy+28:mov-0x28(%ebx),%edx
| 0xf7e0c2e2 frame_dummy+34:test %edx,%edx
| 0xf7e0c2e4 frame_dummy+36:je 0xf7e0c2f1 frame_dummy+49
| 0xf7e0c2e6 frame_dummy+38:lea-0x214(%ebx),%eax
| 0xf7e0c2ec frame_dummy+44:mov%eax,(%esp)
| 0xf7e0c2ef frame_dummy+47:call *%edx
| 0xf7e0c2f1 frame_dummy+49:add$0x4,%esp
| 0xf7e0c2f4 frame_dummy+52:pop%ebx
| 0xf7e0c2f5 frame_dummy+53:pop%ebp
| 0xf7e0c2f6 frame_dummy+54:ret
| 0xf7e0c2f7 frame_dummy+55:nop
| 0xf7e0c2f8 frame_dummy+56:nop
| 0xf7e0c2f9 frame_dummy+57:nop
| 0xf7e0c2fa frame_dummy+58:nop
| 0xf7e0c2fb frame_dummy+59:nop
| 0xf7e0c2fc frame_dummy+60:nop
| 0xf7e0c2fd frame_dummy+61:nop
| 0xf7e0c2fe frame_dummy+62:nop
| 0xf7e0c2ff frame_dummy+63:nop
| End of assembler dump.
| (gdb) print {char[4]}0xf7fb1000
| $7 = \177ELF
Hmm, just below the dynlinker, we have the vdso. If I debug a binary
without using the i686/cmov libs then I miss the symbols for the vdso
so, it looks like they are never used.
Bastian
--
It would be illogical to assume that all conditions remain stable.
-- Spock, The Enterprise Incident, stardate 5027.3
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544145: libc6-i686 - Segfaults on amd64/xen
On Sat, Aug 29, 2009 at 11:31:43AM +0200, Bastian Blank wrote:
Hmm, just below the dynlinker, we have the vdso.
vdso was the point. However I don't know what the real problem is. A
minimal failing program is:
| int main() {
| unsigned int resultvar;
| asm volatile (
| movl %1, %%eax\n\t
| call *%%gs:0x10\n\t
| : =a (resultvar)
| : i (0) : memory, cc);
| }
This just calls the syscall 0 through the vdso and on my system this
produces the following:
| (gdb) run
| Starting program: /test
|
| Program received signal SIGSEGV, Segmentation fault.
| 0xf7fdf42f in __kernel_vsyscall ()
| (gdb) bt
| #0 0xf7fdf42f in __kernel_vsyscall ()
| #1 0xf7fd6ff4 in ?? () from /lib/libc.so.6
| #2 0xf7eb07a5 in __libc_start_main (main=0x8048394 main, argc=1,
ubp_av=0xd884, init=0x80483d0 __libc_csu_init,
| fini=0x80483c0 __libc_csu_fini, rtld_fini=0xf7fee6e0 _dl_fini,
stack_end=0xd87c) at libc-start.c:222
| #3 0x08048301 in _start () at ../sysdeps/i386/elf/start.S:119
| (gdb) disassemble
| Dump of assembler code for function __kernel_vsyscall:
| 0xf7fdf420 __kernel_vsyscall+0: push %ebp
| 0xf7fdf421 __kernel_vsyscall+1: mov%ecx,%ebp
| 0xf7fdf423 __kernel_vsyscall+3: syscall
| 0xf7fdf425 __kernel_vsyscall+5: mov$0x2b,%ecx
| 0xf7fdf42a __kernel_vsyscall+10: mov%ecx,%ss
| 0xf7fdf42c __kernel_vsyscall+12: mov%ebp,%ecx
| 0xf7fdf42e __kernel_vsyscall+14: pop%ebp
| 0xf7fdf42f __kernel_vsyscall+15: ret
| End of assembler dump.
If I debug a binary
without using the i686/cmov libs then I miss the symbols for the vdso
so, it looks like they are never used.
This binaries don't use the vdso in the INLINE_SYSCALL macro.
A check in the Xen source show the following changeset, which is missing
in this hypervisor:
| user:Keir Fraser keir.fra...@citrix.com
| date:Fri Dec 05 15:21:59 2008 +
| files: xen/arch/x86/x86_64/compat/entry.S
| description:
| x86/32on64: adjust address when converting syscall to fault
|
| The faulting address is at the start of the syscall instruction rather
| than at the following one.
Looks like the problem is caught. Will check this tomorrow.
Bastian
--
Sometimes a feeling is all we humans have to go on.
-- Kirk, A Taste of Armageddon, stardate 3193.9
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.2 (was Please test eglibc 2.9-23+multiarch.1)
On Mon, Aug 03, 2009 at 02:02:24AM +0200, Aurelien Jarno wrote: I have finally decided to remove the Depends: line in libc-bin, even if I don't really like that. My tests show that it works now, but don't hesitate to test it on your machine. What happens if someone install libc-bin without a new libc6 then? Forgot about that variant before as it is not forbidden by deps now. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, Today I will be brilliant. -- Kirk, The Ultimate Computer, stardate 4731.3 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.2 (was Please test eglibc 2.9-23+multiarch.1)
On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote: Bastian Blank a écrit : What happens if someone install libc-bin without a new libc6 then? Forgot about that variant before as it is not forbidden by deps now. If it is not the same major version, it will probably break, I'll add a conflict to fix that, but I fear we are going to have the same problem with apt again... Yep. So I'm also out of options. The question is, how badly will it break the binaries in the package. Bastian -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, The Squire of Gothos, stardate 2124.5 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.1
On Thu, Jul 30, 2009 at 06:02:29PM +0200, Aurelien Jarno wrote: We have the constraints that we should support upgrades from Lenny, so we are stuck with apt/aptitude from lenny... Remove the dependency from libc-bin. As long a libc-bin does not have maintainer scripts, this should work. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536085: locales: ru_RU.UTF8 collate UKR-GHE incorrectly
On Tue, Jul 07, 2009 at 10:58:56PM +0400, eshkin...@gmail.com wrote: Bastian Blank wa...@debian.org writes: You have to describe _why_ it is wrong. Different languages may have different collation rules. Yes, i try :) Yes, different languages have different collation, but ru_RU.UTF8 locale is unicode locale and as i can understand this table: http://unicode.org/charts/collation/chart_Cyrillic.html Where is the reference to the russian language? why after U0453 ? This is mistake, IMHO. Please present evidence in form of official documents for the russian language. According to wikipedia[1], this letter is not used in russian anyway. Bastian [1]: http://en.wikipedia.org/wiki/List_of_Cyrillic_letters -- Warp 7 -- It's a law we can live with. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533077: linux-image-2.6.26-2-486: on an idle system /dev/random gets depleted very quick
On Mon, Jun 15, 2009 at 10:47:43AM +0200, Folkert van Heusden wrote: Now add strace to those commands. Do you see the problem? Nope, works as expected: You have different libs than we all have. Ours shows: | open(/dev/urandom, O_RDONLY) = 3 | read(3, \34\344C\242, 4) = 4 | close(3)= 0 Bastian -- Not one hundred percent efficient, of course ... but nothing ever is. -- Kirk, Metamorphosis, stardate 3219.8 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#533077: linux-image-2.6.26-2-486: on an idle system /dev/random gets depleted very quick
On Mon, Jun 15, 2009 at 11:44:07AM +0200, Aurelien Jarno wrote: Bastian Blank a écrit : On Mon, Jun 15, 2009 at 10:47:43AM +0200, Folkert van Heusden wrote: Now add strace to those commands. Do you see the problem? Nope, works as expected: You have different libs than we all have. Ours shows: | open(/dev/urandom, O_RDONLY) = 3 | read(3, \34\344C\242, 4) = 4 | close(3)= 0 Note that it is fixed in glibc 2.10 with kernels = 2.6.29. No. The bugreport is about random depletion, because the glibc uses it. This is not fixed. Bastian -- No more blah, blah, blah! -- Kirk, Miri, stardate 2713.6 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527230: libc6: segfaults in libc-2.9.so when executing cyrus-imapd
On Wed, May 06, 2009 at 11:02:24AM +0200, Guenter Trimmel wrote: Package: libc6 Version: 2.9-4 Severity: critical Justification: breaks unrelated software A tool linking the libc is _never_ unrelated software. Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, Elaan of Troyius, stardate 4372.5 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526823: libc6 2.9-9 broke DNS resolver again
On Mon, May 04, 2009 at 11:55:22PM +0200, Luca Tettamanti wrote: To recap: my ADSL router receives two requests and sends back *two* answers; to the A query it replies with the expected data, to the query it replies NotImpl (see the tcpdump in the first email). I doubt that this behaviour is allowed. Not implemented is a response to the query type, aka standard query or inverse query, not to the contents of the query.[1] This behaviour also violates the transparency considerations.[2] Bastian [1]: http://tools.ietf.org/html/rfc1035 [2]: http://tools.ietf.org/html/rfc3597 -- We have the right to survive! Not by killing others. -- Deela and Kirk, Wink of An Eye, stardate 5710.5 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518133: closed by Aurelien Jarno aurel...@aurel32.net (Re: Bug#518133: libc6-xen: nosegneg not selected when running in OpenVZ under Xen)
On Wed, Mar 04, 2009 at 01:29:59PM +0100, Dr. Andreas Krüger wrote: I have tried that hwcap 0 nosegneg bit. That one does NOT help. Did you call ldconfig after that? You can use ldd to see which libs it wants to use. That established, do you still think there a good chance that the other part of your counsel does help, that is, upgrading to a more recent kernel? There is no Debian kernel which produces this messages anymore. Bastian -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, Wolf in the Fold, stardate 3615.4 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513564: glibc: Please redefine __i686 to work-around the infamous i686 compilation fail
On Fri, Jan 30, 2009 at 10:37:57AM +0200, Yoram bar haim wrote: When compiling with gcc that uses march=i686 (or any sub-arch) gcc defines __i686 to be 1, that causes instructions such as ..ifndef __i686.get_pc_thunk.reg; to fail as syntax error (because the prefix is 1). if you force it to be redefid as __i686 it works fine Any identifier which starts with two underscores (or one underscore and an uppercase letter) is reserved for use by the implementation. You must not define them yourself. According to the google code search, this code is only used in the glibc itself, which obviously built fine. Bastian -- Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, Assignment: Earth, stardate unknown -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479952: not fixed
found 479952 2.7-18 thanks I'm afraid but this is not fixed completely: | $ dchroot-dsa sid | dchroot-dsa: pthread_mutex_lock.c:87: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. | zsh: abort dchroot-dsa sid | $ COLUMNS=72 dpkg -l libc6 | Desired=Unknown/Install/Remove/Purge/Hold | | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed | |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) | ||/ Name VersionDescription | +++-==-==- | ii libc6 2.7-18 GNU C Library: Shared libraries | $ strace -e open dchroot-dsa sid | grep libc | open(/lib/libc.so.6, O_RDONLY)= 3 Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 signature.asc Description: Digital signature
Re: Bug#506420: incorrect hwcap line in /etc/ld.so.conf.d/libc6-xen.conf?
On Sat, Nov 22, 2008 at 07:02:26PM +0100, Aurelien Jarno wrote: On Sat, Nov 22, 2008 at 12:58:38PM +0100, Bastian Blank wrote: The traditional hwcaps are read from the interpreter data via AT_HWCAP. The pseudo hwcaps are defined in the vdso, but I fail to find this code. Look at hwcap_extra in elf/ldconfig.c It is _dl_important_hwcaps in elf/dl-sysdep.c. Bastian -- Beam me up, Scotty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#506420: incorrect hwcap line in /etc/ld.so.conf.d/libc6-xen.conf?
On Sat, Nov 22, 2008 at 10:41:01AM +, Richard Kettlewell wrote: Aurelien Jarno wrote: The value in this file is the correct one. Where is this documented? In the kernel. However, I was not able to find the code which processes this hwcaps in libc. The traditional hwcaps are read from the interpreter data via AT_HWCAP. The pseudo hwcaps are defined in the vdso, but I fail to find this code. Bastian -- Immortality consists largely of boredom. -- Zefrem Cochrane, Metamorphosis, stardate 3219.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499366: 4gb seg fixup not fixed in 2.7-14?
On Wed, Oct 15, 2008 at 08:55:01AM +0200, Aurelien Jarno wrote: Given how Xen works, a lot of people are not able to change their kernel. This is incorrect. There are now two possibilities to use the guest supplied kernels and the whole bunch of enterprise distributions never really supported it otherwise. One of them can even be considered safe. IMHO it is a really bad idea to not support Xen kernels from Etch. I don't know how. The way the kernel in Etch responds to the problem is also not pretty, but this was not really clear at that time of the Etch release. Bastian -- Without followers, evil cannot spread. -- Spock, And The Children Shall Lead, stardate 5029.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499366: 4gb seg fixup not fixed in 2.7-14?
On Tue, Oct 14, 2008 at 04:15:29PM +0200, Aurelien Jarno wrote: The proposed patch has been applied. But maybe it is wrong. Waldi, could you please have a look? I have no Xen machine. The patch is correct. The problem is the wrong capability definition in the Etch kernel. But fixing the package to work together with the Lenny kernel is more important. Maybe I should fix the kernel in Etch also. Bastian -- Beauty is transitory. Beauty survives. -- Spock and Kirk, That Which Survives, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499366: Acknowledgement (libc6-xen - Wrong bit for nosegneg pseudo hwcap)
tags 499366 patch thanks Patch diff -Nru glibc-2.7/debian/changelog glibc-2.7/debian/changelog --- glibc-2.7/debian/changelog 2008-09-20 12:41:28.0 + +++ glibc-2.7/debian/changelog 2008-09-20 12:41:42.0 + @@ -1,3 +1,10 @@ +glibc (2.7-13.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Set nosegneg capability to 1 to match current kernels. (closes: #499366) + + -- Bastian Blank [EMAIL PROTECTED] Sat, 20 Sep 2008 12:24:22 + + glibc (2.7-13) unstable; urgency=low [ Aurelien Jarno ] diff -Nru glibc-2.7/debian/sysdeps/i386.mk glibc-2.7/debian/sysdeps/i386.mk --- glibc-2.7/debian/sysdeps/i386.mk2008-09-20 12:41:28.0 + +++ glibc-2.7/debian/sysdeps/i386.mk2008-09-20 12:41:42.0 + @@ -11,7 +11,7 @@ i686_extra_config_options = $(extra_config_options) --disable-profile # We use -mno-tls-direct-seg-refs to not wrap-around segments, as it -# greatly increase the speed when running under the Xen hypervisor. +# greatly increase the speed when running under the 32bit Xen hypervisor. GLIBC_PASSES += xen DEB_ARCH_REGULAR_PACKAGES += libc6-xen xen_add-ons = nptl $(add-ons) @@ -24,11 +24,11 @@ define libc6-xen_extra_pkg_install mkdir -p debian/libc6-xen/etc/ld.so.conf.d echo '# This directive teaches ldconfig to search in nosegneg subdirectories' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf -echo '# and cache the DSOs there with extra bit 0 set in their hwcap match' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf +echo '# and cache the DSOs there with extra bit 1 set in their hwcap match' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf echo '# fields. In Xen guest kernels, the vDSO tells the dynamic linker to' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf echo '# search in nosegneg subdirectories and to match this extra hwcap bit' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf echo '# in the ld.so.cache file.' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf -echo 'hwcap 0 nosegneg' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf +echo 'hwcap 1 nosegneg' debian/libc6-xen/etc/ld.so.conf.d/libc6-xen.conf endef # build 64-bit (amd64) alternative library signature.asc Description: Digital signature
Bug#499366: libc6-xen - Wrong bit for nosegneg pseudo hwcap
Package: libc6-xen Version: 2.7-13 Severity: important Linux uses bit 1 for the nosegneg pseudo hwcap, not 0. This makes this package currently unusable. (And the systems really slow.) Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, Errand of Mercy, stardate 3201.7 signature.asc Description: Digital signature
Bug#484477: bug closed
On Thu, Jun 05, 2008 at 10:08:53AM +0200, Salvo Tomaselli wrote: If inet_ntop is not buggy, then inet_pton is. Please provide a _complete_ and _compiling_ example. You want to show a bug noone believes there is one. :::151.97.56.250: This address is not valid. Bastian -- Punishment becomes ineffective after a certain point. Men become insensitive. -- Eneg, Patterns of Force, stardate 2534.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480433: libc6.1: mkdtemp on ia64 can return xa non null pointer not pointing at the template
On Fri, May 09, 2008 at 05:46:21PM -0600, Alan Bain wrote:
Affects IA64 only
Code like...
static char buf[20];
strcpy(buf, /tmp/some_XX);
char * tmpname=mkdtemp(buf);
Please provide a minimal, compiling and known to fail testcase. The following
testcase works as expected:
| merulo% cat test.c
| #define _GNU_SOURCE 1
|
| #include stdlib.h
| #include stdio.h
| #include string.h
|
| int main()
| {
| static char buf[20];
| strcpy(buf, /tmp/some_XX);
| char * tmpname=mkdtemp(buf);
| printf(%s (%p)\n, buf, buf);
| printf(%s (%p)\n, tmpname, tmpname);
| }
| merulo% uname -a
| Linux merulo 2.6.18-dsa-mckinley #1 SMP Mon Feb 11 09:57:09 MST 2008 ia64
GNU/Linux
| merulo% dpkg -s libc6.1-dev | grep Version
| Version: 2.7-10
| merulo% gcc -o test test.c
| merulo% ./test
| /tmp/some_mCgeUd (0x6fc0)
| /tmp/some_mCgeUd (0x6fc0)
| merulo% rmdir /tmp/some_mCgeUd
Bastian
--
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, This Side of Paradise, stardate 3417.3
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480295: [alpha] missing asm/page.h
On Fri, May 09, 2008 at 06:01:09PM +0200, Aurelien Jarno wrote: Bastian Blank a écrit : On Fri, May 09, 2008 at 05:33:40PM +0200, Aurelien Jarno wrote: Matthias Klose a écrit : In file included from ../../bfd/trad-core.c:45: /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory make[5]: *** [trad-core.lo] Error 1 /usr/include/asm is provided by linux-libc-dev, not by libc6.1-dev. /usr/include/asm/page.h is _not_ provided by linux-libc-dev, but This is actually something relatively new, introduced by linux 2.6.25. Yes. The removal was announced long ago because it only provided the not really static PAGE_SIZE since a long time. Most of the architectures already followed that. Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, Amok Time, stardate 3372.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480433: libc6.1: mkdtemp on ia64 can return xa non null pointer not pointing at the template
reassign 480433 f2c 20061008-1 thanks On Sat, May 10, 2008 at 10:46:31AM +0200, Bastian Blank wrote: Please provide a minimal, compiling and known to fail testcase. The following testcase works as expected: You uploaded a fixed f2c which shows that you ignored compiler warnings about undefined functions. Reassigning. Bastian -- One does not thank logic. -- Sarek, Journey to Babel, stardate 3842.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
Package: libc6 Version: 2.7-10 Severity: important On Wed, May 07, 2008 at 09:34:12AM +0200, Matthias Klose wrote: the build failure on s390 is unexpected; is it possible to extract a test case? | java: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. So another package failed about that (after mono and libto$bla). It looks like a race condition somewhere in the libpthread. Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, Shore Leave, stardate 3025.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Incompatibility of libc6 with kernel 2.6 ax25
On Wed, Apr 30, 2008 at 01:57:26PM +0200, Arjan van Schijndel wrote: Version: 2.3.6.ds1-13etch5 And in unstable? The following files in libc6 are not up to date: netax25/ax25.h netrom/netrom.h netrose/rose.h. Meaning these files do not correspond with the ax25.h netrom.h and rose.h from the 2.6 kernel. Resulting in a wrong syscall.h. Would it be enough to use the linux-libc-dev provided files linux/netrom.h, linux/rose.h and linux/ax25.h? Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, Amok Time, stardate 3372.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459606: libc6: 2.7-5 breaks dpkg on sparc64
reassign 459606 linux-2.6 forcemerge 433187 459606 thanks On Mon, Jan 07, 2008 at 03:35:28PM +, J.J.Green wrote: and the dpkg-query (running dpkg-query --status sysvinit) runs at 100% cpu for at least 20 minutes, and does not respond to a kill -9 from root! The only way I could kill it was to power cycle. This is an old kernel bug. See #433187[1] for reference Kernel: Linux 2.6.18-jjg (SMP w/1 CPU core) This is _no_ debian kernel. Bastian [1]: http://bugs.debian.org/433187 -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454266: upgrade to 2.7 fails, leaving system unusable
On Wed, Dec 05, 2007 at 09:24:27AM +0100, Marcus Better wrote: ~$ sudo grep -C1 libc6-i686 /var/log/installer/* /var/log/installer/syslog-Aug 21 11:26:57 apt-install: Queueing package acpid for later installation /var/log/installer/syslog:Aug 21 11:26:58 apt-install: Queueing package libc6-i686 for later installation /var/log/installer/syslog-Aug 21 11:26:58 hw-detect: Missing modules 'ide-core (Linux IDE support), usb-storage (USB storage), ide-generic (Linux IDE support), ide-floppy (Linux IDE floppy), ide-disk (Linux ATA DISK), ide-cd (Linux ATAPI CD-ROM), isofs (Linux ISO 9660 filesystem) -- /var/log/installer/syslog-Aug 21 11:39:20 apt-install: Rekommenderade paket: /var/log/installer/syslog:Aug 21 11:39:20 apt-install: libc6-i686 /var/log/installer/syslog-Aug 21 11:39:20 apt-install: Följande NYA paket kommer att installeras: -- /var/log/installer/syslog-Aug 21 11:43:27 apt-install: Rekommenderade paket: /var/log/installer/syslog:Aug 21 11:43:27 apt-install: libc6-i686 /var/log/installer/syslog-Aug 21 11:43:27 apt-install: Följande NYA paket kommer att installeras: Please provide the complete files. Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0
Bug#453326: locales-all: postinst script does not respect TMPDIR
+ tmpdir=$(mktemp -d ${TMPDIR:-/tmp}/locales.XX)
Or just use -t as documented in mktemp(1).
Bastian
--
It is more rational to sacrifice one life than six.
-- Spock, The Galileo Seven, stardate 2822.3
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449192: acknowledged by developer (closing 449192)
reopen 449192 thanks Closed without comment. Use the changelog to close bugs. Bastian -- Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449192: glibc - FTBFS: make: *** [clean] Error 1
Package: glibc Version: 2.7-0exp6 Severity: serious There was an error while trying to autobuild your package: Automatic build of glibc_2.7-0exp6 on debian-31.osdl.marist.edu by sbuild/s390 98 [...] rm -f /build/buildd/glibc-2.7/stamp-dir/binaryinst* # FTBFS if not on madcoder's machine [ `hostname -f` = artemis.madism.org ] || exit 1 make: *** [clean] Error 1 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules clean gave error exit status 2 ** Build finished at 20071101-1408 FAILED [dpkg-buildpackage died] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r2566 - in glibc-package/trunk/debian: . patches patches/amd64
On Mon, Sep 17, 2007 at 02:15:01AM -0400, Clint Adams wrote: * amd64/local-x86_64_bits_sigcontext.diff: use a copy of the generic header for x86_64. closes: #442418. Incidentally, waldi says this is the wrong fix. asm-i386/sigcontext.h and asm-x86_64/sigcontext.h have different contents. The generic header which only includes asm/sigcontext.h is suitable for i386. asm-i386/sigcontext.h provides - _fpreg, - _fpxreg, - _xmmreg, - _fpstate and - sigcontext. asm-x86_64/sigcontext.h provides only - _fpstate and - sigcontext. Bastian -- Dammit Jim, I'm an actor, not a doctor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer Status Update - August 31th 2007
On Mon, Sep 03, 2007 at 05:00:08PM +0200, Martin Michlmayr wrote: When I use mklibs-copy rather than mklibs to produce the initrd it works. Maybe waldi can give some help as to how to track this down. The symbol-version-problem #433874. Currently only binNMUs can workaround it. Bastian -- You're dead, Jim. -- McCoy, Amok Time, stardate 3372.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote: This is not properly fixable by the glibc. The attached patch fixes it in linux, but I'm unsure if this will not break other things like alternative libc. No productive disagreement. It will be included with a changed guard: #if defined(__KERNEL__) || __STDC_HOSTED__ == 0 !defined(__KERNEL_STRICT_NAMES) Bastian -- There are always alternatives. -- Spock, The Galileo Seven, stardate 2822.3 signature.asc Description: Digital signature
Re: linux/types.h - glibc interferences
On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote: If there's userspace code that wants to get the kernel types under the standard posix names, why break that? Please provide a less strict fix which works. Userspace code can only use this definitions within a freestanding compiler without libc. I update the guard to defined __KERNEL__ || __STDC_HOSTED__ == 0. This way the kernel and the freestanding compiler can use them. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Fri, Aug 24, 2007 at 01:14:17AM -0700, Steve Langasek wrote: On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote: #434040 and a hand full of packages on the buildd. What packages? Several. No further information available without manual checking. I expect that several hundred packages may be affected. linux-kernel-headers had a crude workaround, which is not better. Well, it's hard to suggest a less strict fix without knowing what needs fixing. :) linux/types.h and the other glibc/gcc headers must not clash, even if features.h is not included and __KERNEL_STRICT_NAMES not set. Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, Requiem for Methuselah, stardate 5842.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux/types.h - glibc interferences
Hi folks
linux/types.h exports some POSIX types. It can be asked to stop this
with __KERNEL_STRICT_NAMES. features.h defines this. So currently
anything works if features.h is included before linux/types.h.
This is not properly fixable by the glibc. The attached patch fixes it
in linux, but I'm unsure if this will not break other things like
alternative libc.
Bastian
--
You can't evaluate a man by logic alone.
-- McCoy, I, Mudd, stardate 4513.3
diff --git a/include/linux/types.h b/include/linux/types.h
index 0351bf2..a9779d6 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -14,10 +14,10 @@
#include linux/posix_types.h
#include asm/types.h
-#ifndef __KERNEL_STRICT_NAMES
-
typedef __u32 __kernel_dev_t;
+#ifdef __KERNEL__
+
typedef __kernel_fd_set fd_set;
typedef __kernel_dev_t dev_t;
typedef __kernel_ino_t ino_t;
@@ -32,7 +32,6 @@ typedef __kernel_timer_t timer_t;
typedef __kernel_clockid_t clockid_t;
typedef __kernel_mqd_t mqd_t;
-#ifdef __KERNEL__
typedef _Bool bool;
typedef __kernel_uid32_t uid_t;
@@ -46,51 +45,14 @@ typedef __kernel_old_uid_t old_uid_t;
typedef __kernel_old_gid_t old_gid_t;
#endif /* CONFIG_UID16 */
-/* libc5 includes this file to define uid_t, thus uid_t can never change
- * when it is included by non-kernel code
- */
-#else
-typedef __kernel_uid_t uid_t;
-typedef __kernel_gid_t gid_t;
-#endif /* __KERNEL__ */
-
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __kernel_loff_t loff_t;
-#endif
-/*
- * The following typedefs are also protected by individual ifdefs for
- * historical reasons:
- */
-#ifndef _SIZE_T
-#define _SIZE_T
typedef __kernel_size_t size_t;
-#endif
-
-#ifndef _SSIZE_T
-#define _SSIZE_T
typedef __kernel_ssize_t ssize_t;
-#endif
-
-#ifndef _PTRDIFF_T
-#define _PTRDIFF_T
typedef __kernel_ptrdiff_t ptrdiff_t;
-#endif
-
-#ifndef _TIME_T
-#define _TIME_T
typedef __kernel_time_t time_t;
-#endif
-
-#ifndef _CLOCK_T
-#define _CLOCK_T
typedef __kernel_clock_t clock_t;
-#endif
-
-#ifndef _CADDR_T
-#define _CADDR_T
typedef __kernel_caddr_t caddr_t;
-#endif
/* bsd */
typedef unsigned char u_char;
@@ -104,27 +66,18 @@ typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
-#ifndef __BIT_TYPES_DEFINED__
-#define __BIT_TYPES_DEFINED__
-
+typedef __u8 uint8_t;
typedef __u8 u_int8_t;
typedef __s8 int8_t;
+typedef __u16 uint16_t;
typedef __u16 u_int16_t;
typedef __s16 int16_t;
+typedef __u32 uint32_t;
typedef __u32 u_int32_t;
typedef __s32 int32_t;
-
-#endif /* !(__BIT_TYPES_DEFINED__) */
-
-typedef __u8 uint8_t;
-typedef __u16 uint16_t;
-typedef __u32 uint32_t;
-
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __u64 uint64_t;
typedef __u64 u_int64_t;
typedef __s64 int64_t;
-#endif
/* this is a special 64bit data type that is 8-byte aligned */
#define aligned_u64 unsigned long long __attribute__((aligned(8)))
@@ -160,7 +113,7 @@ typedef unsigned long blkcnt_t;
#define pgoff_t unsigned long
#endif
-#endif /* __KERNEL_STRICT_NAMES */
+#endif /* __KERNEL__ */
/*
* Below are truly Linux-specific types that should never collide with
@@ -182,10 +135,8 @@ typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
-typedef __u64 __bitwise __le64;
-typedef __u64 __bitwise __be64;
-#endif
+__extension__ typedef __u64 __bitwise __le64;
+__extension__ typedef __u64 __bitwise __be64;
typedef __u16 __bitwise __sum16;
typedef __u32 __bitwise __wsum;
@@ -198,8 +149,6 @@ typedef u64 resource_size_t;
typedef u32 resource_size_t;
#endif
-#endif /* __KERNEL__ */
-
struct ustat {
__kernel_daddr_t f_tfree;
__kernel_ino_t f_tinode;
@@ -207,4 +156,6 @@ struct ustat {
char f_fpack[6];
};
+#endif /* __KERNEL__ */
+
#endif /* _LINUX_TYPES_H */
Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote: Is there some specific reported issue that this change is intended to fix? I haven't noticed any complaints about the current behavior. #434040 and a hand full of packages on the buildd. Anyway, it's my understanding that userspace apps are never supposed to define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so in terms of overall design this change looks wrong to me (or at least, gratuitously strict). __KERNEL__-only parts of the headers are filtered out for linux-libc-dev. If there's userspace code that wants to get the kernel types under the standard posix names, why break that? Please provide a less strict fix which works. Userspace code can only use this definitions within a freestanding compiler without libc. (For an example of code that probably breaks with this change, I offer you aboot, the alpha bootloader; it's not great code, but we have to maintain it all the same...) Thats what I expected. Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote:
D-I may be also affected and mklibs needs to pull in libgcc_s.so.1
always if it catches a glibc.
The attached mklibs patch always adds libgcc for old-abi arm.
Bastian
--
Well, Jim, I'm not much of an actor either.
Index: debian/control
===
--- debian/control (revision 108)
+++ debian/control (working copy)
@@ -8,7 +8,7 @@
Package: mklibs
Architecture: all
-Depends: python, binutils, gcc, mklibs-copy (= 0.1.21)
+Depends: python, binutils, gcc, mklibs-copy (= ${source:Version})
Recommends: libc6-pic | libc6.1-pic
Description: Shared library reduction script
mklibs produces cut-down shared libraries that contain only the
Index: src/mklibs-copy.py
===
--- src/mklibs-copy.py (revision 108)
+++ src/mklibs-copy.py (working copy)
@@ -65,6 +65,13 @@
return result
+def elf_header(obj):
+if not os.access(obj, os.F_OK):
+raise Cannot find lib: + obj
+output = command(mklibs-readelf, --print-elf-header, obj)
+s = [int(i) for i in output[0].split()]
+return {'class': s[0], 'data': s[1], 'machine': s[2], 'flags': s[3]}
+
# Return a set of rpath strings for the passed object
def rpath(obj):
if not os.access(obj, os.F_OK):
@@ -278,6 +285,11 @@
previous_pass_libraries = libraries
+# WORKAROUND: Always add libgcc on old-abi arm
+header = elf_header(find_lib(libraries.copy().pop()))
+if header['machine'] == 40 and header['flags'] 0xff00 == 0:
+libraries.add('libgcc_s.so.1')
+
# reduce libraries
for library in libraries:
so_file = find_lib(library)
Index: src/mklibs-readelf/main.cpp
===
--- src/mklibs-readelf/main.cpp (revision 112)
+++ src/mklibs-readelf/main.cpp (working copy)
@@ -18,6 +18,7 @@
static struct option const long_opts[] =
{
+ {print-elf-header, no_argument, 0, 'e'},
{print-interp, no_argument, 0, 'i'},
{print-needed, no_argument, 0, 'n'},
{print-rpath, no_argument, 0, 'R'},
@@ -33,6 +34,7 @@
enum command
{
+ COMMAND_PRINT_ELF_HEADER,
COMMAND_PRINT_INTERP,
COMMAND_PRINT_NEEDED,
COMMAND_PRINT_RPATH,
@@ -41,6 +43,15 @@
COMMAND_PRINT_SYMBOLS_UNDEFINED,
};
+static void process_elf_header (Elf::file *file)
+{
+ std::cout
+ (unsigned int) file-get_class () ' '
+ (unsigned int) file-get_data () ' '
+ file-get_machine () ' '
+ file-get_flags () '\n';
+}
+
static void process_dynamics (Elf::section_typeElf::section_type_DYNAMIC
*section, int64_t tag)
{
for (std::vectorElf::dynamic *::const_iterator it = section-get_dynamics
().begin (); it != section-get_dynamics ().end (); ++it)
@@ -108,6 +119,9 @@
switch (cmd)
{
+case COMMAND_PRINT_ELF_HEADER:
+ process_elf_header (file);
+ break;
case COMMAND_PRINT_INTERP:
if (segment_interp)
std::cout segment_interp-get_interp () '\n';
@@ -166,12 +180,15 @@
program_name = argv[0];
- while ((c = getopt_long (argc, argv, inpRsu, long_opts, NULL)) != -1)
+ while ((c = getopt_long (argc, argv, einpRsu, long_opts, NULL)) != -1)
{
switch (c)
{
case 0:
break;
+ case 'e':
+cmd = COMMAND_PRINT_ELF_HEADER;
+break;
case 'i':
cmd = COMMAND_PRINT_INTERP;
break;
Index: src/mklibs-readelf/elf.cpp
===
--- src/mklibs-readelf/elf.cpp (revision 105)
+++ src/mklibs-readelf/elf.cpp (working copy)
@@ -150,6 +150,7 @@
this-machine = convert_data, typeof (ehdr-e_machine ) ()
(ehdr-e_machine);
this-phoff = convert_data, typeof (ehdr-e_phoff) ()
(ehdr-e_phoff);
this-shoff = convert_data, typeof (ehdr-e_shoff) ()
(ehdr-e_shoff);
+ this-flags = convert_data, typeof (ehdr-e_flags) ()
(ehdr-e_flags);
this-phentsize = convert_data, typeof (ehdr-e_phentsize) ()
(ehdr-e_phentsize);
this-phnum = convert_data, typeof (ehdr-e_phnum) ()
(ehdr-e_phnum);
this-shentsize = convert_data, typeof (ehdr-e_shentsize) ()
(ehdr-e_shentsize);
Index: src/mklibs-readelf/elf.hpp
===
--- src/mklibs-readelf/elf.hpp (revision 105)
+++ src/mklibs-readelf/elf.hpp (working copy)
@@ -31,15 +31,15 @@
namespace Elf
{
- class file_class_32 { public: static const unsigned int id = 1; };
- class file_class_64 { public: static const unsigned int id = 2; };
- class file_data_2LSB { public: static const unsigned int id = 1; };
- class file_data_2MSB { public: static const unsigned int id = 2; };
+ class file_class_32 { public: static const uint8_t id = 1; };
+ class file_class_64 { public: static const uint8_t id = 2; };
+ class file_data_2LSB { public: static const uint8_t id = 1
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 09:27:10AM +0200, Aurelien Jarno wrote: The same code is also present on glibc 2.3.6 for nptl builds. So at least amd64 is using it in etch for the initrd. Yes. But it is only used sometimes. This code is located in libpthread and consist of direct wrappers around libgcc functions. Isn't it possible to just correctly link against libgcc instead of this dlopen stunt? As libgcc needs libc, it is not possible to do that for libc, but libpthread should work, or do I miss something? D-I may be also affected and mklibs needs to pull in libgcc_s.so.1 always if it catches a glibc. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 10:30:05AM +0200, Bastian Blank wrote: This code is located in libpthread and consist of direct wrappers around libgcc functions. Isn't it possible to just correctly link against libgcc instead of this dlopen stunt? As libgcc needs libc, it is not possible to do that for libc, but libpthread should work, or do I miss something? Yes I did. The code is spread over the complete libc.so.6 depending on the correct architecture. Bastian -- Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: What I don't understand is why /sbin/init on arm now uses threads? It is /bin/sh, which should be busybox. It is clear that we miss a dependency on libgcc1/libgcc2/libgcc4, but unfortunately I am not sure there is another way to fix that. I don't think that ld is able to process recursive lib deps. So there is no other fix. Bastian -- He's dead, Jim. -- McCoy, The Devil in the Dark, stardate 3196.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc dlopening libgcc on arm
On Wed, May 30, 2007 at 11:31:35AM +0200, Bastian Blank wrote: On Wed, May 30, 2007 at 11:19:38AM +0200, Aurelien Jarno wrote: What I don't understand is why /sbin/init on arm now uses threads? It is /bin/sh, which should be busybox. And it does not use pthread at all. It may be usefull to get a backtrace. Bastian -- Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, Assignment: Earth, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419644: libc6-dev - /usr/include/bits/stdio-ldbl.h:39: error: 'vsnprintf' undeclared here (not in a function)
Package: libc6-dev Version: 2.5-2 Severity: serious Automatic build of wmweather+_2.9-3 on debian-31.osdl.marist.edu by sbuild/s390 98 [...] if s390-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include -I/usr/include -I/usr/include/w3c-libwww -DHAVE_CONFIG_H -MT wmgeneral.o -MD -MP -MF .deps/wmgeneral.Tpo -c -o wmgeneral.o wmgeneral.c; \ then mv -f .deps/wmgeneral.Tpo .deps/wmgeneral.Po; else rm -f .deps/wmgeneral.Tpo; exit 1; fi In file included from /usr/include/stdio.h:839, from wmgeneral.c:70: /usr/include/bits/stdio-ldbl.h:39: error: 'vsnprintf' undeclared here (not in a function) make[3]: *** [wmgeneral.o] Error 1 make[3]: Leaving directory `/build/buildd/wmweather+-2.9/wmgeneral' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/wmweather+-2.9' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/wmweather+-2.9' make: *** [build-stamp] Error 2 ** Build finished at 20070416-1953 FAILED [dpkg-buildpackage died] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419644: libc6-dev - /usr/include/bits/stdio-ldbl.h:39: error: 'vsnprintf' undeclared here (not in a function)
reassign 419644 wmweather+ 2.9-3 thanks On Tue, Apr 17, 2007 at 10:15:36AM +0200, Aurelien Jarno wrote: Bastian Blank a écrit : Package: libc6-dev Version: 2.5-2 Severity: serious Automatic build of wmweather+_2.9-3 on debian-31.osdl.marist.edu by sbuild/s390 98 [...] if s390-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include -I/usr/include -I/usr/include/w3c-libwww -DHAVE_CONFIG_H -MT wmgeneral.o -MD -MP -MF .deps/wmgeneral.Tpo -c -o wmgeneral.o wmgeneral.c; \ then mv -f .deps/wmgeneral.Tpo .deps/wmgeneral.Po; else rm -f .deps/wmgeneral.Tpo; exit 1; fi In file included from /usr/include/stdio.h:839, from wmgeneral.c:70: /usr/include/bits/stdio-ldbl.h:39: error: 'vsnprintf' undeclared here (not in a function) Have you been able to reproduce the bug outside of the build daemon? Yes. And I found the following: | # 221 ../config.h | #define vsnprintf(str,size,format,ap) my_vsnprintf(str, size, format, ap) | # 2 wmgeneral.c 2 So it is a clear bug in wmweather+ by redefining C99 functions. Bastian -- War isn't a good life, but it's life. -- Kirk, A Private Little War, stardate 4211.8 signature.asc Description: Digital signature
Bug#413744: glibc - uses more than one cpu without asking
Package: glibc Version: 2.3.6.ds1-13 glibc uses all cpus without asking. One of the s390 buildds, lxdebian, have two cpus online but is only allowed to use one full. This is followed by a make call without -j. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, The Cloud Minders, stardate 5818.4 signature.asc Description: Digital signature
Bug#393023: PAGE_SIZE is undeclared
On Sat, Oct 14, 2006 at 06:13:28PM +0100, Martin Michlmayr wrote: Lots of packages don't build because PAGE_SIZE is undeclared. Several arches don't export PAGE_SIZE as it is not fixed. Examples: Automatic build of directfb-0.9-22_0.9.22-10 on bigsur by sbuild/mips 0.49 Automatic build of eciadsl_0.11-3 on coconut0 by sbuild/ia64 0.49 You found the two arches where this is true. Also asm/page.h is marked as These probably shouldn't be exported. Bastian -- Leave bigotry in your quarters; there's no room for it on the bridge. -- Kirk, Balance of Terror, stardate 1709.2 signature.asc Description: Digital signature
Re: r1813 - glibc-package/trunk/debian
On Sun, Oct 01, 2006 at 04:15:44PM +, Aurelien Jarno wrote: Modified: glibc-package/trunk/debian/FAQ === --- glibc-package/trunk/debian/FAQ2006-10-01 15:46:58 UTC (rev 1812) +++ glibc-package/trunk/debian/FAQ2006-10-01 16:15:43 UTC (rev 1813) @@ -90,7 +90,8 @@ The application should continue to run for now, but when the warning message is printed use of the NPTL threading library, and other new kernel-2.6 features, it's worth trying to set environment variable LD_ASSUME_KERNEL=2.4.1 -(switch to LinuxThreads instead of NPTL). +(switch to LinuxThreads instead of NPTL). Not that this workaround does not +work on amd64. s/Not/Note/? Bastian -- Live long and prosper. -- Spock, Amok Time, stardate 3372.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc 2.5
On Sun, Oct 01, 2006 at 10:39:57PM +0200, Aurelien Jarno wrote: Upstream has released version 2.5 of the glibc on Friday. I have added a new branch in the SVN, and prepared a new tarball. I have made it using the upstream tarballs for glibc (with manual removed) and libidn, and cvs for ports and linuxthreads (are they are not released anymore). You mean that every dist which wants to support arches not in core glibc have to produce releases of the ports themself? Which Debian arches are currently not maintained in core glibc? Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, Amok Time, stardate 3372.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389673: linux-kernel-headers: Old version of asm-i386/unistd.h in source tarball (hides _syscall* macros)
On Wed, Sep 27, 2006 at 01:39:10PM +1000, Ted Percival wrote: The linux-kernel-headers 2.6.18 source tarball contains an old version of include/asm-i386/unistd.h. This old version has the _syscall* macros hidden inside an #ifdef __KERNEL__ so userspace cannot use them. The _syscall macros are not save to use on most architectures. Use the syscall wrapper. The ifdef is on line 327. The source file was fixed in the following patch: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=386dcafaacd212ef4a8aeed67a7db3ffbb44c7b2 This was reverted in e5fa6d70318e4a6a644edbb7d574059e5b326de1. According to the Changelog (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18) it was fixed between 2.6.18-rc5 and 2.6.18-rc6. I checked a couple of more recent commits in include/asm-i386 and they are up-to-date in the source tarball. It is the state of the 2.6.18 release. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6 signature.asc Description: Digital signature
Bug#383276: glibc - FTBFS: /bin/sh: line 9: texi2html: command not found
Package: glibc Version: 2.3.6.ds1-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of glibc_2.3.6.ds1-1 on lxdebian.bfinv.de by sbuild/s390 85 [...] ** Using build dependencies supplied by package: Build-Depends: gettext, make (= 3.80-1), dpkg-dev (= 1.13.5), bzip2, file, linux-kernel-headers (= 2.6.13+0rc3-2) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386], kfreebsd-kernel-headers [kfreebsd-i386 kfreebsd-amd64], gcc-4.0 [hurd-i386], gcc-4.1 [!hurd-i386], binutils (= 2.16.1cvs20051109-1), autoconf, sed (= 4.0.5-4), gawk, debhelper (= 5.0), libc6-dev-amd64 [i386], libc6-dev-ppc64 [powerpc], libc6-dev-i386 [amd64], libc6-dev-powerpc [ppc64], libc6-dev-sparc64 [sparc], libc6-dev-s390x [s390], quilt Build-Depends-Indep: perl, po-debconf (= 1.0) [...] make[3]: Leaving directory `/build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/localedata' make[2]: Leaving directory `/build/buildd/glibc-2.3.6.ds1/build-tree/glibc-2.3.6' make[1]: Leaving directory `/build/buildd/glibc-2.3.6.ds1/build-tree/s390-libc' /bin/sh: line 9: texi2html: command not found make: *** [/build/buildd/glibc-2.3.6.ds1/stamp-dir/install_libc] Error 127 ** Build finished at 20060816-0352 FAILED [dpkg-buildpackage died] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiple definition of `_init'
On Tue, Jul 25, 2006 at 01:30:34PM +0200, Martin Michlmayr wrote: While building rsplib, I get the following errors. Is that an application or glibc problem? Application. You can't link the same object files in more than one time. g++ -shared /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtbeginS.o .libs/mutex.o .libs/thread.o -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crtn.o -o .libs/libcppthread.so.0.0.0 It lists crtbeginS.o explicitely, which is already included into the link list by gcc. Also the whole -L definitions looks pretty wrong. It lists the default paths again. Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 signature.asc Description: Digital signature
Bug#374330: Please also build libc6-xen on amd64
On Sun, Jun 18, 2006 at 07:51:01PM +0200, Timo Weingärtner wrote: What about i386 binaries under an amd64 kernel? AFAIK no. What about an i386 kernel under an amd64 xen? Not possible at all. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, Today I will be brilliant. -- Kirk, The Ultimate Computer, stardate 4731.3 signature.asc Description: Digital signature
Bug#372072: glibc - FTBFS: dh_install: libc6-s390x missing files (log-test-*-s390x), aborting
Package: glibc Version: 2.3.6-14 Severity: important There was an error while trying to autobuild your package: Automatic build of glibc_2.3.6-14 on debian-31 by sbuild/s390 85 [...] Running debhelper for libc6-s390x dh_testroot dh_installdirs -plibc6-s390x dh_install -plibc6-s390x dh_install: libc6-s390x missing files (log-test-*-s390x), aborting make: *** [/build/buildd/glibc-2.3.6/stamp-dir/binaryinst_libc6-s390x] Error 1 ** Build finished at 20060607-2052 FAILED [dpkg-buildpackage died] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369659: glibc - FTBFS: Missing build dependency lib64gcc1
Package: glibc Version: 2.3.6-12 Severity: serious There was an error while trying to autobuild your package: Automatic build of glibc_2.3.6-12 on debian01 by sbuild/s390 85 [...] ** Using build dependencies supplied by package: Build-Depends: gettext, make (= 3.80-1), dpkg-dev (= 1.13.5), bzip2, texinfo, texi2html, file, linux-kernel-headers (= 2.6.13+0rc3-2) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386], kfreebsd-kernel-headers [kfreebsd-i386 kfreebsd-amd64], gcc-4.0 [!m68k], gcc-3.4 [m68k], binutils (= 2.16.1cvs20051109-1), autoconf, sed (= 4.0.5-4), gawk, debhelper (= 4.1.76), libc6-dev-amd64 [i386], libc6-dev-ppc64 [powerpc], libc6-dev-i386 [amd64], libc6-dev-powerpc [ppc64], libc6-dev-sparc64 [sparc], quilt [...] gcc-4.0 -m64 -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld64.so.1 -B/build/buildd/glibc-2.3.6/build-tree/s390-s390x/csu/ -Wl,--version-script=/build/buildd/glibc-2.3.6/build-tree/s390-s390x/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -nostdlib -nostartfiles -e __libc_main -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/math -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/elf -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/dlfcn -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/nss -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/nis -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/rt -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/resolv -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/crypt -L/build/buildd/glibc-2.3.6/build-tree/s390-s390x/linuxthreads -Wl,-rpath-link=/build/buildd/glibc-2.3.6/build-tree/s390-s390x:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/math:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/elf:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/dlfcn:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/nss:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/nis:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/rt:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/resolv:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/crypt:/build/buildd/glibc-2.3.6/build-tree/s390-s390x/linuxthreads -o /build/buildd/glibc-2.3.6/build-tree/s390-s390x/libc.so -T /build/buildd/glibc-2.3.6/build-tree/s390-s390x/shlib.lds /build/buildd/glibc-2.3.6/build-tree/s390-s390x/csu/abi-note.o /build/buildd/glibc-2.3.6/build-tree/s390-s390x/elf/soinit.os /build/buildd/glibc-2.3.6/build-tree/s390-s390x/libc_pic.os /build/buildd/glibc-2.3.6/build-tree/s390-s390x/elf/sofini.os /build/buildd/glibc-2.3.6/build-tree/s390-s390x/elf/interp.os /build/buildd/glibc-2.3.6/build-tree/s390-s390x/elf/ld.so -lgcc -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/s390-linux-gnu/4.0.4/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/s390-linux-gnu/4.0.4/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make[2]: *** [/build/buildd/glibc-2.3.6/build-tree/s390-s390x/libc.so] Error 1 make[2]: Leaving directory `/build/buildd/glibc-2.3.6/build-tree/glibc-2.3.6' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/glibc-2.3.6/build-tree/s390-s390x' make: *** [/build/buildd/glibc-2.3.6/stamp-dir/build_s390x] Error 2 ** Build finished at 20060531-0057 FAILED [dpkg-buildpackage died]
Bug#369492: glibc - FTBFS: error: syntax error before 'CFI_STARTPROC'
Package: glibc Version: 2.3.6-11 Severity: serious There was an error while trying to autobuild your package: Automatic build of glibc_2.3.6-11 on debian01 by sbuild/s390 85 [...] gcc-4.0 dl-error.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -pipe -I../include -I. -I/build/buildd/glibc-2.3.6/build-tree/s390-udeb/elf -I.. -I../libio -I/build/buildd/glibc-2.3.6/build-tree/s390-udeb -I../sysdeps/s390/s390-32/elf -I../libidn/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux/s390/s390-32 -I../linuxthreads/sysdeps/unix/sysv/linux/s390 -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/s390/s390-32 -I../linuxthreads/sysdeps/s390 -I../sysdeps/unix/sysv/linux/s390/s390-32 -I../sysdeps/unix/sysv/linux/s390 -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 -I../sysdeps/posix -I../sysdeps/s390/s390-32 -I../sysdeps/wordsize-32 -I../sysdeps/s390/fpu -I../sysdeps/s390 -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/s390-linux-gnu/4.0.4/include -isystem /build/buildd/glibc-2.3.6/debian/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /build/buildd/glibc-2.3.6/build-tree/s390-udeb/elf/dl-error.o -MD -MP -MF /build/buildd/glibc-2.3.6/build-tree/s390-udeb/elf/dl-error.o.dt -MT /build/buildd/glibc-2.3.6/build-tree/s390-udeb/elf/dl-error.o dl-runtime.c:222: error: syntax error before 'CFI_STARTPROC' make[3]: *** [/build/buildd/glibc-2.3.6/build-tree/s390-udeb/elf/dl-runtime.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/build/buildd/glibc-2.3.6/build-tree/glibc-2.3.6/elf' make[2]: *** [elf/subdir_lib] Error 2 make[2]: Leaving directory `/build/buildd/glibc-2.3.6/build-tree/glibc-2.3.6' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/glibc-2.3.6/build-tree/s390-udeb' make: *** [/build/buildd/glibc-2.3.6/stamp-dir/build_udeb] Error 2 ** Build finished at 20060530-0803 FAILED [dpkg-buildpackage died] Bastian
Re: TLS support (Re: linux-2.4 deprecated)
On Fri, Apr 07, 2006 at 10:44:26AM +0200, Matthias Klose wrote: - configure gcc with --disable-tls (on which architectures would that be (not) needed?) amd64, maybe hppa. Anything with supports tla in sarge and don't ship with 2.4 kernels. - build a libstdc++6 with a gcc, configured with --disable-tls and ship two versions? Would that help the upgrade issue? Yes, you have to follow the /lib/tls vs. /lib scheme. - provide TLS support for 2.4 kernels and an upgrade path? This is not a solution. Bastian -- Beam me up, Scotty, there's no intelligent life down here! signature.asc Description: Digital signature
Re: glibc-doc-reference_2.3.999-1_i386.changes UNACCEPT
On Sun, Mar 26, 2006 at 09:26:29PM +0200, Denis Barbier wrote: Does someone understand what is happening here? Someone/something removed the override entries after the package got moved into the accepted queue. Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
Re: [Pkg-xen-devel] Test version of the glibc with xen flavour
On Thu, Mar 23, 2006 at 12:55:13PM +0100, Ralph Passgang wrote: I am sorry to say, but I think the packages doesn't work as expected. I have installed your libc6, libc6-xen and libc6-dev package on my debian unstable system, where xen-3.0.1 is installed but it seems so that nothing has changed. I have checked that in dom0 and domU. You need some patches from the fedora glibc to support /etc/ld.so.config.d and mapped hwcaps. Bastian signature.asc Description: Digital signature
Re: Xen and glibc
On Thu, Mar 16, 2006 at 02:30:44PM +0100, Aurelien Jarno wrote: As already said on IRC, my main concern is that if we accept that, it will be more difficult to refuse some more flavors. I don't want to end up with 10 flavors of the glibc. If we stop to Xen, that's ok for me. You can also change the default behaviour of gcc as the assumptions that this works is not longer true even with glibc.. The setting have only little impact on the speed. On the technical points:: - The patch is not conditional, and it is currently not possible to use different sources for different flavors. But as it is fixed in glibc Which patch? Can't you read which is written before? - How we detect to use this flavor and not the tls or the default one? Is there any flag exported by the kernel? How is it done on other distributions? It is. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, Shore Leave, stardate 3025.3 signature.asc Description: Digital signature
Re: Xen and glibc
On Thu, Mar 16, 2006 at 02:41:09PM +0100, Bastian Blank wrote: - The patch is not conditional, and it is currently not possible to use different sources for different flavors. But as it is fixed in glibc Which patch? Can't you read which is written before? Excuse me, this was a little bit rude. The patch is not needed for 2.4. - How we detect to use this flavor and not the tls or the default one? Is there any flag exported by the kernel? How is it done on other distributions? It is. It defines another hwcap called nosegneg, which is exported via the elf aux sections. Bastian -- Is truth not truth for all? -- Natira, For the World is Hollow and I have Touched the Sky, stardate 5476.4. signature.asc Description: Digital signature
Re: r1175 - in glibc-package/trunk/debian: . control.in
On Tue, Feb 14, 2006 at 11:37:45PM +, Denis Barbier wrote: debian/control: Split Build-Depends on several lines for readability purpose. You have to unfold it for debian/control. Folding is only allowed for the Description field. Bastian -- No one wants war. -- Kirk, Errand of Mercy, stardate 3201.7 signature.asc Description: Digital signature
Re: r1175 - in glibc-package/trunk/debian: . control.in
On Wed, Feb 15, 2006 at 06:28:17PM +0100, Aurelien Jarno wrote: You have to unfold it for debian/control. Folding is only allowed for the Description field. Where is such a policy defined? I have found nothing forbidding that in the Debian policy and there is an example in section 7.1 using folding for the Build-Depends: line. 5.1: | Except where otherwise stated, only a single line of data is allowed and | whitespace is not significant in a field body. Whitespace must not | appear inside names (of packages, architectures, files or anything else) | or version numbers, or between the characters of multi-character version | relationships. And chapter 7 don't change this requirement. Bastian -- If a man had a child who'd gone anti-social, killed perhaps, he'd still tend to protect that child. -- McCoy, The Ultimate Computer, stardate 4731.3 signature.asc Description: Digital signature
Re: s390 buildd problems for glibc
On Sun, Nov 13, 2005 at 12:44:40PM -0500, Daniel Jacobowitz wrote: What kernel is the build daemon running? Does it have threading problems? I don't think glibc 2.3.5 has ever successfully autobuilt on s390. It was built on debian01 which runs 2.6.11. Bastian -- Youth doesn't excuse everything. -- Dr. Janice Lester (in Kirk's body), Turnabout Intruder, stardate 5928.5. signature.asc Description: Digital signature
Re: s390 buildd problems for glibc
On Sun, Nov 13, 2005 at 02:04:45PM -0500, Daniel Jacobowitz wrote: On Sun, Nov 13, 2005 at 07:30:47PM +0100, Bastian Blank wrote: On Sun, Nov 13, 2005 at 12:44:40PM -0500, Daniel Jacobowitz wrote: What kernel is the build daemon running? Does it have threading problems? I don't think glibc 2.3.5 has ever successfully autobuilt on s390. It was built on debian01 which runs 2.6.11. Thanks. Do you think these are likely to be problems in that kernel? No. But I can reschedule it on the other buildd which runs 2.6.12. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, Errand of Mercy, stardate 3198.9 signature.asc Description: Digital signature
Bug#301135: libc6: libacl/libcrypto/libasound all have PT_GNU_STACK enabled on them in glibc 2.3.4-1
On Mon, Sep 05, 2005 at 12:59:05AM +0200, Zoran Dzelajlija wrote: debian/patches/902_glibc-2.3.5-pt_pax-1.dpatch This adds some ELF-flags to elf.h. debian/patches/903_glibc-2.3.5-dl_execstack_PaX-2.dpatch This effectively removes any sanity check for executable stack. Bastian -- Spock: We suffered 23 casualties in that attack, Captain. signature.asc Description: Digital signature
