Bug#823682: libc0.1-dev: can't link PIE executable on kfreebsd
close 823682 notfound 823682 glibc/2.22-6 thanks Steven Chamberlain wrote: > $ cc -fPIE -Wl,-pie -o foo foo.c > /usr/bin/ld: > /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: > relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making > a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: error > adding symbols: Bad value > collect2: error: ld returned 1 exit status > Is that the right file to link with, or should it rather use Scrt1.o or > something else? Sorry, my fault, I'd passed -pie as a linker option, but not to the compiler. This works - and it uses Scrt1.o instead: $ cc -fPIE -pie -o foo foo.c I'll file a new bug about the change needed in dpkg-dev. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#823682: libc0.1-dev: can't link PIE executable on kfreebsd
Package: libc0.1-dev Version: 2.22-6 Severity: normal User: debian-...@lists.debian.org Usertags: kfreebsd Hi, It seems that ever since Bug #430455, dpkg-buildflags thinks kfreebsd does not support Position-Independent Executable, so does not enable it even if specifically requested with DEB_BUILD_MAINT_OPTIONS=hardening=+pie Fixing dpkg-dev's /usr/share/perl5/Dpkg/Vendor/Debian.pm to permit use of PIC on kfreebsd, still doesn't enable it by default. Trying to compile+link anything as PIE, actually seems to fail at the moment: $ cc -fPIE -Wl,-pie -o foo foo.c /usr/bin/ld: /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status The C runtime has been compiled as relocatable code, not PIC: $ file /usr/lib/x86_64-kfreebsd-gnu/crt1.o /usr/lib/x86_64-kfreebsd-gnu/crt1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), for GNU/kFreeBSD 8.3.0, not stripped Is that the right file to link with, or should it rather use Scrt1.o or something else? Or does this mean PIC/PIE must be enabled somewhere in glibc first? It's not clear to me how that is done, or how/why this works at the moment on linux-amd64 but not kfreebsd-amd64. Thanks! p.s. the kernel of FreeBSD didn't implement ASLR yet, but when it does, we'd like to have as much as possible compiled as PIC/PIE already. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#822143: glibc: please update for kfreebsd 10.3
tags 822143 - moreinfo + patch thanks Steven Chamberlain wrote: > Steven Chamberlain wrote: > > Please could you update patches/kfreebsd/local-sysdeps.diff > > to SVN revision 6019, which adds some things that will be needed > > by kfreebsd 10.3 userland: > > Oops, maybe not yet. I need to fix the type names first. Fixed in glibc-ports and glibc-ports-2.23 SVN r6029. Please try to include this in a future glibc upload to experimental and/or sid. Thank you. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#822143: glibc: please update for kfreebsd 10.3
tags 822143 - patch + moreinfo thanks Steven Chamberlain wrote: > Please could you update patches/kfreebsd/local-sysdeps.diff > to SVN revision 6019, which adds some things that will be needed > by kfreebsd 10.3 userland: Oops, maybe not yet. I need to fix the type names first. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Bug#822143: glibc: please update for kfreebsd 10.3
Package: src:glibc Version: 2.22-7 Severity: wishlist Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd Hi Aurelien, Please could you update patches/kfreebsd/local-sysdeps.diff to SVN revision 6019, which adds some things that will be needed by kfreebsd 10.3 userland: Update sys/net/if.h for 10.3: * add struct ifi2creq * remove struct ifconf32 * append struct if_data with ifi_oqdrops (ABI-compatible change) Add 10.3 syscalls: procctl, ppoll, futimens, utimensat This could go into 2.23 in experimental and/or 2.22 as well. Thank you! -- System Information: Debian Release: 8.0 APT prefers stable-kfreebsd-proposed-updates APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500, 'stable-kfreebsd') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#817207: glibc: kfreebsd-i386: illegal instruction in ld.so
Aurelien Jarno wrote: > + * patches/kfreebsd/local-sysdeps.diff: update to revision 5932 (from > +glibc-bsd): > +- Fix consistency check for PIC code when built with GCC 5. Closes: > + #817207. Thanks Aurelien, that's brilliant! I just tested and it has fixed the problem I saw on kfreebsd-i386. So this turned out to be: * not due to a change in glibc, but the change to gcc-5; * specific to i386 CPU architecture; * already fixed for linux, just wasn't applied to kfreebsd sysdeps; * the failure was in check_consistency(); not directly related to executable stacks, but it was called inside a code block that tries to enables executable stacks, if some library requests it. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#817207: glibc: kfreebsd-i386: illegal instruction in ld.so
Steven Chamberlain wrote: > Upgrading libc0.1 breaks pretty much everything: Actually not everything. It broke the buildd though, because dpkg-deb stopped working. This was from dpkg-deb: > | Core was generated by `ld-2.22.so'. > | Program terminated with signal 4, Illegal instruction. > | (gdb) bt full > | #0 0x0100622b in ?? () > | No symbol table info available. > | #1 0x62696c2f in ?? () > | No symbol table info available. > | #2 0x3833692f in ?? () > | No symbol table info available. > | #3 0x666b2d36 in ?? () > | No symbol table info available. > | #4 0x01001a90 in ?? () > | No symbol table info available. > | #5 0x in ?? () > | No symbol table info available. It fails trying to map shared object liblzma.so.5: | 2494 ld.so.1 NAMI "/usr/bin/dpkg-deb" | ... | 2494 ld.so.1 NAMI "/lib/i386-kfreebsd-gnu/libz.so.1" | 2494 ld.so.1 NAMI "/lib/i386-kfreebsd-gnu/liblzma.so.5" | ... | 2494 ld.so.1 PSIG SIGILL SIG_DFL code=ILL_PRVOPC There is something special about liblzma.so.5: | STACK off0x vaddr 0x paddr 0x align 2**2 | filesz 0x memsz 0x flags rwx It requires a writable and executable stack! which is rather rare, and probably should be fixed in the affected libraries. The kfreebsd buildds have disallowed executable stacks since DebConf15 though. I'm not sure why glibc 2.22 causes any regression here; this code has not changed since 2.21, but maybe something related to DEFAULT_STACK_PERMS, PF_X or PT_GNU_STACK has changed recently. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#817207: glibc: kfreebsd-i386: illegal instruction in ld.so
Package: src:glibc Version: 2.22-1 Severity: important User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Hi, glibc/2.22 has a major problem on kfreebsd-i386. It built on the buildds, but the compiled ld-2.22.so is broken as seen on buildd finzi: https://buildd.debian.org/status/fetch.php?pkg=mksh=kfreebsd-i386=52c-1=1457437296 | dpkg: error processing archive /var/cache/apt/archives/libc-bin_2.22-1_kfreebsd-i386.deb (--unpack): | subprocess dpkg-deb --control was killed by signal (Illegal instruction) | Errors were encountered while processing: | /var/cache/apt/archives/libc-bin_2.22-1_kfreebsd-i386.deb Upgrading libc0.1 breaks pretty much everything: | Core was generated by `ld-2.22.so'. | Program terminated with signal 4, Illegal instruction. | (gdb) bt full | #0 0x0100622b in ?? () | No symbol table info available. | #1 0x62696c2f in ?? () | No symbol table info available. | #2 0x3833692f in ?? () | No symbol table info available. | #3 0x666b2d36 in ?? () | No symbol table info available. | #4 0x01001a90 in ?? () | No symbol table info available. | #5 0x in ?? () | No symbol table info available. That corresponds to the 'ud2' instruction in the disassembly below: | /* The stack is presently not executable, but this module | requires that it be executable. We must change the | protection of the variable which contains the flags used in | the mprotect calls. */ |#ifdef SHARED | if ((mode & (__RTLD_DLOPEN | __RTLD_AUDIT)) == __RTLD_DLOPEN) |51fc: 8b 45 14mov0x14(%ebp),%eax |51ff: 25 00 00 00 88 and$0x8800,%eax |5204: 3d 00 00 00 80 cmp$0x8000,%eax |5209: 0f 84 b9 01 00 00 je 53c8 <_dl_map_object_from_fd+0x1258> |} | __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC; | __mprotect ((void *) p, s, PROT_READ); |} | else |__stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC; |520f: 8b 85 70 ff ff ff mov-0x90(%ebp),%eax |5215: 83 88 1c ff ff ff 07orl$0x7,-0xe4(%eax) |521c: e8 af 2e 01 00 call 180d0 <__x86.get_pc_thunk.cx> |5221: 81 c1 df cd 01 00 add$0x1cddf,%ecx |5227: 29 d9 sub%ebx,%ecx |5229: 74 02 je 522d <_dl_map_object_from_fd+0x10bd> |522b: 0f 0b ud2 | |#ifdef check_consistency | check_consistency (); |#endif | | errval = (*GL(dl_make_stack_executable_hook)) (stack_endp); |522d: 8b 8d 70 ff ff ff mov-0x90(%ebp),%ecx kFreeBSD 10 disallows executable stacks by default. It can be allowed again by sysctl kern.elf32.nxstack=0, but it would be better if glibc didn't need this. I wonder why this issue wasn't seen on kfreebsd-amd64 since executable stacks are not allowed there either. Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-i386 (i386) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) signature.asc Description: Digital signature
Bug#814958: glibc: FTBFS[kfreebsd]: misc/bug18240 timed out
Steven Chamberlain wrote:
> Unfortunately gdb on kfreebsd doesn't handle threads very well, [...]
I changed the test runner to send a SIGABRT instead of SIGKILL; then
gdb returns a trace of the thread we are interested in:
| #0 memset () at ../sysdeps/x86_64/memset.S:93
| No locals.
| #1 0x00080089bbf0 in alloc_perturb (n=, p=) at malloc.c:1864
| No locals.
| #2 _int_malloc (av=av@entry=0x800b84b40 ,
bytes=bytes@entry=51539607552) at malloc.c:3796
| iters =
| nb =
| idx =
| bin =
| victim =
| size =
| victim_index =
| remainder =
| remainder_size =
| block =
| bit =
| map =
| fwd =
| bck =
| errstr = 0x0
| __func__ = "_int_malloc"
| #3 0x00080089e581 in __libc_calloc (n=,
elem_size=) at malloc.c:3213
| av = 0x800b84b40
| oldtop = 0x606250
| p =
| bytes = 51539607552
| sz = 51539607552
| csz =
| oldtopsize = 130480
| mem =
| clearsize =
| nclears =
| d =
| hook =
| __func__ = "__libc_calloc"
| #4 0x00080090006e in __GI_hcreate_r (nel=,
htab=0x800b873d0 ) at hsearch_r.c:99
| No locals.
| #5 0x00401187 in test_size (size=2147483645) at
../../misc/bug18240.c:29
The problem is the large memory allocation by hcreate(INT_MAX-2), when
M_PERTURB option is also set (by test-skeleton.c). It takes some time
allocating and zeroing that memory, until the 2-second timeout is
reached, or memory exhausted.
A more condensed testcase is:
#include
#include
int main() {
mallopt (M_PERTURB, 42);
int res = hcreate(2147483645);
return 0;
}
$ LD_LIBRARY_PATH=. /usr/bin/time ./testcase
Command terminated by signal 9
0.70user 2.75system 0:04.11elapsed 84%CPU (17avgtext+589avgdata
5981064maxresident)k
0inputs+0outputs (0major+1492254minor)pagefaults 0swaps
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Bug#814958: glibc: FTBFS[kfreebsd]: misc/bug18240 timed out
Package: glibc Version: 2.21-8 Severity: important User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org | misc/bug18240 | +-+ | TEST misc/bug18240: | Timed out: killed the child process https://buildd.debian.org/status/fetch.php?pkg=glibc=kfreebsd-amd64=2.21-8=1455647345 Christoph Egger wrote: > Also I noticed the unstable upload to fix this (-8) fails due to > testsuite regressions .. it seems the package got some unrelated[0] > updates between -7 and -8 so not completely sure what caused this yet. > [0] > https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=6a0c9c0a8e4c94e7028cf908482e0224664db510 That commit added a new test misc/bug18240 which fails reliably for me on kfreebsd-amd64. With glibc -7, the testcase crashes with SIGSEGV, which is the bug that is now fixed. With -8 however, the testcase 'times out' after 2 seconds not really doing anything. Compiling misc/bug18240.c as a single-threaded executable, it takes <0.01 seconds to succesfully run and return 0. When misc/bug18240 is compiled with test-skeleton.c, the code under test runs in a separate thread (ID 101060 below), which just hangs until the test runner (thread ID 102564) kills it. Unfortunately gdb on kfreebsd doesn't handle threads very well, but here's a ktrace at least: | 7705 102564 bug18240 0.000842 CALL fork | 7705 102564 bug18240 0.000892 RET fork 7706/0x1e1a | 7706 101060 bug18240 0.000918 RET fork 0 | 7705 102564 bug18240 0.000924 CALL sigaction(SIGALRM,0x7fffe410,0x7fffe430) | 7706 101060 bug18240 0.000931 CALL getpid | 7705 102564 bug18240 0.000931 RET sigaction 0 | 7706 101060 bug18240 0.000961 RET getpid 7706/0x1e1a | 7705 102564 bug18240 0.000971 CALL setitimer(0,0x7fffe430,0x7fffe410) | 7706 101060 bug18240 0.000973 CALL thr_self(0x800624d90) | 7705 102564 bug18240 0.000980 RET setitimer 0 | 7706 101060 bug18240 0.000988 RET thr_self 0 | 7705 102564 bug18240 0.000991 CALL sigaction(SIGINT,0x7fffe410,0x7fffe430) | 7705 102564 bug18240 0.001007 RET sigaction 0 | 7705 102564 bug18240 0.001013 CALL wait4(0x1e1a,0x7fffe470,0,0) | 7706 101060 bug18240 0.001022 CALL setrlimit(RLIMIT_CORE,0x7fffe460) | 7706 101060 bug18240 0.001030 RET setrlimit 0 | 7706 101060 bug18240 0.001036 CALL getrlimit(RLIMIT_DATA,0x7fffe470) | 7706 101060 bug18240 0.001041 RET getrlimit 0 | 7706 101060 bug18240 0.001056 CALL setrlimit(RLIMIT_DATA,0x7fffe470) | 7706 101060 bug18240 0.001062 RET setrlimit 0 | 7706 101060 bug18240 0.001068 CALL setpgid(0,0) | 7706 101060 bug18240 0.001074 RET setpgid 0 | 7706 101060 bug18240 0.001085 CALL break(0x625210) | 7706 101060 bug18240 0.001092 RET break 0 | 7706 101060 bug18240 0.001101 CALL break(0x626000) | 7706 101060 bug18240 0.001109 RET break 0 | 7706 101060 bug18240 0.001255 CALL mmap(0,0xc1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON,0x,0) | 7706 101060 bug18240 0.001263 RET mmap 34371833856/0x800b89000 | 7705 102564 bug18240 2.004328 RET wait4 RESTART | 7705 102564 bug18240 2.004358 PSIG SIGALRM caught handler=0x4012a0 mask=0x0 code=SI_KERNEL | 7705 102564 bug18240 2.004390 CALL kill(0xe1e6,SIGKILL) Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: glibc 2.21-5 ftbfs
Hi,
Aurelien Jarno wrote:
> On 2015-12-23 17:30, Samuel Thibault wrote:
> > So it looks like there are no /usr/include/sys files any more in the
> > kernel headers? If so we can just drop the statement. If you want to
>
> It seems it has been changed in the last kfreebsd-kernel-headers upload.
Sorry, my fault for not noticing this. In kfreebsd-amd64 builds,
/usr/include/sys still exists because of gcc-multilib.
> That said, I don't think we can just drop this entry as this would
> likely breaks the cross-compilation case.
I think so, yes.
> > keep backward compatibility, we can also make the statement failure
> > non-fatal.
>
> Likely either that, or a check if the directory exists before running
> the command.
A patch for this is attached.
Thank you,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/debian/sysdeps/kfreebsd.mk 2015-09-09 15:01:41.0 +
+++ b/debian/sysdeps/kfreebsd.mk 2015-12-25 01:59:01.355433000 +
@@ -43,12 +43,16 @@
mkdir -p debian/include/sys
# Link to any headers found in the old locations first
- find $(KFREEBSD_HEADERS)/sys -mindepth 1 \
- -exec ln -sf '{}' debian/include/sys ';'
+ if test -d $(KFREEBSD_HEADERS)/sys ; then \
+ find $(KFREEBSD_HEADERS)/sys -mindepth 1 \
+ -exec ln -sf '{}' debian/include/sys ';' ; \
+ fi
# Link to any headers found at the new multiarch location,
# replacing any existing links
- find $(KFREEBSD_ARCH_HEADERS)/sys -mindepth 1 \
- -exec ln -sf '{}' debian/include/sys ';'
+ if test -d $(KFREEBSD_ARCH_HEADERS)/sys ; then \
+ find $(KFREEBSD_ARCH_HEADERS)/sys -mindepth 1 \
+ -exec ln -sf '{}' debian/include/sys ';' ; \
+ fi
# To make configure happy if libc0.1-dev is not installed.
touch debian/include/assert.h
signature.asc
Description: Digital signature
Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path
Control: reassign -1 src:glibc 2.19-19 Control: forcemerge -1 672774 I just noticed the earlier, duplicate bug. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#798955: Moving glibc headers from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH)
Hi! I applied the patch against 2.19 to test on kfreebsd (since 2.21 is not building on it yet). It seems one kfreebsd-specific file was missed in the patch, vm86.h, which breaks the build, so please add the attached hunk also. I'm trying some test-rebuilds on kfreebsd-amd64 with this patch applied to glibc, and also with kfreebsd-kernel-headers/10.1~7 from experimental (where kernel headers have moved to multiarch paths too). It's going rather well so far: 146 packages built fine; and only 2 FTBFS, insserv (which seemed unrelated to this), and this in python2.6 (due to a hard-coded path to headers) : | cd ../Lib/plat-x86_64-kfreebsd-gnu; ./regen | eval $PYTHON_FOR_BUILD ../../Tools/scripts/h2py.py -i "'(u_long)'" /usr/include/netinet/in.h | Traceback (most recent call last): | File "../../Tools/scripts/h2py.py", line 181, in | main() | File "../../Tools/scripts/h2py.py", line 81, in main | fp = open(filename, 'r') | IOError: [Errno 2] No such file or directory: '/usr/include/netinet/in.h' | make[1]: *** [../Lib/plat-x86_64-kfreebsd-gnu] Error 1 | Makefile:1119: recipe for target '../Lib/plat-x86_64-kfreebsd-gnu' failed | make[1]: Leaving directory '/«PKGBUILDDIR»/build-static' | make: *** [stamps/stamp-install] Error 2 I expect a full rebuild will uncover dozens more cases like this, and we may need to start filing (wishlist?) bugs. Regards, -- Steven Chamberlain ste...@pyro.eu.org --- debian/sysdeps/kfreebsd-amd64.mk.orig 2015-09-15 14:12:10.72604 +0100 +++ debian/sysdeps/kfreebsd-amd64.mk 2015-09-16 20:52:20.178441378 +0100 @@ -31,7 +31,7 @@ ln -s ../x86_64-kfreebsd-gnu/sys/$$i debian/libc0.1-dev-i386/usr/include/sys/$$i ; \ done -cp -a debian/tmp-i386/usr/include/sys/vm86.h \ +cp -a debian/tmp-i386/usr/include/x86_64-kfreebsd-gnu/sys/vm86.h \ debian/libc0.1-dev-i386/usr/include/sys endef signature.asc Description: Digital signature
Bug#785796: glibc: kfreebsd should define F_DUPFD_CLOEXEC
tags 785796 + patch thanks Hi, Now that all the kfreebsd buildds are upgraded to kfreebsd-10, it is desirable to define F_DUPFD_CLOEXEC in glibc. I assume we don't need to be able to build current glibc on an oldstable kernel any more. The patch for this is inline here: https://bugs.debian.org/785796#65 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#764692: glibc removed __FAVOR_BSD from features.h
block 765468 by 764692 tags 764692 + patch thanks Hi, To recap, glibc-2.19 no longer implements __FAVOR_BSD. Users of netinet/tcp.h may have defined that to request a BSD version of the tcphdr struct. To fix this, we simply need to merge a change from gnu/netinet/tcp.h into our unix/bsd/bsd4.4/kfreebsd/netinet/tcp.h : * sysdeps/gnu/netinet/tcp.h (struct tcphdr): Use anonymous unions instead of making contents conditional on [__FAVOR_BSD]. I've committed this to glibc-ports SVN as r5772. Please update it in the glibc package sometime. It fixes some outstanding FTBFS (regression from older glibc, where FAVOR_BSD was supported before): * ndisc6 (#778418) * dns-flood-detector (#765468) * tcpstat * rtpproxy And this change allows some new packages to build on kfreebsd: * pchar * pads * ssldump * fprobe Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path
Sorry, that was wrong. Required headers could be located in
/usr/include/sys and /usr/include/$(DEB_HOST_MULTIARCH)/sys at the same
time. It is necessary to split debian/include/sys/ and link to
individual headers (or subdirectories) wherever they are located.
I think I have a patch now that meets all the requirements.
Firstly it will look for headers at the new multiarch location,
/usr/include/$(DEB_HOST_MULTIARCH). Those could be native headers, or
foreign-architecture headers if you've installed those for
cross-building.
But otherwise it will fall back to using headers from the original
locations: /usr/include for native builds;
/usr/$(DEB_HOST_GNU_TYPE)/include for old-style cross builds.
I've tested this with successful native kfreebsd-amd64 builds (including
multilib), having kernel headers in either the original or the new
(multiarch) locations.
Thank you,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- glibc-2.19/debian/sysdeps/kfreebsd.mk 2015-07-09 13:28:06.0 +0100
+++ glibc-2.19/debian/sysdeps/kfreebsd.mk 2015-09-05 20:23:27.708048223 +0100
@@ -16,6 +16,7 @@
else
KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
endif
+ KFREEBSD_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
KFREEBSD_HEADERS := $(KFREEBSD_SOURCE)/sys
endif
@@ -27,17 +28,25 @@
$(stamp)mkincludedir:
rm -rf debian/include
mkdir debian/include
- for file in bsm net netatalk netipx nfs osreldate.h sys x86 vm ; do \
- if test -e $(KFREEBSD_HEADERS)/$$file ; then \
+
+ # Link to any headers found at the new multiarch location,
+ # otherwise look for them in the old locations
+ for file in bsm machine machine-amd64 machine-i386 net netatalk netipx nfs osreldate.h x86 vm ; do \
+ if test -e $(KFREEBSD_ARCH_HEADERS)/$$file ; then \
+ ln -s $(KFREEBSD_ARCH_HEADERS)/$$file debian/include ; \
+ elif test -e $(KFREEBSD_HEADERS)/$$file ; then \
ln -s $(KFREEBSD_HEADERS)/$$file debian/include ; \
fi ; \
done
-# Link all machine directories. We can't just link machine
-# because of explicit references to and
- # .
- find $(KFREEBSD_HEADERS) -maxdepth 1 -xtype d -name machine\* \
- -exec ln -s '{}' debian/include ';'
+ mkdir -p debian/include/sys
+ # Link to any headers found in the old locations first
+ find $(KFREEBSD_HEADERS)/sys -mindepth 1 \
+ -exec ln -sf '{}' debian/include/sys ';'
+ # Link to any headers found at the new multiarch location,
+ # replacing any existing links
+ find $(KFREEBSD_ARCH_HEADERS)/sys -mindepth 1 \
+ -exec ln -sf '{}' debian/include/sys ';'
# To make configure happy if libc0.1-dev is not installed.
touch debian/include/assert.h
signature.asc
Description: Digital signature
Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path
Hi!
Helmut Grohne wrote:
> So maybe we could find a way that works for both the "dpkg-cross" way
> (at least in theory) and the multiarch way.
>
> For linux this is not sorted out either yet. The relevant code here is
> in debian/sysdeps/linux.mk:
> | ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
> | LINUX_HEADERS := /usr/include
> | else
> | LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
> | endif
> | LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
Actually... that looks like it should already work. The files in
LINUX_ARCH_HEADERS are used in preference to LINUX_HEADERS, if they
are available.
We can just do the same in kfreebsd.mk, using multiarch headers if
they're found, or the old locations as a fallback.
It also means glibc can apply this patch before kfreebsd-kernel-headers
has made the change; no need to bump the Build-Depends version now.
> Using target variables is wrong here. It might work (because target
> defaults to host), but it doesn't make sense semantically. This must be
> DEB_HOST_MULTIARCH here. Target variables are only relevant for
> compilers, but glibc isn't a compiler.
I've corrected this too in the new version of the patch, attached.
Thanks again for your help!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/sysdeps/kfreebsd.mk.orig 2015-07-09 12:28:06.0 +
+++ debian/sysdeps/kfreebsd.mk 2015-09-05 16:29:00.655101849 +
@@ -16,6 +16,7 @@
else
KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
endif
+ KFREEBSD_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
KFREEBSD_HEADERS := $(KFREEBSD_SOURCE)/sys
endif
@@ -27,18 +28,14 @@
$(stamp)mkincludedir:
rm -rf debian/include
mkdir debian/include
- for file in bsm net netatalk netipx nfs osreldate.h sys x86 vm ; do \
- if test -e $(KFREEBSD_HEADERS)/$$file ; then \
+ for file in bsm machine machine-i386 net netatalk netipx nfs osreldate.h sys x86 vm ; do \
+ if test -e $(KFREEBSD_ARCH_HEADERS)/$$file ; then \
+ ln -s $(KFREEBSD_ARCH_HEADERS)/$$file debian/include ; \
+ elif test -e $(KFREEBSD_HEADERS)/$$file ; then \
ln -s $(KFREEBSD_HEADERS)/$$file debian/include ; \
fi ; \
done
-# Link all machine directories. We can't just link machine
-# because of explicit references to and
- # .
- find $(KFREEBSD_HEADERS) -maxdepth 1 -xtype d -name machine\* \
- -exec ln -s '{}' debian/include ';'
-
# To make configure happy if libc0.1-dev is not installed.
touch debian/include/assert.h
signature.asc
Description: Digital signature
Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path
Steven Chamberlain wrote:
> We can just do the same in kfreebsd.mk, using multiarch headers if
> they're found, or the old locations as a fallback.
Turns out this was not backward-compatible, because other packages
(libc0.1-dev) may create /usr/include/$(DEB_HOST_ARCH)/sys, having
some but not all the required headers.
Doing the opposite works though - look for /usr/include/sys (or the
dpkg-cross location); if it's not there, try looking at the new
multiarch location instead. This is the same ordering used by gcc's
default include paths already.
Revised patch attached.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/sysdeps/kfreebsd.mk.orig 2015-07-09 12:28:06.0 +
+++ debian/sysdeps/kfreebsd.mk 2015-09-05 16:29:00.655101849 +
@@ -16,6 +16,7 @@
else
KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
endif
+ KFREEBSD_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH)
else
KFREEBSD_HEADERS := $(KFREEBSD_SOURCE)/sys
endif
@@ -27,18 +28,14 @@
$(stamp)mkincludedir:
rm -rf debian/include
mkdir debian/include
- for file in bsm net netatalk netipx nfs osreldate.h sys x86 vm ; do \
- if test -e $(KFREEBSD_HEADERS)/$$file ; then \
+ for file in bsm machine machine-i386 net netatalk netipx nfs osreldate.h sys x86 vm ; do \
+ if test -e $(KFREEBSD_HEADERS)/$$file ; then \
+ ln -s $(KFREEBSD_HEADERS)/$$file debian/include ; \
+ elif test -e $(KFREEBSD_ARCH_HEADERS)/$$file ; then \
ln -s $(KFREEBSD_ARCH_HEADERS)/$$file debian/include ; \
fi ; \
done
-# Link all machine directories. We can't just link machine
-# because of explicit references to and
- # .
- find $(KFREEBSD_HEADERS) -maxdepth 1 -xtype d -name machine\* \
- -exec ln -s '{}' debian/include ';'
-
# To make configure happy if libc0.1-dev is not installed.
touch debian/include/assert.h
signature.asc
Description: Digital signature
Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path
Package: glibc Version: 2.19-19 Severity: wishlist Tags: patch Hi, We're hoping to move kfreebsd-kernel-headers' files to multiarch path /usr/include/$(DEB_TARGET_MULTIARCH), so that headers of other kernels are co-installable on a build machine (for cross-building and bootstrapping). gcc-5 is already fine with this. And since gcc's default include search path has /usr/include/$(DEB_TARGET_MULTIARCH), it is expected to not cause many problems; except where -nostdinc is used. Please could glibc be patched as attached, to always look in that directory for system includes, even for native builds (HOST==BUILD). We hope to make this change with kfreebsd-kernel-headers (>= 10.1~7~), unless there are objections, or if my upcoming mass rebuild reveal any other breakage in reverse-depends. Thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- glibc-2.19/debian/sysdeps/kfreebsd.mk.orig 2015-07-09 12:28:06.0 + +++ glibc-2.19/debian/sysdeps/kfreebsd.mk 2015-09-04 16:04:43.104028000 + @@ -11,11 +11,7 @@ libc_extra_config_options = $(extra_config_options) ifndef KFREEBSD_SOURCE - ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) -KFREEBSD_HEADERS := /usr/include - else -KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include - endif + KFREEBSD_HEADERS := /usr/include/$(DEB_TARGET_MULTIARCH) else KFREEBSD_HEADERS := $(KFREEBSD_SOURCE)/sys endif
Bug#785796: kernel on buildd (Re: [Glibc-bsd-commits] r5714 - trunk/glibc-ports/kfreebsd/bits)
tags 785796 - patch thanks Hi, Petr Salinger wrote: what is currently used kernel on buildd for kfreebsd-* ? According to last log of util-linux (22 May 2015/fayrfax.debian.org): Kernel: GNU/kFreeBSD 9.0-2-amd64 kfreebsd-amd64 (x86_64) Damn, I thought all the builds were upgraded to 10.1. Thanks for pointing this out. Therefore please don't apply this patch to glibc yet... we'll need a plan B. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20150528161332.gc62...@pyro.eu.org
Re: [Glibc-bsd-commits] r5714 - trunk/glibc-ports/kfreebsd/bits
Dear Glibc Maintainers, Please try to upload the http://bugs.debian.org/785796 bugfix to sid as soon as possible, and it would really help us out. Thanks. Christoph Egger wrote: I understand the thing below is the intended fix for util-linux? Is there some planned timeline to get it into unstable? We're not building anything currently for as long as util-linux isn't updated so one might want to push a little Yes, this is intended to fix the current util-linux FTBFS. Something crazy is going on with that, but adding this patch to glibc would be a way to resolve the current issue on kfreebsd. I think util-linux might still need binNMUs by a porter to get our buildds working again. (So in theory one could apply this glibc patch locally, to binNMU util-linux, but I think that'd be against the rules if the change isn't in sid). stevenc-gu...@alioth.debian.org writes: Author: stevenc-guest Date: 2015-05-24 14:00:19 + (Sun, 24 May 2015) New Revision: 5714 Modified: trunk/glibc-ports/kfreebsd/bits/fcntl.h Log: provide F_DUPFD_CLOEXEC of POSIX.1-2008, implemented in kfreebsd-10 Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#785796: glibc: kfreebsd should define F_DUPFD_CLOEXEC
retitle 785796 glibc: kfreebsd should define F_DUPFD_CLOEXEC reassign 785796 src:glibc found 785796 glibc/2.19-18 affects 785796 src:util-linux tags 785796 + patch thanks Hi, util-linux FTBFS on kfreebsd as it assumes fcntl supports F_DUPFD_CLOEXEC (of POSIX.1-2008): Andreas Henriksson wrote: 11:02 ah kzak: fwiw, commit d1f9c0969e apparently broke kfreebsd where F_DUPFD_CLOEXEC is not defined [...] This has only been implemented since kfreebsd-10 so we didn't define it yet in bits/fcntl.h, but we should add this now. I've committed this to glibc-ports: --- kfreebsd/bits/fcntl.h (revision 5713) +++ kfreebsd/bits/fcntl.h (working copy) @@ -148,6 +148,10 @@ #define F_SETLK64 12 /* Set record locking info (non-blocking). */ #define F_SETLKW64 13 /* Set record locking info (blocking). */ +#if __USE_BSD || __POSIX_VISIBLE = 200809 +#defineF_DUPFD_CLOEXEC 17 /* Like F_DUPFD, but FD_CLOEXEC is set */ +#endif + #if defined __USE_BSD || defined __USE_UNIX98 # define F_GETOWN 5 /* Get owner of socket (receiver of SIGIO). */ # define F_SETOWN 6 /* Set owner of socket (receiver of SIGIO). */ Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150524141422.ga84...@pyro.eu.org -- 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/20150524141422.ga84...@pyro.eu.org
Bug#764692: Bug#778418: ndisc6: fails to build on kfreebsd
Control: block -1 by 764692 Hi, Michael Gilbert wrote: This package no longer builds on the freebsd architectures: https://buildd.debian.org/ndisc6 This is another effect of #764692; we should be able to fix it in glibc post-jessie release, by updating the glibc-bsd copy of tcp.h (and others) with union of Linux and BSD-like struct tcphdr members. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20150214191930.gb4...@squeeze.pyro.eu.org
Bug#757941: Bug#769190: Bug#757941: Bug#769190: busybox-static: DNS resolver is broken again with the last upload
Hi, Michael Tokarev wrote: Since this is all alternatives, is it really necessary to list the [arch] names? I mean, just list of pkgs with versions should be enough I think, each arch will pick the right name, no? I could be wrong, but I think within sbuild only the first of the alternatives is considered. I'm not sure whether it skips over the missing ones on that arch, or would fail with BD-Uninstallable. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141112211037.gd19...@squeeze.pyro.eu.org
Re: Bug#740509: ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address
found 740509 glibc/2.19-11 tags 740509 + patch thanks Hi, I'm sorry, I made a mistake testing this on kfreebsd-i386; I'd modified a header in the build tree and forgotten about it. As a result, the workaround was not effective on kfreebsd-i386 10.1. Some additional code is committed now to svn/glibc-bsd/trunk/glibc-ports as r5668. Please could you pull in that change in the next glibc upload. I've re-tested it on kfreebsd-i386, kfreebsd-amd64, for kernels 9.0 and 10.1. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141025185327.gb16...@squeeze.pyro.eu.org
Re: Bug#740509: ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address
Hi!
The attached patch is my best guess at how to fix this bug. I'm still
testing it myself, but I'm sharing it now in case anyone else is able to
build glibc on kfreebsd-i386 and also help test. (It can take many
hours to build glibc).
getifaddrs() uses a NET_RT_IFLIST sysctl to get back a struct rt_msghdr
followed by a struct sockaddr_dl. From kfreebsd 9.0 - 10.1, the
rt_msghdr seems to be 4 bytes larger on kfreebsd-i386 only (not on
kfreebsd-amd64, probably because there was some padding for alignment).
With the current build of glibc (based on outdated
kfreebsd-kernel-headers), ifconfig fails to get a list of interface
names on 10.1 kernels, but can still do that within a chroot on 9.0.
If glibc is rebuilt against latest kfreebsd-kernel-headers ( 10.1~), I
think it works on 10.1 kernels, but stops working on kfreebsd-i386 9.0.
The buildds run kfreebsd 9.0, so I expect it would FTBFS when that
happens. The attached patch uses rt_msghdr-ifm_msglen to guess the
running kernel version and accordingly, find the right place for the
struct sockaddr_dl. I expect it will still work for the i386-on-amd64
compat case also.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From: Steven Chamberlain ste...@pyro.eu.org
Subject: getifaddrs: work around a kfreebsd 9.0 to 10.1 ABI break
--- a/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/ifaddrs.c 2014-10-21 01:19:18.0 +
+++ b/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/ifaddrs.c 2014-10-21 01:27:59.072736100 +
@@ -147,7 +147,13 @@
if (ifm-ifm_addrs RTA_IFP) {
idx = ifm-ifm_index;
++icnt;
+/* XXX: smooth over a kfreebsd 9.0-10.1 ABI break:
+ sizeof(struct rt_msghdr) is correct for 10.1 kernel */
dl = (struct sockaddr_dl *)(void *)(ifm + 1);
+if (rtm-rtm_msglen == 152) {
+ /* on kfreebsd-i386 9.0, struct rt_msghdr is 96 bytes */
+ dl = (struct sockaddr_dl *)((char *)ifm + 96);
+}
dcnt += SA_RLEN((struct sockaddr *)(void*)dl) +
ALIGNBYTES;
#ifdef HAVE_IFM_DATA
@@ -234,7 +240,13 @@
ifm = (struct if_msghdr *)(void *)rtm;
if (ifm-ifm_addrs RTA_IFP) {
idx = ifm-ifm_index;
+/* XXX: smooth over a kfreebsd 9.0-10.1 ABI break:
+ sizeof(struct rt_msghdr) is correct for 10.1 kernel */
dl = (struct sockaddr_dl *)(void *)(ifm + 1);
+if (rtm-rtm_msglen == 152) {
+ /* on kfreebsd-i386 9.0, struct rt_msghdr is 96 bytes */
+ dl = (struct sockaddr_dl *)((char *)ifm + 96);
+}
cif = ift;
ift-ifa_name = names;
signature.asc
Description: OpenPGP digital signature
Re: Bug#764692: usbmuxd: FTBFS on kfreebsd-*
tags 764692 + patch thanks Hi, [adding -glibc@ and -bsd@ to Cc:] On 10/10/14 10:47, Jonathan Wiltshire wrote: CC usbmuxd-device.o device.c: In function 'send_anon_rst': device.c:264:4: error: 'struct tcphdr' has no member named 'th_sport' th.th_sport = htons(sport); glibc-provided features.h no longer defines a __FAVOR_BSD macro, so the BSD version of struct tcphdr in netinet/tcp.h cannot be used, even if _BSD_SOURCE was requested as it was in this case: src/device.c: 22 #define _BSD_SOURCE [...] 28 #include sys/time.h 29 #include netinet/in.h 30 #include netinet/tcp.h It works to define __FAVOR_BSD here (patch attached), but I wonder if that should be fixed in glibc headers somehow? There are already many users of netinet/tcp.h that define __FAVOR_BSD however: http://codesearch.debian.net/search?q=define+__FAVOR_BSD Regards, -- Steven Chamberlain ste...@pyro.eu.org --- a/src/device.c +++ b/src/device.c @@ -20,6 +20,7 @@ */ #define _BSD_SOURCE +#define __FAVOR_BSD #ifdef HAVE_CONFIG_H #include config.h
Re: Bug#764692: glibc removed __FAVOR_BSD from features.h (was: usbmuxd: FTBFS on kfreebsd-*)
clone 764692 -1 reassign 764692 libc0.1-dev found 764692 glibc/2.19-11 retitle 764692 glibc: removed __FAVOR_BSD from features.h thanks Hi, On 12/10/14 16:45, Steven Chamberlain wrote: glibc-provided features.h no longer defines a __FAVOR_BSD macro, so the BSD version of struct tcphdr in netinet/tcp.h cannot be used, [...] Seems we've had another occurrence of this with dns-flood-detector; I'm worried there could still be more packages affected by the change: https://buildd.debian.org/status/fetch.php?pkg=dns-flood-detectorarch=kfreebsd-amd64ver=1.20-2stamp=1413149812 Was this macro removed for a good reason or could we add it back in? /usr/include/features.h: | /* If _BSD_SOURCE was defined by the user, favor BSD over POSIX. */ | #if defined _BSD_SOURCE \ | !(defined _POSIX_SOURCE || defined _POSIX_C_SOURCE || \ | defined _XOPEN_SOURCE || defined _GNU_SOURCE || defined _SVID_SOURCE) | # define __FAVOR_BSD1 | #endif Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/543aff9d.4080...@pyro.eu.org
Bug#764692: glibc removed __FAVOR_BSD from features.h
Hi Guillem, Would a BSD-style netinet/tcp.h be a good candidate to ship in libbsd-dev? On 12/10/14 16:45, Steven Chamberlain wrote: glibc-provided features.h no longer defines a __FAVOR_BSD macro, so the BSD version of struct tcphdr in netinet/tcp.h cannot be used, [...] glibc upstream has deliberately removed the BSD-style tcphdr definition which was available until now using _BSD_SOURCE. That broke packages usbmuxd, dns-flood-detector that I know of so far. Since glibc 2.19, _BSD_SOURCE no longer causes BSD definitions to be preferred in case of conflicts. Since glibc 2.20, this macro is deprecated. Patching affected software to use libbsd seems like a good idea to me? Another sad thing I saw is that dozens of packages decided to embed a BSD-style tcphdr definition in their code, because it wasn't readily available: http://codesearch.debian.net/search?q=th_dport The BSD form of this struct dates back at least 20 years, is still defined like this the BSDs, Mac OS X, possibly AIX, Solaris and its derivatives. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/543b10b6.9020...@pyro.eu.org
Bug#764692: glibc removed __FAVOR_BSD from features.h
On 13/10/14 00:37, Steven Chamberlain wrote: Would a BSD-style netinet/tcp.h be a good candidate to ship in libbsd-dev? ...and also netinet/udp.h, due to udphdr. More packages (unported yet) that could benefit from BSD struct tcphdr/udphdr definitions are: * ntop * pchar * scamper * rtpproxy * openvas-libnasl * pads * ssldump * ncap * fprobe Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/543b1391.7060...@pyro.eu.org
Bug#762404: glibc: FTBFS[kfreebsd] tst-execstack fails; expected behaviour
tags 762404 + patch thanks Hi, Encountered regressions that don't match expected failures (debian/testsuite-checking/expected-results-x86_64-kfreebsd-gnu-libc): tst-execstack-needed.out, Error 1 tst-execstack.out, Error 1 tst-execstack-prog.out, Error 1 I decided to simply add those to the list of expected failures, since: Similar to SElinux enforcement of allow_execstack=0 - something the test program checks for and knows how to handle [...] I suggest the test could be fixed for any version of kfreebsd by checking the appropriate sysctl. In short, I tried to implement this, but kfreebsd's stack protector seems to trigger a SIGSEGV in the process rather than whatever SElinux does. It also wouldn't fix the tst-execstack-needed and -prog tests. Patch attached! Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org --- debian/testsuite-checking/expected-results-i586-kfreebsd-gnu-libc.orig 2014-09-12 21:50:56.0 + +++ debian/testsuite-checking/expected-results-i586-kfreebsd-gnu-libc 2014-09-27 00:54:07.869807173 + @@ -20,6 +20,11 @@ tst-timer4.out, Error 1 tst-timer5.out, Error 1 tst-waitid.out, Error 1 +# will expectedly SIGSEGV on kfreebsd 10.0 and later, due to having +# nxstack=1 by default (bug #762404) +tst-execstack-needed.out, Error 1 +tst-execstack.out, Error 1 +tst-execstack-prog.out, Error 1 # # needs newer kernel - see #716746 # --- debian/testsuite-checking/expected-results-x86_64-kfreebsd-gnu-libc.orig 2014-09-12 21:50:56.0 + +++ debian/testsuite-checking/expected-results-x86_64-kfreebsd-gnu-libc 2014-09-27 00:40:54.945854744 + @@ -22,6 +22,13 @@ tst-waitid.out, Error 1 tst-writev.out, Error 1 # +# will expectedly SIGSEGV on kfreebsd 10.0 and later, due to having +# nxstack=1 by default (bug #762404) +# +tst-execstack-needed.out, Error 1 +tst-execstack.out, Error 1 +tst-execstack-prog.out, Error 1 +# # needs newer kernel - see #716746 # tst-cpuclock1.out, Error 1
Re: Bug#740509: ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address
reassign 740509 libc0.1 found 740509 glibc/2.19-11 tags 740509 + jessie sid affects 740509 freebsd-net-tools user debian-...@lists.debian.org usertags 740509 + kfreebsd thanks On 13:10, Robert Millan wrote: $ sudo ifconfig -a : flags=8802BROADCAST,SIMPLEX,MULTICAST ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address : flags=0 ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address : flags=0 ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address : flags=8008LOOPBACK,MULTICAST ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address I think this could be related to a workaround in glibc local-sysdeps.diff for kfreebsd: + /* FIXME: 'struct if_msghdr' contains a 'struct if_data' which in turns +contains 'unsigned long' values. Their size therefore depends on +the running kernel (32 or 64 bits). This should be fixed in the +compat layer of the kernel. Meanwhile just workaround the bug here/ */ +#if 0 + sdl = (struct sockaddr_dl *) (msg + 1); +#else + sdl = (struct sockaddr_dl *) (p + msg-ifm_msglen - sizeof(struct sockaddr_dl) - 2); +#endif whereas if_data was removed from the struct in the following commit, to fix the ABI break; that means the workaround should no longer be used? http://svnweb.freebsd.org/base/head/sys/net/if.h?r1=231504r2=231503pathrev=231504 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140921182947.ge31...@squeeze.pyro.eu.org
Bug#762404: glibc: FTBFS[kfreebsd] tst-execstack fails; expected behaviour
Package: glibc Version: 2.19.11 Severity: serious User: debian-...@lists.debian.org Usertags: kfreebsd Hi, During a test rebuild for kfreebsd 10.1 transition, I noticed that glibc fails to build from source already on kfreebsd 10.0: Encountered regressions that don't match expected failures (debian/testsuite-checking/expected-results-x86_64-kfreebsd-gnu-libc): tst-execstack-needed.out, Error 1 tst-execstack.out, Error 1 tst-execstack-prog.out, Error 1 TEST tst-execstack-needed.out: DSO called ok (local 0x7fffd2b0, trampoline 0x7fffd2b1) TEST tst-execstack.out: executable stacks allowed DSO called ok (local 0x7fffd290, trampoline 0x7fffd291) executable stacks allowed threads waiting DSO called ok (local 0x7fffd200, trampoline 0x7fffd201) Stack address remains the same: 0x7fffe000 TEST tst-execstack-prog.out: DSO called ok (local 0x7fffd2c0, trampoline 0x7fffd2c1) That shows kfreebsd-amd64; it fails similarly on kfreebsd-i386. This is actually by design. The test program is killed due to a new default setting of: kern.elf64.nxstack: 1 kern.elf32.nxstack: 1 Similar to SElinux enforcement of allow_execstack=0 - something the test program checks for and knows how to handle. So I suggest the test could be fixed for any version of kfreebsd by checking the appropriate sysctl. The Debian buildds run a 9.0 kernel with nxstack=0 so are not affected *yet*, but the package will start to FTBFS as soon as they are updated to a jessie kernel, which would of course be a problem for future s-p-u and jessie-security. (Hence the severity). Thanks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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: https://lists.debian.org/20140921231823.75966.48928.report...@sid.kfreebsd-amd64.pyro.eu.org
Bug#722246: libc6: Please consider lowering minimal linux kernel version
On 09/09/13 13:25, Dmitrijs Ledkovs wrote: At configure time though, the minimal kernel version is set at 2.6.32. Probably glibc is dependent on functionality (syscalls and kernel interfaces) only available in the newer kernels. I doubt it's possible to lower that requirement, without substantial rewrite, or by losing some functionality that userland software now depends on. Alternatively, would you consider having a separate binary glibc package on i386/amd64 with minimal version set back to 2.6.16? Maybe some other libc could more easily do this, perhaps dietlibc? That would still require recompilation of binaries though I think? Then it makes more sense to just rebuild for kfreebsd natively. Or otherwise hope that FreeBSD linuxulator can add support newer syscalls of 2.6.32 and later. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/522e0e95.1030...@pyro.eu.org
Bug#704598: libc0.1-dev: sys/mount.h requires C99
On 12/04/13 17:49, Pino Toscano wrote: GNU/kFreeBSD porters, can you please take a look at this? At first glance at this, I think it was made 'static inline' because the function (copied from FreeBSD libc) really is being inlined into the header; it wouldn't be linked into the executable otherwise as glibc does not have it. I think 'static' is essential (so the function does not get exported / defined more than once), but maybe the 'inline' can be dropped without ill effects (a compiler might choose to inline it anyway). An alternative might have been the __inline GCC extension and the necessary defines for that macro to work, but that sounds messy - making something standards-compliant by using a nonstandard feature... This why I asked first if it is really worth the effort of trying to fix this. I couldn't find any packages in unstable that compile as C89. Maintaining compatibility with FreeBSD ports seems like a good enough reason so we should see what we can do about this. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/51687a57.4060...@pyro.eu.org
Bug#704598: libc0.1-dev: sys/mount.h requires C99
Hi Pino, $ gcc -D_BSD_SOURCE -std=c90 -o mount mount.c Do any packages actually do this? Compile with -std=c90 or -ansi or -std and use this header? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/515c270f.50...@pyro.eu.org
Bug#699593: login: wrong egid
Hi,
I don't think GNU/kFreeBSD's behaviour is wrong; but we may need to fix
some applications that suffer problems, including bash.
Maybe this is related to the problem (a wild guess really - the first
thing that jumped out at me as being wrong). There are checks for
__FreeBSD__ relating to euid/egid, and they may also need to check for
__FreeBSD_kernel__
bash-4.2/lib/sh/eaccess.c:
int
sh_eaccess (path, mode)
char *path;
int mode;
{
int ret;
if (path_is_devfd (path))
return (sh_stataccess (path, mode));
#if defined (HAVE_FACCESSAT) defined (AT_EACCESS)
return (faccessat (AT_FDCWD, path, mode, AT_EACCESS));
#elif defined (HAVE_EACCESS)/* FreeBSD */
ret = eaccess (path, mode); /* XXX -- not always correct for X_OK */
# if defined (__FreeBSD__)
if (ret == 0 current_user.euid == 0 mode == X_OK)
return (sh_stataccess (path, mode));
# endif
return ret;
and:
if (current_user.uid == current_user.euid current_user.gid ==
current_user.egid)
{
ret = access (path, mode);
#if defined (__FreeBSD__) || defined (SOLARIS)
if (ret == 0 current_user.euid == 0 mode == X_OK)
return (sh_stataccess (path, mode));
#endif
return ret;
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/510d8ea8.5080...@pyro.eu.org
Bug#698102: eglibc: initgroups changes egid on kfreebsd
Hi Michael, I'm not sure I understand what the problem is. In normal situations setgid() is called first - that changes the process's real+effective group ID - then initgroups() may be used afterward to add any additional groups the user is a member of. If used in that order, your testcase seems to work as expected on GNU/kFreeBSD: pw_name=steven pw_uid=1000 pw_gid=1000 uid=0(root) gid=0(root) groups=0(root) then after setgid(1000) : uid=0(root) gid=1000(steven) groups=0(root),1000(steven) then after initgroups(1000, 1000) : uid=0(root) gid=1000(steven) groups=0(root),1000(steven),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev) then after setuid(1000) : uid=1000(steven) gid=1000(steven) groups=1000(steven),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev) I'm not sure why you were seeing egid=27, but user 'michael' was already a member of that group. Only the superuser can use initgroups()... so I'm not sure this is a security problem? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/51059363.4020...@pyro.eu.org
Bug#696556: [kfreebsd] ldd: segfault with inkscape/inkview executables
Here's a small testcase that executes fine, but triggers a Bus error
(return status 138) from ldd on kfreebsd-amd64, but not Linux amd64:
$ cat testcase.c
unsigned char foo[16*1024*1024];
void main() { }
$ gcc testcase.c -o testcase
$ ./testcase
$ /lib/ld-kfreebsd-x86-64.so.1 --verify ./testcase
Bus error
(gdb) run --verify ./testcase
Starting program: /lib/ld-kfreebsd-x86-64.so.1 --verify ./testcase
Cannot access memory at address 0x220128
Cannot access memory at address 0x220120
(gdb) bt full
#0 0x01021ab0 in ?? ()
No symbol table info available.
#1 0x in ?? ()
No symbol table info available.
This may be a different issue to the one seen with the inkscape binary,
which was a segfault instead (return status 139).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/50d7c304.5000...@pyro.eu.org
Bug#696556: [kfreebsd] ldd: segfault with inkscape/inkview executables
Package: libc-bin Version: 2.13-37 File: /usr/bin/ldd User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Hi, On 22/07/12 22:18, Steven Chamberlain wrote: $ ldd /usr/bin/inkscape ldd: exited with unknown exit code (139) [...] pid 16961 (ld-2.13.so), uid 1000: exited on signal 10 I haven't seen this happen with any other executables - the most notable thing about the inkscape/inkview 0.48.3.1-1 binaries is their large size. On linux amd64 the bug does not occur, but we see that some 100 dynamic libraries are linked in. I'm struggling to get any helpful debugging info: (gdb) run --verify ./inkscape Starting program: /usr/lib/debug/lib/x86_64-kfreebsd-gnu/ld-2.13.so --verify ./inkscape Cannot access memory at address 0x220128 Cannot access memory at address 0x220120 (gdb) bt #0 0x01021ab0 in ?? () #1 0x in ?? () From a separate run under ktrace(1) we get some rough idea of what leads up to the crash: 49053 ld-2.13.so CALL open(0x1241148,0invalid0,unused0) 49053 ld-2.13.so NAMI ./inkscape 49053 ld-2.13.so RET open 3 49053 ld-2.13.so CALL read(0x3,0x7fffcfb8,0x340) 49053 ld-2.13.so RET read 832/0x340 49053 ld-2.13.so CALL fstat(0x3,0x7fffcd00) [...] 49053 ld-2.13.so RET fstat 0 49053 ld-2.13.so CALL __getcwd(0x7fffc900,0x400) 49053 ld-2.13.so NAMI .. 49053 ld-2.13.so NAMI /usr/bin 49053 ld-2.13.so RET __getcwd 0 49053 ld-2.13.so CALL mmap(0x40,0xc5c000,0x5PROT_READ|PROT_EXEC,0x12MAP_PRIVATE|MAP_FIXED,0x3,0) 49053 ld-2.13.so RET mmap 4194304/0x40 49053 ld-2.13.so PSIG SIGSEGV SIG_DFL code=0x1 That mmap is the inkscape ELF executable, up to and including the .gcc_except_table section. The 0x1021ab0 address mentioned by GDB would be within that .gcc_except_table section, where I guess it's not supposed to be executing code? 1021aa4: 0001 0e550578 0060058d 01008801 .U.x.`.. 1021ab4: 05ff ff01081b 05450059 05ff .E.Y 1021ac4: ff013451 9f018c03 00850205 fe03008d ..4Q $ file inkscape inkscape: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for GNU/kFreeBSD 8.1.0, BuildID[sha1]=0x085d1e83d4ab8e3466e0a31b2f480cc7d9cda835, stripped -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/50d6055e.4010...@pyro.eu.org
Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing
On 29/05/12 18:00, Dominic Hargreaves wrote: On Sun, May 27, 2012 at 08:00:48PM +0100, Steven Chamberlain wrote: On 27/05/12 17:55, Steven Chamberlain wrote: I just checked to see if Petr's eglibc getosreldate() fix made any difference to the Perl waithires.t test [...] Actually this is fixed (#673711), I just didn't notice the other commit in pkg-glibc SVN. Thanks Petr! Thanks - I'd appreciate a heads-up when the updated package is available for test in sid. Hi Dominic, The new eglibc is installed in sid now. Hopefully that failing test can be re-enabled. (I'm running it now and it looks fixed to me). Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4fcc8af8.1090...@pyro.eu.org
Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing
Hi, I just checked to see if Petr's eglibc getosreldate() fix made any difference to the Perl waithires.t test; still seeing failures though. While here I noticed a new test failure -- always reproducible on my ZFS mount (+compression +dedup), but it works fine if I move the build directory onto a UFS mount. Maybe to do with the ordering of readdir() output? steven@kfreebsd-i386:~/perl-5.14.2$ ./perl t/op/threads-dirh.t TEST_VERBOSE=1 1..6 ok 1 - crash when duping dirh ok 2 - dir iterator is copied from one thread to another ok 3 - cloned iterator iterates exactly once over everything not already seen not ok 4 - cloned dir iterator that points to the end of the directory # Failed at t/op/threads-dirh.t line 92 # got rile # expected undef ok 5 # skip OS does not support long file names (and I mean *long*) ok 6 - no warnings during all that steven@kfreebsd-i386:~/perl-5.14.2$ ./perl t/op/threads-dirh.t TEST_VERBOSE=1 1..6 ok 1 - crash when duping dirh ok 2 - dir iterator is copied from one thread to another ok 3 - cloned iterator iterates exactly once over everything not already seen not ok 4 - cloned dir iterator that points to the end of the directory # Failed at t/op/threads-dirh.t line 92 # got zor # expected undef ok 5 # skip OS does not support long file names (and I mean *long*) ok 6 - no warnings during all that steven@kfreebsd-i386:~/perl-5.14.2$ ./perl t/op/threads-dirh.t TEST_VERBOSE=1 1..6 ok 1 - crash when duping dirh ok 2 - dir iterator is copied from one thread to another ok 3 - cloned iterator iterates exactly once over everything not already seen not ok 4 - cloned dir iterator that points to the end of the directory # Failed at t/op/threads-dirh.t line 92 # got thrit # expected undef ok 5 # skip OS does not support long file names (and I mean *long*) ok 6 - no warnings during all that Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4fc25c84.8020...@pyro.eu.org
Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing
On 27/05/12 17:55, Steven Chamberlain wrote: I just checked to see if Petr's eglibc getosreldate() fix made any difference to the Perl waithires.t test [...] Actually this is fixed (#673711), I just didn't notice the other commit in pkg-glibc SVN. Thanks Petr! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4fc279e0.8060...@pyro.eu.org
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
On 19/04/12 20:51, Robert Millan wrote: CCing #663056 El 19 dâabril de 2012 1:12, Steven Chamberlain ste...@pyro.eu.org ha escrit: For now I still have Petr's change applied. I notice that libsoup2.4's connection-test (see #663056) has stopped failing. (Just had 100/100 test passes, was previously seeing about 50% failures.) Are you sure? You mean you tried 100 times? It passed 100 times in a row. And another 100 times just now. I'm not sure that Petr's patch is what really fixed it, but I can try to narrow it down. You say the cause was well-known...? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f907c84.8000...@pyro.eu.org
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
On 19/04/12 20:54, Robert Millan wrote: CCing #575302 El 19 dâabril de 2012 1:12, Steven Chamberlain ste...@pyro.eu.org ha escrit: Also, perhaps related, I got through the (Python-powered) iceweasel 10.0.3esr test suite for the first time, without hangs (see #575302). Maybe this helped. That's really nice. Petr, could you give some explanation on that one-line patch you provided? Is it supposed to be the correct fix or is more work necessary? I'm not familiar with the whole picture but if you give some pointers I may be able to help. I only thought to test iceweasel because in #658704 you mentioned an infinite poll() loop (but you didn't show the timing, which you would get from kdump -T). Maybe if __pthread_sig_cancel is missed somehow, Petr's diff works around that by checking anyway for terminated child threads every couple of seconds. Just guessing. Python 2.7.3~rc2 fixed something else, that could have been causing iceweasel's test harness to hang (like waf in #668240) so that maybe also helped here. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f907e97.3040...@pyro.eu.org
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
On 18/04/12 19:59, Robert Millan wrote: El 18 dâabril de 2012 15:46, Steven Chamberlain ste...@pyro.eu.org ha escrit: With it, I hit a tst-timer5 regression during build. Don't worry about tst-timer5, it's a fake regression. Previously it succeeded by exitting without testing anything. Oh okay. For now I still have Petr's change applied. I notice that libsoup2.4's connection-test (see #663056) has stopped failing. (Just had 100/100 test passes, was previously seeing about 50% failures.) Also, perhaps related, I got through the (Python-powered) iceweasel 10.0.3esr test suite for the first time, without hangs (see #575302). Maybe this helped. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f8f4a47.4000...@pyro.eu.org
Bug#662018: libsoup2.4: FTBFS on kfreebsd-*: test-suite FAIL: context-test
On 23/03/12 22:13, Robert Millan wrote: Actually it's in librt. Swapping that library with a patched version didn't change anything either. I'll try over the weekend to find space to do a full rebuild + normal dpkg install of eglibc though. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f6d1971.8090...@pyro.eu.org
Bug#662018: libsoup2.4: FTBFS on kfreebsd-*: test-suite FAIL: context-test
On 22/03/12 20:23, Robert Millan wrote: Please could someone test this? It's not correct, but it should do the trick. Hi, I don't /think/ it worked. I didn't have enough disk space to rebuild eglibc entirely. I built only libc0.1-i686, with your patch, and replaced only the libpthread library on my system and re-tested. The same problem as before. If I can get a build system set up soon with enough disk space, I'll try this again properly by rebuilding+installing the whole of eglibc. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f6bd0ba.5000...@pyro.eu.org
