Mailing List Archive

On 29/08/2011 15:23, Jude Pereira wrote:
> I've been able to create stages for x86 under the uclibc profile using
> catalyst.
> I'd like that they get upstream to the gentoo mirrors, so that its
> available publicly.
>
> I'm also willing to maintain them, I'd love to be a gentoo uclibc
> maintainer for the x86 arch.

Excellent idea.

I am using latest uclibc (slightly newer git release than .32). It is
so much better and easier to use than what is in portage that we
desperately need to dump the current portage uclibc for all archs that
support nptl + uclibc latest! I don't think I have any local patches
now to build under this uclibc version...!

Additionally I have had some success enabling iconv on latest uclibc.
This needs some tweaking to the uclibc src if you are building under a
uclibc toolchain (it only builds correctly under a glibc toolchain, but
easy to workaround). Patches are on the uclibc mailing list and I can
highlight them if needed. It adds around 50KB to my build size, but also
it allows git and a bunch of other ebuilds to build successfully without
patching - some people may like this trade off - I suspect that the
build size could be reduced with some work

I have asked if someone would proxy maintain this - I don't have a whole
bunch of time, but I would love to see portage get pulled up to date if
someone had the time to give it a push? My vote would be for .32 to
become stable (subject to normal arch signoffs) and a regular git
snapshot to be tracked and keyword masked

I think uclibc stages will mainly be useful to highlight that gentoo is
a good build environment for embedded and to provide a working toolchain
for cross compiling. Love to see this become productionised

Cheers

Ed W

I do have the time to give the uclibc profile in portage a good kick. I'm
very much into this as I'm working with uclibc toolchains under the x86
mainly.

I'll make an ebuild for the new one, and test it out.


--Jude Pereira
(http://judepereira.com/blog)


On Wed, Aug 31, 2011 at 4:27 PM, Ed W <lists@wildgooses.com> wrote:

> On 29/08/2011 15:23, Jude Pereira wrote:
> > I've been able to create stages for x86 under the uclibc profile using
> > catalyst.
> > I'd like that they get upstream to the gentoo mirrors, so that its
> > available publicly.
> >
> > I'm also willing to maintain them, I'd love to be a gentoo uclibc
> > maintainer for the x86 arch.
>
> Excellent idea.
>
> I am using latest uclibc (slightly newer git release than .32). It is
> so much better and easier to use than what is in portage that we
> desperately need to dump the current portage uclibc for all archs that
> support nptl + uclibc latest! I don't think I have any local patches
> now to build under this uclibc version...!
>
> Additionally I have had some success enabling iconv on latest uclibc.
> This needs some tweaking to the uclibc src if you are building under a
> uclibc toolchain (it only builds correctly under a glibc toolchain, but
> easy to workaround). Patches are on the uclibc mailing list and I can
> highlight them if needed. It adds around 50KB to my build size, but also
> it allows git and a bunch of other ebuilds to build successfully without
> patching - some people may like this trade off - I suspect that the
> build size could be reduced with some work
>
> I have asked if someone would proxy maintain this - I don't have a whole
> bunch of time, but I would love to see portage get pulled up to date if
> someone had the time to give it a push? My vote would be for .32 to
> become stable (subject to normal arch signoffs) and a regular git
> snapshot to be tracked and keyword masked
>
> I think uclibc stages will mainly be useful to highlight that gentoo is
> a good build environment for embedded and to provide a working toolchain
> for cross compiling. Love to see this become productionised
>
> Cheers
>
> Ed W
>
>
>
>

On 31/08/2011 13:16, Jude Pereira wrote:
> I do have the time to give the uclibc profile in portage a good kick.
> I'm very much into this as I'm working with uclibc toolchains under
> the x86 mainly.
>
> I'll make an ebuild for the new one, and test it out.

I didn't need to do much more than trim out all the old patches and bump
the ebuild. Just to give a heads up, here are my main changes for
iconv/locales:


--- /usr/portage/sys-libs/uclibc/uclibc-0.9.30.1-r1.ebuild
2011-04-20 19:31:26.000000000 +0100
+++ /usr/local/portage/sys-libs/uclibc/uclibc-0.9.33_pre20110617.ebuild
2011-06-23 19:43:24.000000000 +0100
@@ -170,6 +173,10 @@
epatch "${WORKDIR}"/patch
fi

+ epatch "${FILESDIR}"/${PN}-${PV}-clean.patch
+ epatch "${FILESDIR}"/gen_wc8bit.patch
+ epatch "${FILESDIR}"/gen_wctype.patch
+
sed -i 's:getline:get_line:' extra/scripts/unifdef.c #277186

########## CPU SELECTION ##########
@@ -305,6 +312,14 @@
cp .config myconfig

emake -s clean > /dev/null || die "could not clean"
+
+ # TODO: These should depend on some useflag, eg iconv
+ # Run after make clean, otherwise files removed
+ find ./extra/locale/charmaps -name "*.pairs" >
extra/locale/codesets.txt
+ #cp ./extra/locale/LOCALES ./extra/locale/locales.txt
+ cp "${FILESDIR}"/locales.txt ./extra/locale/locales.txt
+ # TODO: Now edit locales as appropriate...
+ # FIXME: ...
}


Also, not sure I remember why, but I have this change...

-IUSE="build uclibc-compat debug hardened ssp ipv6 minimal wordexp
crosscompile_opts_headers-only"
+IUSE="build elibc_uclibc uclibc-compat debug hardened ssp ipv6 minimal
wordexp crosscompile_opts_headers-only"



The missing patch files are attached (note the _clean_ is not needed on
recent git). Note the gen_wc patches should be credited/copyrighted to
the chap whos name I forget on the uclibc list who posted them about Feb
this year?

Bit of a mess, but hopefully helpful?

Ed W

Hey Ed,
I bumped the ebuild to the snapshot of 20110831 last evening, I've
successfully compiled it, but then python goes crazy.

It says that it cant find libutil.so.0, but it is actually in the correct
lib dir. I'm going to look into this even more now.


--Jude Pereira
(http://judepereira.com/blog)


On Wed, Aug 31, 2011 at 8:49 PM, Ed W <lists@wildgooses.com> wrote:

> On 31/08/2011 13:16, Jude Pereira wrote:
> > I do have the time to give the uclibc profile in portage a good kick.
> > I'm very much into this as I'm working with uclibc toolchains under
> > the x86 mainly.
> >
> > I'll make an ebuild for the new one, and test it out.
>
> I didn't need to do much more than trim out all the old patches and bump
> the ebuild. Just to give a heads up, here are my main changes for
> iconv/locales:
>
>
> --- /usr/portage/sys-libs/uclibc/uclibc-0.9.30.1-r1.ebuild
> 2011-04-20 19:31:26.000000000 +0100
> +++ /usr/local/portage/sys-libs/uclibc/uclibc-0.9.33_pre20110617.ebuild
> 2011-06-23 19:43:24.000000000 +0100
> @@ -170,6 +173,10 @@
> epatch "${WORKDIR}"/patch
> fi
>
> + epatch "${FILESDIR}"/${PN}-${PV}-clean.patch
> + epatch "${FILESDIR}"/gen_wc8bit.patch
> + epatch "${FILESDIR}"/gen_wctype.patch
> +
> sed -i 's:getline:get_line:' extra/scripts/unifdef.c #277186
>
> ########## CPU SELECTION ##########
> @@ -305,6 +312,14 @@
> cp .config myconfig
>
> emake -s clean > /dev/null || die "could not clean"
> +
> + # TODO: These should depend on some useflag, eg iconv
> + # Run after make clean, otherwise files removed
> + find ./extra/locale/charmaps -name "*.pairs" >
> extra/locale/codesets.txt
> + #cp ./extra/locale/LOCALES ./extra/locale/locales.txt
> + cp "${FILESDIR}"/locales.txt ./extra/locale/locales.txt
> + # TODO: Now edit locales as appropriate...
> + # FIXME: ...
> }
>
>
> Also, not sure I remember why, but I have this change...
>
> -IUSE="build uclibc-compat debug hardened ssp ipv6 minimal wordexp
> crosscompile_opts_headers-only"
> +IUSE="build elibc_uclibc uclibc-compat debug hardened ssp ipv6 minimal
> wordexp crosscompile_opts_headers-only"
>
>
>
> The missing patch files are attached (note the _clean_ is not needed on
> recent git). Note the gen_wc patches should be credited/copyrighted to
> the chap whos name I forget on the uclibc list who posted them about Feb
> this year?
>
> Bit of a mess, but hopefully helpful?
>
> Ed W
>
>
>

On 01/09/2011 04:27, Jude Pereira wrote:
> Hey Ed,
> I bumped the ebuild to the snapshot of 20110831 last evening, I've
> successfully compiled it, but then python goes crazy.
>
> It says that it cant find libutil.so.0, but it is actually in the correct
> lib dir. I'm going to look into this even more now.
>

Hi, uclibc can break if you don't do a binary compatible upgrade.
Because it's so configurable, it's much easier to break it if you
accidently change something in the config which has big implications.
For example I think it proved very difficult to switch uclibc from non
hardened to hardened because it breaks before you can re-install?

Additionally, I forget the details now, but I think this bug hit some
people before - not sure if it's properly resolved in current uclibc either?

https://bugs.busybox.net/show_bug.cgi?id=1543

It's not something I recall running into though, so possibly a config
change has caused / will rectify things?

Ed W