Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 406303 - sys-apps/util-linux-2.20.1 with sys-libs/uclibc - fails to compile because of missing scanf support
Summary: sys-apps/util-linux-2.20.1 with sys-libs/uclibc - fails to compile because of...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL: http://repository.timesys.com/buildso...
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2012-02-29 14:12 UTC by Ed Wildgoose
Modified: 2012-04-21 17:35 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to make libmount optional (util-linux-uclibc.patch,681 bytes, patch)
2012-04-16 12:38 UTC, James Le Cuirot
Details | Diff
Patch to make libmount optional (util-linux-uclibc.patch,1.00 KB, patch)
2012-04-16 12:41 UTC, James Le Cuirot
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Wildgoose 2012-02-29 14:12:12 UTC
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
Comment 1 Anthony Basile gentoo-dev 2012-02-29 20:22:35 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?
Comment 2 Ed Wildgoose 2012-03-01 00:41:32 UTC
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?
Comment 3 Anthony Basile gentoo-dev 2012-03-03 01:44:04 UTC
(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
Comment 4 James Le Cuirot gentoo-dev 2012-04-16 12:38:22 UTC
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
Comment 5 James Le Cuirot gentoo-dev 2012-04-16 12:41:09 UTC
Created attachment 309139 [details, diff]
Patch to make libmount optional

Forgot to remove uclibc from IUSE.
Comment 6 SpanKY gentoo-dev 2012-04-20 03:36:29 UTC
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.
Comment 7 James Le Cuirot gentoo-dev 2012-04-20 07:33:48 UTC
(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.
Comment 8 James Le Cuirot gentoo-dev 2012-04-20 07:38:33 UTC
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.
Comment 9 Anthony Basile gentoo-dev 2012-04-20 09:22:56 UTC
(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.
Comment 10 Anthony Basile gentoo-dev 2012-04-20 11:58:54 UTC
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.
Comment 11 Ed Wildgoose 2012-04-20 14:19:25 UTC
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
Comment 12 Anthony Basile gentoo-dev 2012-04-20 21:21:11 UTC
(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.
Comment 13 SpanKY gentoo-dev 2012-04-21 06:22:57 UTC
(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).
Comment 15 Anthony Basile gentoo-dev 2012-04-21 13:44:27 UTC
(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.
Comment 16 James Le Cuirot gentoo-dev 2012-04-21 13:57:22 UTC
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
Comment 17 Anthony Basile gentoo-dev 2012-04-21 14:05:11 UTC
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.