When trying to built util-linux-2.25.2 against uclibc the build process drops out with UL_SCNsA undeclared (first use in this function) when compiling colors.c. This looks alot like https://bugs.gentoo.org/show_bug.cgi?id=458496 just a different file is affected this time. Reproducible: Always The error msg refers to line 579 in colors.c.
1) Please attach the entire build log to this bug report. 2) Please post your `emerge --info' output in a comment.
Created attachment 391172 [details] emerge-x86_64-pc-linux-uclibc --info
Created attachment 391178 [details] uclibc.build.log build.log
I has not been able to find any other reference to this error than: http://www.spinics.net/lists/util-linux-ng/msg10496.html :/
bug 458496 was fixed by me implementing %ms in uClibc itself. 0.9.33.2-r12 has that fix so your system should work. please attach the config.log from the build dir. there's no way for us to know otherwise why you're getting this: checking scanf string alloc modifiers... no
Created attachment 398812 [details] config.log config.log as req
Back to unconfirmed as info was provided as requested.
(In reply to Sven E. from comment #7) > Back to unconfirmed as info was provided as requested. 1) I just tested and could not reproduce using a fresh stage3 uclibc from the mirrors. Not surprising since I would have hit this a hundred time by now with all the uclibc testing I do. 2) It looks like the failing program in hte config file is | #include <stdio.h> | #include <unistd.h> | | #ifdef __GLIBC__ | | #if !(__GLIBC_PREREQ(2, 7)) | #error %m is not available | #endif | | #elif defined(_POSIX_VERSION) | | #if _POSIX_VERSION < 200809L | #error %m is not available | #endif | | #else | #error Your C-library is not supported. | #endif Running this on my system I do see why it fails. If you run the following: #include <stdio.h> #include <unistd.h> int main() { printf("%d\n", __GLIBC__); printf("%d\n", __GLIBC_PREREQ(2, 7)); printf("%ld\n", _POSIX_VERSION); } you get 2 0 200112 which tells us that the first `#error %m is not available` is being triggered. I don't know how you are getting here though, because as I said, I don't hit it on my uclibc systems.
(In reply to Anthony Basile from comment #8) > I don't know how you are getting here though, because as I said, > I don't hit it on my uclibc systems. Ah I now know. If you read the ./configure file (or configure.ac), you see it uses the test from comment #8 if you are cross compiling, while it uses a compile test if its native. So that test in configure.ac needs to be fixed.
(In reply to Anthony Basile from comment #9) > (In reply to Anthony Basile from comment #8) > > I don't know how you are getting here though, because as I said, > > I don't hit it on my uclibc systems. > > Ah I now know. If you read the ./configure file (or configure.ac), you see > it uses the test from comment #8 if you are cross compiling, while it uses a > compile test if its native. So that test in configure.ac needs to be fixed. It seems that this particular issue was somehow fixed in 2.26, which in turn fails at a later point during compilation (unfortunately). Maybe some change in 2.26 can be backported, if the goal is fixing 2.25.x?
(In reply to Sven E. from comment #10) > (In reply to Anthony Basile from comment #9) > > (In reply to Anthony Basile from comment #8) > > > I don't know how you are getting here though, because as I said, > > > I don't hit it on my uclibc systems. > > > > Ah I now know. If you read the ./configure file (or configure.ac), you see > > it uses the test from comment #8 if you are cross compiling, while it uses a > > compile test if its native. So that test in configure.ac needs to be fixed. > > It seems that this particular issue was somehow fixed in 2.26, which in turn > fails at a later point during compilation (unfortunately). Maybe some change > in 2.26 can be backported, if the goal is fixing 2.25.x? If we do want it in 2.25.x I think that `export scanf_cv_alloc_modifier=ms` before you emerge should do the trick. If you have the chance, can you test. Also open a bug for the other failure. I got 2.26 going just fine at my end.
(In reply to Anthony Basile from comment #11) > (In reply to Sven E. from comment #10) > > (In reply to Anthony Basile from comment #9) > > > (In reply to Anthony Basile from comment #8) > > > > I don't know how you are getting here though, because as I said, > > > > I don't hit it on my uclibc systems. > > > > > > Ah I now know. If you read the ./configure file (or configure.ac), you see > > > it uses the test from comment #8 if you are cross compiling, while it uses a > > > compile test if its native. So that test in configure.ac needs to be fixed. > > > > It seems that this particular issue was somehow fixed in 2.26, which in turn > > fails at a later point during compilation (unfortunately). Maybe some change > > in 2.26 can be backported, if the goal is fixing 2.25.x? > > If we do want it in 2.25.x I think that `export scanf_cv_alloc_modifier=ms` > before you emerge should do the trick. If you have the chance, can you test. > > Also open a bug for the other failure. I got 2.26 going just fine at my end. Exporting the variable did the trick to get a minimal set of util-linux compiled. The binaries seem to work in a short test I did. BTW, there's a heapload of warnings about __fpending() returning the same value for narrow and wide, I just hope this won't cause problems somewhen.
*** Bug 550768 has been marked as a duplicate of this bug. ***
should be all set now in the tree; thanks for the report! Commit message: Force the scanf configure test to select the POSIX version when cross-compiling http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.25.2-r2.ebuild?r1=1.14&r2=1.15 http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.26.2.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/sys-apps/util-linux/util-linux-9999.ebuild?r1=1.63&r2=1.64