When building uclibc stage1's, you get a bunch of warning of the form: * Messages for package sys-apps/file-5.12-r1 merged to /tmp/stage1root/: * uClibc patch set 'uclibc-conf' failed to apply! This is coming from the patches applied by elibtoolize at $PORTDIR/eclass/ELT-patches/uclibc-conf/{1.2.0,1.3.0c} Its easy to confirm that these fail if you try to apply them manually. The build succeed despite the fact that the patch fails. Other patches succeed. Reproducible: Always
Created attachment 364036 [details, diff] updated patch These patches date back to 2005 so I'm not even sure what the numbers 1.2.0 or 1.3.0c refer to. Nonetheless, hunk 2 seems to have no equivalent in the newer configure scripts and it was just there for even older configure scripts, so it might have been simply dropped by upstream. For what its worth, this is the updated patch.
(In reply to Anthony Basile from comment #1) the versions reflect the *libtool* version they're attempting to patch. the whole point of elibtoolize is to not require the latest libtool version, nor require re-running of autotools. i'm not sure these patches are needed with newer libtool versions. iirc, the newer libtool versions "just work" for uclibc targets.
(In reply to SpanKY from comment #2) > (In reply to Anthony Basile from comment #1) > > the versions reflect the *libtool* version they're attempting to patch. the > whole point of elibtoolize is to not require the latest libtool version, nor > require re-running of autotools. > > i'm not sure these patches are needed with newer libtool versions. iirc, > the newer libtool versions "just work" for uclibc targets. I'm pretty sure they do. I'll test.
(In reply to Anthony Basile from comment #3) > (In reply to SpanKY from comment #2) > > (In reply to Anthony Basile from comment #1) > > > > the versions reflect the *libtool* version they're attempting to patch. the > > whole point of elibtoolize is to not require the latest libtool version, nor > > require re-running of autotools. > > > > i'm not sure these patches are needed with newer libtool versions. iirc, > > the newer libtool versions "just work" for uclibc targets. > > I'm pretty sure they do. I'll test. 1) This bug was triggered by the last commit ---------------------------- revision 1.107 date: 2013-11-22 04:05:55 -0500; author: haubi; state: Exp; lines: +84 -89; commitid: a50528f1e3b4567; libtool.eclass elibtoolize(): Besides ltmain.sh, explicitly locate configure to apply patches rather than guessing based on where ltmain.sh was found. ---------------------------- 2) The uclibc-conf patch is not needed for any of the in-tree versions of libtool and its just works for uclibc. I recommend we just remove it: 1) cvs rm eclass/ELT-patches/uclibc-conf/{1.2.0,1.3.0c} 2) We apply the following patch to libtool.eclass diff -Nuar /usr/portage/eclass/libtool.eclass eclass/libtool.eclass --- /usr/portage/eclass/libtool.eclass 2013-11-22 09:31:16.000000000 +0000 +++ eclass/libtool.eclass 2013-11-30 17:59:39.990179604 +0000 @@ -185,7 +185,7 @@ esac done - [[ ${do_uclibc} == "yes" ]] && elt_patches+=" uclibc-conf uclibc-ltconf" + [[ ${do_uclibc} == "yes" ]] && elt_patches+=" uclibc-ltconf" case ${CHOST} in *-aix*) elt_patches+=" hardcode aixrtl aix-noundef" ;; #213277 @@ -375,12 +375,6 @@ ret=0 case ${p} in - uclibc-conf) - if grep -qs 'Transform linux' "${d}/configure" ; then - ELT_walk_patches "${d}/configure" "${p}" - ret=$? - fi - ;; fbsd-conf) if grep -qs 'version_type=freebsd-' "${d}/configure" ; then ELT_walk_patches "${d}/configure" "${p}"
Sorry for the wrap in the patch on the previous post. Actually, we don't need either uclibc-conf or uclibc-ltconf patches, so we could go even further and remove all special treatment of uclibc in libtool.eclass. I tested with >=sys-devel/libtool-1.5.26-r1 on several packages running elibtoolize abd found no issues. NOTE: For some reason I haven't figure out yet, =sys-devel/libtool-1.3.5 fails to build on uclibc. libltdl.so doesn't get built although libltdl.a does.
(In reply to Anthony Basile from comment #4) i think you're misunderstanding the point of these patches. it doesn't matter what version of libtool is installed in /usr/bin/. when packages are made, they are done so with the libtool version installed at that time. then we live with those for a long time until the maintainer updates their distro/build packages, and releases a new version. at this point, the number of packages we still build that use older than libtool-1.5.x is probably pretty low, but i suspect it is not zero. we probably can just drop the warning now though. it made a lot of sense in the early days of the uClibc port (10 years ago), but since things are largely sane now, it's probably useless. let's just delete the warning.
(In reply to SpanKY from comment #6) > (In reply to Anthony Basile from comment #4) > > i think you're misunderstanding the point of these patches. it doesn't > matter what version of libtool is installed in /usr/bin/. when packages are > made, they are done so with the libtool version installed at that time. > then we live with those for a long time until the maintainer updates their > distro/build packages, and releases a new version. Yeah, after reading the eclass its pretty clear what's going on. > > at this point, the number of packages we still build that use older than > libtool-1.5.x is probably pretty low, but i suspect it is not zero. It would be hard to know, so we can't drop those patches. > > we probably can just drop the warning now though. it made a lot of sense in > the early days of the uClibc port (10 years ago), but since things are > largely sane now, it's probably useless. let's just delete the warning. Dropping the warning is good enough.
Created attachment 364558 [details, diff] Remove the warning for uclibc is patching fails.
Comment on attachment 364558 [details, diff] Remove the warning for uclibc is patching fails. doooooooooo it
(In reply to SpanKY from comment #9) > Comment on attachment 364558 [details, diff] [details, diff] > Remove the warning for uclibc is patching fails. > > doooooooooo it done
