Bug#1080244: Memory corruption with ancient i386 binaries using stdio
Package: libc6 Version: 2.40-2 Severity: minor I have an executable that I compiled for i386 in (probably) 1998, which I have been running in a faily cron job until now. Today it failed to open a file, and strace showed that the filename was partially corrupted. Since the executable predates the use of ASLR, the memory corruption is reliably reproducible and I was able to catch it with gdb. The memory watchpoint is hit in __GI__IO_link_in() at: 123 _IO_list_all->file._prevchain = &fp->file._chain; 0xf7de4a44 <+612>: lea0x34(%esi),%ebp 0xf7de4a47 <+615>: mov%ebp,0x64(%ecx) => 0xf7de4a4a <+618>: jmp0xf7de498a <__GI__IO_link_in+426> 0xf7de4a4f <+623>: nop The backtrace is: #0 0xf7de4a4a in __GI__IO_link_in (fp=0x804a1a0) at ./libio/genops.c:123 #1 0xf7ed9267 in _IO_old_file_init_internal (fp=0x804a1a0) at ./libio/oldfileops.c:106 #2 0xf7ed7e5b in _IO_old_fopen ( filename=0x8049c9c "/home/ben/.base-ԡ\004\b", mode=0x8048b43 "r") at ./libio/oldiofopen.c:54 #3 0x0804887a in main () At this point _IO_list_all points to _IO_stderr_, which for some reason is *in the executable's BSS section*: 08049c48 ld .bss .bss 08049c9c l O .bss 0100 base_n.4 08049d9c l O .bss 0100 rand_n.5 08049e9c l O .bss 0100 sig_n.6 08049c48 g O .bss 0050 _IO_stderr_ 08049c98 w .bss 0004 _environ 08049c98 g O .bss 0004 __environ 08049c48 g O *ABS* __bss_start The size allocated for _IO_stderr_ in the executable appears to be 80 bytes, which is rather smaller than the current size of struct _IO_FILE_plus (152 bytes), so the assignment to _IO_list_all->file._prevchain overwrites the following static data (base_n) containing the filename. I'm just going to recompile the executable, but I will keep the old one around for a while in case anyone feels like investigating further. Ben. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6 depends on: ii libgcc-s1 14.2.0-4 Versions of packages libc6 recommends: ii libidn2-0 2.3.7-2 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.87 ii glibc-doc 2.40-2 ii libc-l10n 2.40-2 ii libnss-nis 3.1-5 ii libnss-nisplus 1.3-5+b1 ii locales2.40-2 -- debconf-show failed
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
I don't know if this should be a blocker, but the MIPS builders are
still extremely slow for kernel builds. In the worst case (mipsel:
mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
than the next slowest group of builders (armhf: hasse, henze, holby).
This can be a problem for getting security updates out promptly.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
signature.asc
Description: This is a digitally signed message part
Bug#898743: breaks when #included after
Control: reassign -1 libc6-dev Control: severity -1 normal On Tue, 15 May 2018 16:57:57 +0200 Helmut Grohne wrote: > Package: linux-libc-dev,libc6-dev > Severity: serious > Justification: makes systemd ftbfs > User: helm...@debian.org > Usertags: rebootstrap > Control: affects -1 + src:systemd libmount-dev > > systemd FTBFS here, because compiling load-fragment.c fails. I spent a while > minimizing that file and it boils down to: > > $ cat test.c > #include > #include > $ gcc -c test.c > In file included from test.c:1:0: > /usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier > before numeric constant >MS_RDONLY = 1, /* Mount read-only. */ >^ > $ > > linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an > enum containing MS_RDONLY. That's a problem. [...] has defined MS_RDONLY as a macro since before version 1.0, so this is a wontfix on the kernel side. was already defining MS_RDONLY as both enumerator and macro in jessie, so this doesn't seem to be a regression. Downgrading and reassigning to just libc6-dev, but I fully expect this to be wontfix on that side as well. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Re: busybox sh broken on i386 with glibc 2.26, leads to kernel panic
On Sun, 2018-01-21 at 12:18 +0100, Aurelien Jarno wrote: > On 2018-01-21 00:47, Ben Hutchings wrote: > > On Wed, 17 Jan 2018 12:31:06 +0100 Aurelien Jarno > > wrote: > > [...] > > > busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has > > > the same effect of reducing the default stack alignment from 16 bytes to > > > 2 bytes. This comes from arch/i386/Makefile: > > > > The argument is the log2 of the alignment, so this sets alignment to 4 > > bytes - which is compliant with the System V psABI for i386. > > This is correct, but it is not compliant with the i386 GCC ABI which > assumes the stack is 16-byte aligned (not just 4-byte aligned) when the > call instruction in the caller was executed. Yes, that's what I think the bug is - gcc's default ABI for i386-linux-gnu was quietly changed. > > Any assumption of 16-byte stack alignment in glibc on i386 will break > > not only busybox but most binaries built with old versions of gcc > > (before 4.2, if the comment in busybox is correct). So this really > > ought to be fixed there. > > The 16-byte stack alignment in glibc on i386 comes from a GCC 7 > regression, reported as bug #887327. It has been fixed in the upstream > gcc-7 branch in the mean time. > > > I think that any libraries that need to maintain backward binary > > compatibility will need to be compiled with the option > > -mincoming-stack-boundary=2. gcc will then fix up the stack alignment > > in functions that need greater alignment for local variables. > > If we allow any binary to be built with -mpreferred-stack-boundary=2, > we need to build *all* libraries with -mincoming-stack-boundary=2, not > only the ones that need to maintain backward binary compatibility. That's true, but we could also specify that if you mess with stack alignment you can only use libc6 and other libraries whose ABI pre- dates the change in gcc. (I don't know where we would do that; I haven't seen any formal specifications of Debian architectures.) > In that case we should make it the default in GCC. I think there are quite few libraries where this would be necessary. I could be wrong. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: busybox sh broken on i386 with glibc 2.26, leads to kernel panic
On Wed, 17 Jan 2018 12:31:06 +0100 Aurelien Jarno wrote: [...] > busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has > the same effect of reducing the default stack alignment from 16 bytes to > 2 bytes. This comes from arch/i386/Makefile: The argument is the log2 of the alignment, so this sets alignment to 4 bytes - which is compliant with the System V psABI for i386. Any assumption of 16-byte stack alignment in glibc on i386 will break not only busybox but most binaries built with old versions of gcc (before 4.2, if the comment in busybox is correct). So this really ought to be fixed there. I think that any libraries that need to maintain backward binary compatibility will need to be compiled with the option -mincoming-stack-boundary=2. gcc will then fix up the stack alignment in functions that need greater alignment for local variables. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Bug#847478: FTBFS: needs to Build-Depends on gperf
Control: retitle -1 Locale hash tables are not built from source; rebuilding requires gperf Control: tag -1 - moreinfo Control: severity -1 normal On Sun, 18 Dec 2016 22:28:33 +0100 Aurelien Jarno wrote: > control: tag -1 + moreinfo > > On 2016-12-08 16:42, Ximin Luo wrote: > > Package: glibc > > Version: 2.24-7 > > Severity: serious > > Tags: patch > > Justification: fails to build from source (but built successfully in the > > past) > > > > Dear Maintainer, > > > > whilst trying to build glibc: > > > > /usr/bin/install -c -m 644 > > /tmp/debrepro.uGH5xEsmL1/build/source/build-tree/amd64-libc/gnu/lib-names-64.h > > > > /tmp/debrepro.uGH5xEsmL1/build/source/debian/tmp-libc/usr/include/gnu/lib-names-64.h > > /usr/bin/install -c -m 644 > > /tmp/debrepro.uGH5xEsmL1/build/source/build-tree/amd64-libc/libBrokenLocale.map > > > > /tmp/debrepro.uGH5xEsmL1/build/source/debian/tmp-libc/usr/lib/x86_64-linux-gnu/libBrokenLocale_pic.map > > cd programs \ > > && gperf -acCgopt -k1,2,5,9,$ -L ANSI-C -N charmap_hash charmap-kw.gperf > > > charmap-kw.h.new > > /bin/bash: line 1: gperf: command not found > > Makefile:66: recipe for target 'programs/charmap-kw.h' failed [...] > Strange, I am not able to reproduce the problem, the package built fine > here. Also it built fine on the build daemons for quite some time and > there hasn't been any recent change besides hurd one. > > Are you doing something special to trigger this bug? Do you have the > build log? Looking for gperf in the source, I see: [locale/Makefile] programs/%-kw.h: programs/%-kw.gperf cd programs \ && $(GPERF) $(GPERFFLAGS) -N $(@F:-kw.h=_hash) $( $(@F).new mv -f $@.new $@ and there are these files: -rw-rw 1 ben ben 1553 Aug 2 03:01 locale/programs/charmap-kw.gperf -rw-rw 1 ben ben 7086 Aug 2 03:01 locale/programs/charmap-kw.h -rw-rw 1 ben ben 10382 Aug 2 03:01 locale/programs/locfile-kw.gperf -rw-rw 1 ben ben 25742 Aug 2 03:01 locale/programs/locfile-kw.h All the timestamps are equal in the upstream tarball, but if the .gperf files are touched before building it will result in this build failure. Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part
Re: libc recently more aggressive about pthread locks in stable ?
On Sat, 2016-11-05 at 20:32 +0100, Christian Seiler wrote: > On 11/05/2016 08:13 PM, Ian Jackson wrote: > > I have just been debugging a ghostscript segfault on jessie amd64. > > > > Looking at the code, I think that gs in jessie is plainly violating > > the rules about the use of pthread locks. On my partner's machine, > > this makes it segfault on termination (with some input files, at > > least). On my machine it works just fine. The code in sid is better. > > > > I recently encountered what seems to be a similar bug in ogg123 in > > stable. #842796. > > > > Has something changed in jessie's libc recently ? I find it difficult > > to imagine that these bugs would have been missed earlier during the > > life of jessie. > > Recently Frank Fegert discovered a problem with locking in open-iscsi > that only occurs on new hardware. The code previously was wrong, but > earlier CPUs were more forgiving when it came to this error and it > couldn't be triggered. > > Frank wrote about the problem in his blog in great detail: > http://www.bityard.org/blog/2016/08/05/debugging_segfaults_open-iscsi_iscsiuio_intel_broadwell [...] This is not really a case of older CPUs being 'more forgiving'; they had no locking operations[*] and nothing to forgive. However, glibc uses transactional memory (TSX) on the newer CPUs that implement it, and that new code does result in the CPU detecting some locking errors. It's worth noting that TSX is broken in 'Haswell' processors and is supposed to be disabled via a microcode update. I don't know whether glibc avoids using it on these processors if the microcode update is not applied. (Linux doesn't appear to hide the feature flags.) * The LOCK prefix is for 'bus locking' during a single instruction, i.e. making it atomic. The CPU can't know what higher-level operation it's being used for. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#824442: and conflict needs to be resolved
Source: glibc Version: 2.22-7 Severity: serious (Continued from bug #822393.) glibc's should check whether has already been included and, if so, avoid making conflicting definitions. Including the headers in the opposite order works since this change in Linux 4.6: https://git.kernel.org/linus/4a91cb61bb995e5571098188092e296192309c77 Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#822393: and conflict needs to be resolved
Control: reassign -1 src:linux 4.5.1-1 The kernel side of this has been implemented upstream in Linux 4.6. As it's not possible to clone a merged bug, I'm assigning this to the kernel only and will open a separate bug for glibc. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#822393: marked as done ( and conflict needs to be resolved)
Control: reopen -1 Control: notfixed -1 connman/1.32-0.1 On Mon, 2016-05-02 at 18:54 +, Debian Bug Tracking System wrote: > Your message dated Mon, 02 May 2016 18:50:07 + > with message-id > and subject line Bug#822393: fixed in connman 1.32-0.1 > has caused the Debian Bug report #822393, > regarding and conflict needs to be resolved > to be marked as done. This bug was not assigned to connman any more. You made connman work around it, but you didn't fix the bug. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#781715: libc-bin: ldconfig crashes with SIGSEGV, with large kernel version value.
Control: severity -1 minor > It is possible that it cannot handle my extremely high kernel version > number of 3.14.3720150331. The value 3720150331 exceeds the length of a > signed 32-bit integer. I have never had such a problem before with > lower valued version numbers. The KERNEL_VERSION macro defined in limits the range of the third component to 8 bits: #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) So this is certainly not an important bug. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Bug#803927: Please test eglibc 2.11.3-4+deb6u8
On Wed, 2015-11-25 at 01:27 +0100, Raphael Hertzog wrote: > On Tue, 24 Nov 2015, Ben Hutchings wrote: > > You should copy out the test output file so it's possible to see which > > step of the mqueue5 test failed. > > > > There are some recent changes to the mqueue implementation in Linux > > that might possibly have caused this (not because they are known buggy, > > but they may have user-visible effects). However it's fairly pointless > > for me to look any further without that test output. > > In a build in a normal chroot (not a minimal-sbuild one), I only got the > failure > for the amd64-i386 build: > ┏(squeeze-amd64) x230-buxy:~/deb/lts/pkg/eglibc-2.11.3 > ┗(543)$ cat build-tree/amd64-i386/rt/tst-mqueue5.out > SIGRTMIN signal in child did not arrive > child failed with status 256 The test doesn't fail reliably. Running tst-mqueue5 program against the current libc6-686, 7 out of 100 runs failed in this way. Running it against the new libc6, 8 out of 100 failed. (Both in a squeeze:i386 chroot with a 4.2 amd64 kernel.) Whatever is going wrong here, I don't think it's a regression. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Bug#803927: Please test eglibc 2.11.3-4+deb6u8
On Tue, 2015-11-24 at 17:23 +0100, Raphael Hertzog wrote: > Hello, > > I have backported the upstream patch for squeeze and it results in the > attached patch. It does compile and I have not identified any regression > but the build log mentions unexpected testsuite failures. > > Comparing with a build of the the previous version, I get only one > supplementary failure: > @@ -50775,10 +50775,12 @@ > bug-regex32.out, Error 1 > check-localplt.out, Error 1 > tst-atime.out, Error 1 > +tst-mqueue5.out, Error 1 > *** > Encountered regressions that don't match expected failures: > bug-regex32.out, Error 1 > tst-atime.out, Error 1 > +tst-mqueue5.out, Error 1 > *** [...] You should copy out the test output file so it's possible to see which step of the mqueue5 test failed. There are some recent changes to the mqueue implementation in Linux that might possibly have caused this (not because they are known buggy, but they may have user-visible effects). However it's fairly pointless for me to look any further without that test output. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
squeeze update of eglibc?
The Debian LTS team would like to fix the security issues which are currently open in the Squeeze version of eglibc: https://security-tracker.debian.org/tracker/TEMP-000-1FEA47 Would you like to take care of this yourself? We are still understaffed so any help is always highly appreciated. If yes, please follow the workflow we have defined here: http://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-...@lists.debian.org (via a debdiff, or with an URL pointing to the the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. Thank you very much. Ben Hutchings, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup -- Ben Hutchings - Debian developer, member of Linux kernel and LTS teams signature.asc Description: This is a digitally signed message part
Re: squeeze update of eglibc
On Sat, 2015-02-28 at 21:02 +, Ben Hutchings wrote: > I've started preparing an update to eglibc, fixing the many open > security issues of lower severity than those fixed recently. > > I didn't yet had time to test it properly, so I've uploaded my work to > <https://people.debian.org/~benh/packages/squeeze-lts/> so others can > test further and maybe complete the update. The version number there is > 2.11.3-4+deb6u5~benh.1 but the real update should be 2.11.3-4+deb6u5. > > There don't appear to be any regressions in compiler warnings, and > nothing went obviously wrong when I installed the new libraries in a VM. > > However, for the current version, 2.11.3-4+deb6u4, the build log shows 1 > unexpected test suite failure for each of the library configurations: > > Encountered regressions that don't match expected failures: > bug-regex32.out, Error 1 > > while for my version, 2.11.3-4+deb6u5~benh.1, there were several more: > > [i386] > Encountered regressions that don't match expected failures: > bug-regex32.out, Error 1 > tst-cancel4.out, Error 1 > tst-cancel5.out, Error 1 > tst-nice.out, Error 1 [...] I now understand all the regressions: - tst-nice failed because I run pbuilder with 'nice -19' and the test process then can't change its niceness. It passes without this. - tst-cancel4 (and the three variants compiled in different ways) fails as the minimum kernel socket buffer size is now larger than it assumes. I cherry-picked a fix from glibc git and it now passes. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
squeeze update of eglibc
I've started preparing an update to eglibc, fixing the many open security issues of lower severity than those fixed recently. I didn't yet had time to test it properly, so I've uploaded my work to <https://people.debian.org/~benh/packages/squeeze-lts/> so others can test further and maybe complete the update. The version number there is 2.11.3-4+deb6u5~benh.1 but the real update should be 2.11.3-4+deb6u5. There don't appear to be any regressions in compiler warnings, and nothing went obviously wrong when I installed the new libraries in a VM. However, for the current version, 2.11.3-4+deb6u4, the build log shows 1 unexpected test suite failure for each of the library configurations: Encountered regressions that don't match expected failures: bug-regex32.out, Error 1 while for my version, 2.11.3-4+deb6u5~benh.1, there were several more: [i386] Encountered regressions that don't match expected failures: bug-regex32.out, Error 1 tst-cancel4.out, Error 1 tst-cancel5.out, Error 1 tst-nice.out, Error 1 [i686] Encountered regressions that don't match expected failures: bug-regex32.out, Error 1 tst-cancel4.out, Error 1 tst-cancel5.out, Error 1 tst-nice.out, Error 1 [xen] Encountered regressions that don't match expected failures: bug-regex32.out, Error 1 tst-cancel4.out, Error 1 tst-cancel5.out, Error 1 tst-nice.out, Error 1 [amd64] Encountered regressions that don't match expected failures: bug-regex32.out, Error 1 tst-cancel4.out, Error 1 tst-cancel5.out, Error 1 tst-cancelx4.out, Error 1 tst-cancelx5.out, Error 1 tst-nice.out, Error 1 I don't yet know whether these are genuine regressions or due to a difference in the build environment. I also haven't carefully reviewed all the patches to look at whether any further adjustments are needed due to internal API changes. I've uploaded my build logs along with the packages in case they're useful. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: squeeze update of eglibc?
On Mon, 2015-02-23 at 11:54 +0100, Raphael Hertzog wrote: > Hello dear maintainer(s), > > the Debian LTS team would like to fix the security issues which are > currently open in the Squeeze version of your package: > https://security-tracker.debian.org/tracker/source-package/eglibc > > Would you like to take care of this yourself? > > If yes, please follow the workflow we have defined here: > http://wiki.debian.org/LTS/Development [...] I've now claimed this, but as there are many issues and (e)glibc is a complex package I would be quite happy to hand over to the regular maintainers, or to share the work via a public repository. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#722075: libc6: getaddrinfo() sends DNS queries to random file descriptors
On Wed, 2015-02-11 at 22:11 +0100, Aurelien Jarno wrote: > Control: notfound -1 eglibc 2.13-38+deb7u7 > Control: fixed -1 eglibc/2.13-38+deb7u5 > > On 2015-01-29 23:53, Ben Hutchings wrote: > > Control: retitle -1 libc6: getaddrinfo() sends DNS queries to random file > > descriptors (CVE-2013-7423) > > Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=15946 > > Control: severity -1 serious > > Control: found -1 eglibc 2.11.3-4+deb6u4 > > Control: found -1 eglibc 2.13-38+deb7u7 > > > > This bug came up again at > > <http://www.openwall.com/lists/oss-security/2015/01/28/16>. It still > > needs fixing in wheezy and squeeze-lts. > > It does NOT need to be fixed on wheezy, as it was already done a few > months ago as part of the 2.13-38+deb7u5 upload: [...] Sorry Aurelien, I assumed this was a 3.0 (quilt) package so I mistakenly looked at the unpatched source. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#722075: libc6: getaddrinfo() sends DNS queries to random file descriptors
Control: retitle -1 libc6: getaddrinfo() sends DNS queries to random file descriptors (CVE-2013-7423) Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=15946 Control: severity -1 serious Control: found -1 eglibc 2.11.3-4+deb6u4 Control: found -1 eglibc 2.13-38+deb7u7 This bug came up again at <http://www.openwall.com/lists/oss-security/2015/01/28/16>. It still needs fixing in wheezy and squeeze-lts. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Bug#737697: Missing EFD_SEMAPHORE in on sparc
Package: libc6-dev Version: 2.17-97 Severity: normal Linux defines EFD_SEMAPHORE as 1 in , which is not architecture-specific. For some reason this isn't a UAPI definition and glibc has its own copy of the EFD flag definitions in . However, EFD_SEMAPHORE is missing from on sparc. Please ensure that it is defined correctly on all architectures. Ben. -- 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/20140205041247.4386.7809.report...@deadeye.wl.decadent.org.uk
Re: Bug#717557: gcc-4.8: can't compile working 64bit kernel with 32bit userspace gcc-4.8
On Sun, 2013-10-20 at 23:44 +0200, Matthias Klose wrote: > Am 20.10.2013 22:58, schrieb Ben Hutchings: > > On Sun, 2013-10-20 at 22:21 +0200, Matthias Klose wrote: > >> Am 20.10.2013 00:25, schrieb Ben Hutchings: > >>> On Sat, 2013-10-19 at 23:38 +0200, Matthias Klose wrote: > >>>> Control: severity -1 important Control: tags -1 + moreinfo > >>>> > >>>>>> In file included from :0:0: > >>>>>> /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: > >>>>>> No such file > >>>>> or directory > >>>>>> #include ^ > >>>>> compilation terminated. > >>>>> > >>>>> It looks like I can avoid this by changing the compile tests to > >>>>> use the -nostdinc option. But this change may possibly cause > >>>>> other problems, and neither the pre-included header nor the fact > >>>>> that -nostdinc disables it seem to be documented. > >>>> > >>>> please attach the test program and the command line options used for > >>>> this test case. I think the issue is within the kernel build system > >>>> not being prepared for multiarch and -nostdinc. > >>> > >>> gcc-4.8 -m64 -x c -c /dev/null > >> > >> works for me on a current sid/i386. I assume that gcc-4.8-multilib is > >> installed? > > > > No, it works if that's installed. But gcc-X.Y-multilib was previously only > > needed for building with a 64-bit C library, not for building a 64-bit > > kernel. > > > > If this kernel configuration was actually failing to build without > > gcc-4.8-multilib, I wouldn't mind so much. The problem is that it's built > > wrongly now. Maybe some later version of the kernel will be changed to > > detect or work around this problem, but we have to assume people will still > > try to build older versions not using -nostdinc for some time to come. > > Is this due to the missing /usr/include/asm symlink shipped in gcc-multilib? > It's not ideal, and I think I did file a bug report that this should be > shipped in one of the glibc packages, but can't find it anymore. The /usr/include/bits symlink in libc6-dev-amd64 is what makes this work again (which is disgusting, really...). Without that, stdc-predef.h can be found but not bits/predefs.h. > > The options to deal with this include: 1. Make missing headers non-fatal > > while pre-including . > > that would be the responsibility of those packages using non-standard options > like -nostdinc. Well the problem occurs because Linux uses -nostdinc only in the real compiles (so they succeed) but not the test compiles (so they fail). > > 2. Disable pre-inclusion of . > > no, done upstream to conform to standards. > > > 3. Make 32-bit gcc fail to compile anything with -m64 if gcc-X.Y-multilib > > is not installed, even if -nostdinc is used. > > welcome to multiarch, and thanks for upstreaming patches to fix these issues. > > > 4. Make gcc-X.Y depend on gcc-X.Y-multilib on architectures where it > > exists. > > well, then you can merge these again. the whole point to have them separate > were bug reports about being forced to install the non-defaults multilibs by > default. Indeed, I didn't say any of those options were good. > 5. Install the whole glibc headers into the multiarch header path. Would fix > some other things too, like allowing multiarch configurations for non-glibc > based triplets. And I assume it would allow your build to fail. I don't think this would help. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Bug#707185: libc6:amd64 does not replace libc6-amd64; preinst fails
Package: src:eglibc Version: 2.17-1 Severity: important This upgrade failed: $ sudo apt-get install linux-libc-dev Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libc-dev-bin libc6:amd64 libc6 libc6-amd64 libc6-dbg libc6-dev:amd64 libc6-dev libc6-dev-amd64 libc6-i686 linux-libc-dev:amd64 locales [why did APT want to upgrade these anyway?] Suggested packages: glibc-doc:amd64 locales:amd64 glibc-doc manpages-dev:amd64 Recommended packages: gcc:amd64 c-compiler:amd64 The following packages will be upgraded: libc-dev-bin libc6:amd64 libc6 libc6-amd64 libc6-dbg libc6-dev:amd64 libc6-dev libc6-dev-amd64 libc6-i686 linux-libc-dev:amd64 linux-libc-dev locales 12 upgraded, 0 newly installed, 0 to remove and 439 not upgraded. Need to get 37.3 MB of archives. After this operation, 14.7 MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://cdn.debian.net/debian/ sid/main libc6-dev-amd64 i386 2.17-1 [2,604 kB] Get:2 http://cdn.debian.net/debian/ sid/main libc6-amd64 i386 2.17-1 [4,863 kB] Get:3 http://cdn.debian.net/debian/ sid/main linux-libc-dev amd64 3.8.11-1 [842 kB] Get:4 http://cdn.debian.net/debian/ sid/main linux-libc-dev i386 3.8.11-1 [843 kB] Get:5 http://cdn.debian.net/debian/ sid/main libc6-dev i386 2.17-1 [5,542 kB] Get:6 http://cdn.debian.net/debian/ sid/main libc6-dev amd64 2.17-1 [3,147 kB] Get:7 http://cdn.debian.net/debian/ sid/main libc-dev-bin i386 2.17-1 [227 kB] Get:8 http://cdn.debian.net/debian/ sid/main locales all 2.17-1 [3,816 kB] Get:9 http://cdn.debian.net/debian/ sid/main libc6 amd64 2.17-1 [4,766 kB] Get:10 http://cdn.debian.net/debian/ sid/main libc6 i386 2.17-1 [4,131 kB] Get:11 http://cdn.debian.net/debian/ sid/main libc6-i686 i386 2.17-1 [1,450 kB] Get:12 http://cdn.debian.net/debian/ sid/main libc6-dbg i386 2.17-1 [5,090 kB] Fetched 37.3 MB in 1min 6s (564 kB/s) Reading changelogs... Done Preconfiguring packages ... (Reading database ... 241833 files and directories currently installed.) Preparing to replace libc6-dev-amd64 2.13-38 (using .../libc6-dev-amd64_2.17-1_i386.deb) ... Unpacking replacement libc6-dev-amd64 ... Preparing to replace libc6-amd64 2.13-38 (using .../libc6-amd64_2.17-1_i386.deb) ... Unpacking replacement libc6-amd64 ... Replaced by files in installed package libc6:amd64 ... Preparing to replace linux-libc-dev:i386 3.2.39-2 (using .../linux-libc-dev_3.8.11-1_i386.deb) ... De-configuring linux-libc-dev:amd64 ... Unpacking replacement linux-libc-dev:i386 ... Preparing to replace linux-libc-dev:amd64 3.2.39-2 (using .../linux-libc-dev_3.8.11-1_amd64.deb) ... Unpacking replacement linux-libc-dev:amd64 ... Setting up linux-libc-dev:i386 (3.8.11-1) ... Setting up linux-libc-dev:amd64 (3.8.11-1) ... (Reading database ... 241766 files and directories currently installed.) Preparing to replace libc6-dev:amd64 2.13-38 (using .../libc6-dev_2.17-1_amd64.deb) ... De-configuring libc6-dev:i386 ... Unpacking replacement libc6-dev:amd64 ... Preparing to replace libc6-dev:i386 2.13-38 (using .../libc6-dev_2.17-1_i386.deb) ... Unpacking replacement libc6-dev:i386 ... Preparing to replace locales 2.13-38 (using .../locales_2.17-1_all.deb) ... Unpacking replacement locales ... Preparing to replace libc6:i386 2.13-38 (using .../archives/libc6_2.17-1_i386.deb) ... De-configuring libc6:amd64 ... Checking for services that may need to be restarted... Checking init scripts... Unpacking replacement libc6:i386 ... Preparing to replace libc6:amd64 2.13-38 (using .../libc6_2.17-1_amd64.deb) ... Checking for services that may need to be restarted... Checking init scripts... dpkg: error processing /var/cache/apt/archives/libc6_2.17-1_amd64.deb (--unpack): subprocess new pre-installation script returned error exit status 1 Processing triggers for man-db ... Processing triggers for lintian ... Errors were encountered while processing: /var/cache/apt/archives/libc6_2.17-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) It's not very nice of the preinst to fail without explanation, is it? So I repacked it with set +x added and the installation ended with: + echo Checking init scripts... Checking init scripts... + runlevel + sed s/.*\ // + rl=5 + [ -n ] + [ amd64 = armhf ] + touch /etc/ld.so.nohwcap + readlink -e /lib64/ld-linux-x86-64.so.2 + ldfile= OK, where is /lib64/ld-linux-x86-64.so.2 pointing? To ld-2.13.so, which does not exist. This is left over from libc6-amd64, which dpkg has mostly but not entirely removed in preparation for the upgrade that replaces it. Here's the dpkg log for this: 2013-05-08 01:33:52 startup archives unpack 2013-05-08 01:33:52 upgrade libc6-dev-amd64:i386 2.13-38 2.17-1 2013-05-08 01:33:52 status half-configured libc6-dev-amd64:i386 2.13-38 2013-05-08 01:33:52 status unpacked libc6-dev-amd64:i386 2.13-38 2013-05-08 01:33:52
Re: Missing accept4 for ia64
On Sat, 2012-01-28 at 22:43 +0100, Aurelien Jarno wrote: > On Sat, Jan 28, 2012 at 03:09:49PM +0000, Ben Hutchings wrote: > > On Sat, 2012-01-28 at 13:41 +0100, Émeric Maschino wrote: > > > Hello Ben, > > > > > > IIRC, to completely fix this issue, (e)glibc must be recompiled > > > against updated kernel. > > > Is there a bug report to track this? > > > Do you know when this updated (e)glibc is planned? > > > > I'm not aware that there is a bug report on eglibc regarding this. > > > > I believe that only a binNMU is required, i.e. a request for a automatic > > rebuild. I'll leave that to the maintainers to decide. > > > > I am planning an upload probably tomorrow. That said, I don't know what > is the exact problem, so i don't know if it is going to be fixed with a > rebuild. accept4() was not implemented by Linux on ia64 for a long time. I believe eglibc will define the C wrapper automatically when built against the updated linux-libc-dev. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Missing accept4 for ia64
On Sat, 2012-01-28 at 13:41 +0100, Émeric Maschino wrote: > Hello Ben, > > IIRC, to completely fix this issue, (e)glibc must be recompiled > against updated kernel. > Is there a bug report to track this? > Do you know when this updated (e)glibc is planned? I'm not aware that there is a bug report on eglibc regarding this. I believe that only a binNMU is required, i.e. a request for a automatic rebuild. I'll leave that to the maintainers to decide. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Bug#638810: [PATCH] Add bindresvport6() implementation.
Convert existing bindresvport() implementation into a more generic
function used by both bindresvport() and bindresvport6().
---
The symbol version changes for this are a bit of a guess; I really have
no idea what the difference is between the definitions in Versions and
abilist/libc.abilist.
Ben.
bindrsvprt.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
--- eglibc-2.13.orig/sunrpc/bindrsvprt.c
+++ eglibc-2.13/sunrpc/bindrsvprt.c
@@ -121,29 +121,17 @@
/*
* Bind a socket to a privileged IP port
*/
-int
-bindresvport (int sd, struct sockaddr_in *sin)
+static int
+__bindresvport (int sd, struct sockaddr *addr, size_t addrlen,
+ in_port_t *addrport)
{
static short startport = STARTPORT;
static short port;
- struct sockaddr_in myaddr;
int i;
if (!blacklist_read)
load_blacklist ();
- if (sin == (struct sockaddr_in *) 0)
-{
- sin = &myaddr;
- __bzero (sin, sizeof (*sin));
- sin->sin_family = AF_INET;
-}
- else if (sin->sin_family != AF_INET)
-{
- __set_errno (EAFNOSUPPORT);
- return -1;
-}
-
if (port == 0)
{
port = (__getpid () % NPORTS) + STARTPORT;
@@ -160,14 +148,14 @@
{
int j;
- sin->sin_port = htons (port);
+ *addrport = htons (port);
/* Check, if this port is not blacklisted. */
for (j = 0; j < list_size; j++)
if (port == list[j])
goto try_next_port;
- res = __bind (sd, sin, sizeof (struct sockaddr_in));
+ res = __bind (sd, addr, addrlen);
if (res >= 0 || errno != EADDRINUSE)
break;
@@ -187,4 +175,46 @@
return res;
}
+
+int
+bindresvport (int sd, struct sockaddr_in *sin)
+{
+ struct sockaddr_in myaddr;
+
+ if (sin == (struct sockaddr_in *) 0)
+{
+ sin = &myaddr;
+ __bzero (sin, sizeof (*sin));
+ sin->sin_family = AF_INET;
+}
+ else if (sin->sin_family != AF_INET)
+{
+ __set_errno (EAFNOSUPPORT);
+ return -1;
+}
+
+ return __bindresvport (sd, (struct sockaddr *) sin, sizeof (*sin),
+&sin->sin_port);
+}
libc_hidden_def (bindresvport)
+
+int
+bindresvport6 (int sd, struct sockaddr_in6 *sin6)
+{
+ struct sockaddr_in6 myaddr;
+
+ if (sin6 == (struct sockaddr_in6 *) 0)
+{
+ sin6 = &myaddr;
+ __bzero (sin6, sizeof (*sin6));
+ sin6->sin6_family = AF_INET6;
+}
+ else if (sin6->sin6_family != AF_INET6)
+{
+ __set_errno (EAFNOSUPPORT);
+ return -1;
+}
+
+ return __bindresvport (sd, (struct sockaddr *) sin6, sizeof (*sin6),
+&sin6->sin6_port);
+}
--- eglibc-2.13.orig/sunrpc/Versions
+++ eglibc-2.13/sunrpc/Versions
@@ -116,6 +116,9 @@
GLIBC_2.3.4 {
xdr_quad_t; xdr_u_quad_t;
}
+ GLIBC_2.13_DEBIAN {
+bindresvport6;
+ }
GLIBC_PRIVATE {
__libc_clntudp_bufcreate; __libc_rpc_getport;
}
--- eglibc-2.13.orig/Versions.def
+++ eglibc-2.13/Versions.def
@@ -30,6 +30,7 @@
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
+ GLIBC_2.13_DEBIAN
%ifdef USE_IN_LIBIO
HURD_CTHREADS_0.3
%endif
--- eglibc-2.13.orig/abilist/libc.abilist
+++ eglibc-2.13/abilist/libc.abilist
@@ -2229,3 +2229,5 @@
GLIBC_2.3 ia64-.*-linux.*/tls powerpc64-.*-linux.*/thread s390x-.*-linux.*/tls
x86_64-.*-linux.*/tls
_sys_errlist D 0x3f0
sys_errlist D 0x3f0
+GLIBC_2.13_DEBIAN .*-.*-linux.* .*-.*-gnu-gnu.* .*-.*-freebsd.*-gnu.*
+ bindresvport6 F
---
signature.asc
Description: This is a digitally signed message part
Bug#522774: Bug#522773: possible solutions for __unused problem
On Sun, 2011-06-19 at 18:24 +, Thorsten Glaser wrote: > Robert Millan dixit: > > >I can see they wouldn't be excited about it, but they might also accept > > You know that there are more than one BSD, but only one glibc, > IIRC Drepper isn’t even its maintainer any more. According to <http://www.gnu.org/software/libc/> "Ulrich Drepper is currently the foremost contributor and has overall responsibility for maintenance and development." > Try persuading > for example Theo de Raadt of anything which doesn’t have any > immediate technical merit… have fun ;-) > > Honestly, when resolving this I’d go for “who has the older > rights”. Maybe look at how CSUR resolves different claims to > the same part of the Unicode PUA, or something like that. > Nevertheless, thanks on picking this up. Debian GNU/Linux is the older system; the Debian GNU/kFreeBSD maintainers have to deal with compatibility issues. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#614883: Does not set local time offset for kernel
Package: tzdata
Version: 2011b-2
Severity: normal
The kernel maintains a local time offset which is used for some stupid
filesystems that are defined to store local times in their timestamps.
The offset is initialised by hwclock which is invoked at boot time by
/etc/init/hwclockfirst.sh.
The offset should also be updated whenever the system time zone is
reconfigured. This can be done by code along the following lines:
#define _BSD_SOURCE
#define _XOPEN_SOURCE
#include
#include
int main(void)
{
struct timezone tz;
tzset();
tz.tz_minuteswest = timezone / 60;
tz.tz_dsttime = 0;
if (settimeofday(NULL, &tz)) {
perror("settimeofday");
return 1;
}
return 0;
}
The local time offset should also be updated when DST begins and ends,
but this would be substantially harder to arrange.
Ben.
-- System Information:
Debian Release: wheezy/sid
APT prefers oldstable-proposed-updates
APT policy: (500, 'oldstable-proposed-updates'), (500, 'unstable'), (1,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.37-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tzdata depends on:
ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy
tzdata recommends no packages.
tzdata suggests no packages.
-- 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/20110223231003.20465.2158.reportbug@localhost
Bug#614882: {get,set}timeofday declared with incorrect '__nonnull' attribute
Package: libc6-dev
Version: 2.11.2-11
Severity: normal
On Linux it is valid to call {get,set}timeofday() with a null timeval
pointer and non-null timezone pointer. This will get or set the
kernel's local time offset, which is used for converting timestamps on
brain-dead filesystems like VFAT. settimeofday(NULL, tz) is also used
to fix the system time during the boot process if the RTC is set to
local time for compatibility with a similarly brain-dead operating
system.
Ben.
-- System Information:
Debian Release: wheezy/sid
APT prefers oldstable-proposed-updates
APT policy: (500, 'oldstable-proposed-updates'), (500, 'unstable'), (1,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.37-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.11.2-11 Embedded GNU C Library: Developmen
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii linux-libc-dev2.6.37-1 Linux support headers for userspac
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.4.5-2 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-29 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.5-12 The GNU C compiler
Versions of packages libc6-dev suggests:
ii glibc-doc 2.11.2-11 Embedded GNU C Library: Documentat
ii manpages-dev 3.27-1 Manual pages about using GNU/Linux
-- 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: http://lists.debian.org/20110223230700.21441.37372.reportbug@localhost
Re: Bug#575209 closed by Holger Levsen (Re: Bug#575209: general: Error resolving hostname [resent])
On Thu, 2010-03-25 at 11:21 +0100, Fabian Greffrath wrote: > reopen 575209 > reassign 575209 eglibc > found 575209 2.10.2-6 > found 575209 2.11-0exp6 > severity 575209 important > retitle 575209 Please resolv domain names with hyphens as border chars > tags 575209 + patch > thanks > > Hi Holger et al (please drop -devel out of the list of CCs if you feel > this is getting off-topic), > > sorry, but I find it unacceptable to close this bug referring to a > single paragraph in a (random) RFC [0]. However, there is a multitude > of other reasons why I think this bug *is* an issue: That 'random' RFC happens to be an Internet standard (STD 13) and still largely valid today. > - Sites with domain names like do already exist! > Do you think they should be accessible by any other proprietary > operating system, but not Debian? Not really! So if Windows accepts it then it must be OK? I don't think we have to follow that rule. Otherwise you should be demanding support for NMB and WINS in glibc. > - There is already an inconsistency among the different > implementations in Debian (or Linux as a whole), as e.g. ping and any > other program using gethostbyname() fail to resolv, whereas nslookup > and host succeed. This is what happens when you ignore Internet standards. > - The advice in the cited RFC is already ignored. Domain names that > start with a digit, e.g. 12345.foo.bar, can be resolved, whereas the > RFC tells us "They [labels] must start with a letter, end with a > letter or digit [...]". [...] It is not ignored; the standard was updated by RFC 1123 (STD 3). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#533077: linux-image-2.6.26-2-486: on an idle system /dev/random gets depleted very quick
On Mon, 2009-06-15 at 13:03 +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.
> >
> > It's "fixed" in that Drepper changed the kernel's ELF loader to
> > initialise the random bytes itself. The entropy pool is still depleted
> > by every process startup. :-(
>
> I noticed it during the development of my entropybroker package: I
> noticed that it was constantly refilling /dev/random on all of my linux
> boxes. Glad to know the bug is not in my program :-)
> Should I submit a bug report for glibc?
No, I reassigned this bug.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
Bug#533077: linux-image-2.6.26-2-486: on an idle system /dev/random gets depleted very quick
On Mon, 2009-06-15 at 11:44 +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.
It's "fixed" in that Drepper changed the kernel's ELF loader to
initialise the random bytes itself. The entropy pool is still depleted
by every process startup. :-(
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
reassign 533077 to libc6
reassign 533077 libc6 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#382175: Sun RPC libraries and other stories
On Tue, 2008-11-18 at 01:33 +, Simon Phipps wrote: > Try OpenGrok: http://src.opensolaris.org/source/ The documentation for portmap says that some code is derived from "the RPCSRC 4.0 and the TIRPC source distributions". The two source files labelled with Sun copyright are portmap.c and from_local.c. Many of the functions in portmap.c seem to correspond to rpcbind (usr/src/cmd/rpcbind) in OpenSolaris: portmap.c:find_service() - pmap_svc.c:find_service_pmap() portmap.c:reg_service() - pmap_svc.c:pmap_service() portmap.c:xdr_encap_parms() - rpcb_svc_com.c:xdr_encap_parms() portmap.c:xdr_rmtcall_args() - rpcb_svc_com.c:xdr_rmtcall_args() portmap.c:xdr_rmtcall_result() - rpcb_svc_com.c:xdr_rmtcall_result() portmap.c:xdr_opaque_parms() - rpcb_svc_com.c:xdr_opaque_parms() The key function in from_local.c seems to correspond to usr/src/ucblib/librpcsoc/get_myaddress.c: from_local.c:find_local() - get_myaddress.c:get_myaddress() Ben. signature.asc Description: This is a digitally signed message part
