Summary: | sys-apps/util-linux-2.20.1 with sys-libs/uclibc - fails to compile because of missing scanf support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ed Wildgoose <gentoo> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chewi, embedded |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://repository.timesys.com/buildsources/u/util-linux/util-linux-2.20.1/util-linux-2.20.1-sscanf-no-ms-as.patch | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch to make libmount optional
Patch to make libmount optional |
Description
Ed Wildgoose
2012-02-29 14:12:12 UTC
(In reply to comment #0) > uclibc doesn't support the non standard scanf flags to automatically malloc > the destination buffer, as a result util-linux-2.20.1 fails to compile with > a tangential error about a missing definition for macro UL_SCNsA > > tab_parse.c: In function 'mnt_parse_table_line': > tab_parse.c:57: error: 'UL_SCNsA' undeclared (first use in this function) > tab_parse.c:57: error: (Each undeclared identifier is reported only once > tab_parse.c:57: error: for each function it appears in.) > tab_parse.c:57: error: expected ')' before string constant > > > The solution is in patch: > http://repository.timesys.com/buildsources/u/util-linux/util-linux-2.20.1/ > util-linux-2.20.1-sscanf-no-ms-as.patch > > There is already a uclibc use flag for this ebuild and the patch could be > made conditional only for uclibc - however, it should also be safe to apply > unconditionally Yes I've seen this on uclibc-0.9.32.2 both x86 and amd64 (probably arch independant). What version did you test? I'm currently using 0.9.33 (I also use the iconv and locale features in uclibc - it appears to sort of work...) I don't think there is any doubt about the problem? There is a patch in the uclibc tracker with a proposed fix from 2005, also some stub code in uclibc which is commented out. Very happy to see an upstream fix, but the patch in the link here seems correct to my eye? (In reply to comment #2) > I'm currently using 0.9.33 (I also use the iconv and locale features in > uclibc - it appears to sort of work...) > > I don't think there is any doubt about the problem? There is a patch in the > uclibc tracker with a proposed fix from 2005, also some stub code in uclibc > which is commented out. Very happy to see an upstream fix, but the patch in > the link here seems correct to my eye? The timesys patch reverts the UL_SCNsA macro. I've been using the following patch which just assumes that if you don't have the %ms modifier to use the %as. It works but now I'm testing the timesys patch. diff -Naur util-linux-2.20.1.orig//include/c.h util-linux-2.20.1/include/c.h --- util-linux-2.20.1.orig//include/c.h 2011-10-18 08:22:27.000000000 -0400 +++ util-linux-2.20.1/include/c.h 2012-02-16 15:23:55.000000000 -0500 @@ -216,7 +216,7 @@ */ #ifdef HAVE_SCANF_MS_MODIFIER #define UL_SCNsA "%ms" -#elif defined(HAVE_SCANF_AS_MODIFIER) +#else #define UL_SCNsA "%as" #endif Created attachment 309137 [details, diff] Patch to make libmount optional As of util-linux-2.21.1, it correctly detects the lack of support during configure and doesn't build libmount as a result. The problem with this is that the ebuild expects libmount to be there so a small adjustment is necessary. Also, the uclibc USE flag is no longer necessary because mount/lomount.c doesn't exist any more. Somewhat related is another uClibc failure arising from a bug that has appeared since the last version. The following patch is now required. https://github.com/karelzak/util-linux/commit/69cabd7204e39c5e6055b6a53cf882b9f48f3c60 Created attachment 309139 [details, diff]
Patch to make libmount optional
Forgot to remove uclibc from IUSE.
Comment on attachment 309139 [details, diff]
Patch to make libmount optional
err, no ... disabling libmount isn't the way to go. other packages in the system (like udev) rely on that.
(In reply to comment #6) > err, no ... disabling libmount isn't the way to go. other packages in the > system (like udev) rely on that. I read somewhere that this is only the case for udev in upcoming versions. 182 doesn't seem to need it. >udev-141 is masked in the uclibc profile because later versions depend directly on glibc. I'm not sure why that is but it effectively sidesteps this issue, at least for the time being. I did manage to build @system without libmount, although I haven't tried booting with that system yet. If you think this is still an issue, you'll probably have to take it up with upstream. By the way, I don't think the solution suggested by Anthony above to use %as instead will work. From what I could see, that isn't supported by uClibc either. You can force %as by setting scanf_cv_alloc_modifier=as but I'm pretty sure I got a build error when I tried it. (In reply to comment #8) > By the way, I don't think the solution suggested by Anthony above to use %as > instead will work. From what I could see, that isn't supported by uClibc > either. You can force %as by setting scanf_cv_alloc_modifier=as but I'm > pretty sure I got a build error when I tried it. It does work or at least did. Anyhow it is not a solution, just a workaround. The correct solution would be to get the support in scanf. Okay, so I was playing with this little poc to isolate what was going on and I compiled it on both a glibc and uclibc system --- glibc = 2.13-r4 and uclibc = 0.9.33.1. gcc-4.6. #include <stdio.h> int main() { char *p; int n = sscanf("hi mom", "%3mc", &p); //int n = sscanf("hi mom", "%ms", &p); //int n = sscanf("hi mom", "%as", &p); printf("%d %s\n", n, p); return 0; } On both systems, the code compiles with "%3mc", "%ms" or "%as", but: 1) on the uclibc system, all three give garbage. 2) on the glibc system, "%ms" and "%3mc" work, but "%as" does not. Since I mostly use hardened, I also checked my result for 2 on a pure vanilla gentoo system. The timesys patch is the best way to go because it returns to the tried and true malloc the buffer you need before scanf-ing into it. I would second that either manually malloc locally (what we have all done for years), or patch uclibc. How about both? On the surface it looks like a straightforward patch for uclibc, although I conced it's going to need to wait at least some weeks if you want the code from me... However, given we are still struggling to agree on an ebuild for uclibc that is newer than 5 years old, it will take some time before users can benefit anyway Therefore I would request that the patch to malloc space locally is accepted for the time being (I see no reason not to accept for glibc also since it does no harm?). In 12 months we can review if enough systems can live without it to drop it? Thanks (In reply to comment #11) > from me... However, given we are still struggling to agree on an ebuild for > uclibc that is newer than 5 years old, it will take some time before users > can benefit anyway Nah, an ebuild has to satisfy the community's needs, not mine. So no real struggle to agree. Anyhow I rethought an approach that might work for everyone, something like start with my default mostly ON config and then turn things off carefully based on what USE flags are given/not given. The USE flags are chosen by matching sets of options provided by uclibc and well established global USE flags in the gentoo pantheon. Flags like hardened, threads, ipv6, etc. with USE REQUIRED connecting things like hardened and nptl. Plus cross compile stuff with proper subarch selection and I think everyone's happy. I'm very busy until 2nd week in May, but maybe I'll propose something then. (In reply to comment #7) i don't need to go to util-linux upstream. i can simply say "no" now to attempting to disable libmount. their code is arguably not broken as they're relying on POSIX support which uClibc lacks. pretty sure that timesys patch has bugs (not allocating all pointers). and it's ugly. so i just rewrote it myself. (In reply to comment #9) it "worked" in that it compiled. at runtime, it will not work as James said -- uClibc doesn't support this flag (which only gets checked at runtime). should be all set now in the tree; thanks for the report! Commit message: Add support for older C libraries that do not support latest POSIX standard (%as flags) http://sources.gentoo.org/sys-apps/util-linux/files/util-linux-2.20.1-no-printf-alloc.patch?rev=1.1 http://sources.gentoo.org/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc.patch?rev=1.1 http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.20.1-r1.ebuild?r1=1.6&r2=1.7 http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.20.1-r2.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.21.1.ebuild?r1=1.4&r2=1.5 http://sources.gentoo.org/sys-apps/util-linux/util-linux-9999.ebuild?r1=1.30&r2=1.31 (In reply to comment #14) > should be all set now in the tree; thanks for the report! I'm getting a seg fault with that patch on i686 or amd64, hardened or vanilla. I traced it down to mnt_parse_mountinfo_line() in libmount/src/tab_parse.c between the lines I have marked HERE3 and HERE4: /* (7) optional fields, terminated by " - " */ p = strstr(s, " - "); if (!p) { DBG(TAB, mnt_debug("mountinfo parse error: not found separator")); return -EINVAL; } s = p + 3; printf("HERE3\n"); rc += sscanf(s, UL_SCNsA" " /* (8) FS type */ UL_SCNsA" " /* (9) source */ UL_SCNsA, /* (10) fs options (fs specific) */ #ifdef HAVE_SCANF_MS_MODIFIER &fstype, &src, &fs->fs_optstr); #else fstype, src, fs->fs_optstr); #endif printf("HERE4\n"); An strace shows the following death: mprotect(0x4af57000, 4096, PROT_READ) = 0 mprotect(0x4af30000, 8192, PROT_READ) = 0 mprotect(0x4af0a000, 4096, PROT_READ) = 0 mprotect(0x4af04000, 4096, PROT_READ) = 0 mprotect(0x4aee8000, 4096, PROT_READ) = 0 mprotect(0x4af6a000, 4096, PROT_READ) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 access("/proc/self/mountinfo", R_OK) = 0 brk(0) = 0x13acd3ec brk(0x13ace3ec) = 0x13ace3ec brk(0x13acf000) = 0x13acf000 open("/proc/self/mountinfo", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x59fce7e8) = -1 ENOTTY (Inappropriate ioctl for device) read(3, "12 1 8:3 / / rw,noatime - ext4 /"..., 4096) = 474 write(1, "HERE2\n", 6HERE2 ) = 6 write(1, "HERE3\n", 6HERE3 ) = 6 --- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} (Segmentation fault) --- +++ killed by SIGSEGV +++ Segmentation fault This doesn't look directly related to the original bug (although triggered when fixed). Still tracing it. It's going into the next release so it's not as essential but don't forget about this patch for 2.21.1... https://github.com/karelzak/util-linux/commit/69cabd7204e39c5e6055b6a53cf882b9f48f3c60 Its in reading in fs->fs_optstr. That's fs->fs_optstr not fs->vfs_optstr, without a 'v', so you're missing a malloc for it earlier around line 140. Adding it fixes the seg fault. should be all set now in the tree; thanks for the report! Commit message: Also malloc fs_optstr http://sources.gentoo.org/sys-apps/util-linux/files/util-linux-2.20.1-no-printf-alloc.patch?r1=1.1&r2=1.2 http://sources.gentoo.org/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc.patch?r1=1.1&r2=1.2 |