Re: [gentoo-embedded] some uClibc experience

[Ned Ludd]

On Wed, 2003-11-12 at 16:31, Peter S. Mazinger wrote:
> Hello!
>
> I'm new to gentoo(and -embedded). I have built on x86 successfully the
> attached list of packages
What attached list?
> (based on Redhat's rawhide releases) against
> uClibc-0.9.2[0-2], all RPMS. If the used patches are needed (and the
> spec-files), I would provide them (sorry, the src.rpm's are not
> downloadable, I am behind an analog modem ;-( ). The main problems where
> NIS,PAM,NLS and some functions missing (not required by SUSv3). The
> packages are not used (yet) on a production system.


> I've also got a patch for uClibc from the PaX team, to make it possible to
> use ET_DYN binaries (pax version, not -pie), but do not have the knowledge
> to correct it (if the correction is done, the developers would include it
> into uClibc), so hardened-embedded support would work too (I use kernels
> patched with grsec-1.x, 2.x would be no problem, the PaX part is the
> same, no experience with lsm/selinux and 2.6 kernels).

For this we are in luck. I've add a new local use flag for uClibc-0.9.22
called "etdyn" which adds support thanks to the patch provided by the
PaX Team for the 0.9.22 build we also add in the interp.c and crt1S.S

Note: 
A second cleaner PaX patch is in the works right now, I'm sure you will
see a copy of it here soon enough. 

>
> There are problems building some of the binaries with propolice enabled
> gcc, mainly the .hidden support in binutils has to be "hidden" from gcc,
> but as I can see (read), the glibc version does not work flawlessly
> either.
>
Have you successfully used ssp with uclibc?

> Some (earlier) ideas (or from other gentoo-* lists)
> 1. UPX works too (I have built 1.91-cvs), the compression is not so good,
> as with prebuilt binaries (NRV is not free), but works also on kernel
> images (bzImage)

Would this have a big advantage over say cramfs support? I would assume
that most compressed file systems or executable packers also tend to use
more memory on access whihc could lead to an ever slower system.

>
> 2. As I have read on the gentoo-dev list, there are many against splitting
> the packages in subpackages. For this project it is a "must have it", like
> what ibuild tries to do (if I interpreted it correctly), Bering does it
> too)
Good thing we are on the #gentoo-embedded list and are pretty much free
to decide what's best for our own needs.

>
> 3. The uClibc toolchain is not uptodate, but the buildroot is already used
> by the developers themselves to create development images, so the infos on
> cross-building are there and tested already.

Please take a look at the 0.9.22 ebuild in portage. The wrappers for
gcc,c++,ld,ldd,ar,etc are all missing and I don't know why. I've checked
the detail/changelogs on the uclibc.org site and see no mention of this
what so ever.

> This is the path I go too, if
> uClibc becomes binary incompatible. I build first the target development
> environment, then chroot into it and rebuild rpm, after that rebuilding
> all other packages.
>
> 4. My preference would be to replace sysvinit stuff (I think included in
> baselayout) with some other init (runit, minit, simpleinit, twsinit) to
> have better dependency handling in the startup scripts, also allowing
> parallel startup of services.
We can more or less dump all of the baselayout and or repackage it or
make an e-baselayout.

> 5. -Os would be better to be default for embedded (instead of -O2) (seen
> in the embedded profile)

Thanks.. fixed in portage.


Please note that the uclibc-x86-1.4 profile is in no way shape or form
ready for any sort of production, it's 100% untested as of now.

We leave it up to you guys on the mailing list to help decide what
should stay and what must go in the profile as well as submitting any
new profiles for xyz arch.

> Peter

-- 
Ned Ludd <solar@g.o>
Gentoo Linux Developer