stages for x86 uclibc
 

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.



Let me know.
--Jude Pereira
(http://judepereira.com/)

stages for x86 uclibc
 

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

stages for x86 uclibc
 

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

stages for x86 uclibc
 

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



<<< application/octet-stream; name="gen_wc8bit.patch": Unrecognized >>>


<<< application/octet-stream; name="uclibc-0.9.33_pre20110617-clean.patch": Unrecognized >>>

# First some @modifier mappings. Internally, the modifier is signaled by
# replacing '_' in the locale name with a unique identifying character.
# For example, internally we map "ca_ES@euro" to "caeES". This allows for
# smaller code and easier processing of locale names.

@euro e
@cyrillic c

#---------------------------------------------------------------------------
# Next, set to {y}es to enable and {n}o to disable the UTF-8 and the 8-bit
# codeset locales. Of course, you must have built the c8tables.h and
# the wctables.h files appropriately.


UTF-8 yes
8-BIT yes

#---------------------------------------------------------------------------
# Now the locales

en_GB ISO-8859-1
en_GB.UTF-8 UTF-8


<<< application/octet-stream; name="gen_wctype.patch": Unrecognized >>>

stages for x86 uclibc
 

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