>
> On Sunday 18 March 2012 14:53:44 Joakim Tjernlund wrote:
> > What bugs me is that one can generally use /usr/$CTARGET as your root fs on
> > your favourite embedded target. Doing so will loose libgcc_s.so as there
> > isn't one installed. Having to install gcc into /usr/$CTARGET just to get
> > libgcc_s is a bit much.
>
> why does this actually matter ? as noted, this hack is merely there to
> support a split /usr setup. if you're using /usr/$CTARGET as your rootfs,
> then you aren't going to have a split /usr, and thus the lib copy is
> unnecessary.

I don't quite understand. If I copy /usr/$CTARGET to my target board
as rootfs there will be no libgcc on my target and NPTL needs it.

>
> > Also, would it not be better if glibc showed up in
> > export ROOT=/usr/${CTARGET} PKGDIR=${PORTDIR}/pkgs/${CTARGET}/pkgs
> > quickpkg `qlist -IC` instead of
> > export ROOT=/ PKGDIR=${PORTDIR}/pkgs/${CTARGET}/cross-tools quickpkg
> > `qlist -IC cross-${CTARGET}` ?
>
> no. cross-${CTARGET}/glibc is a cross-compiler glibc, not a native one. yes,
> you can run it through a script to move things around so that it'd basically
> have the same install as a native glibc, but the existing one is not.
>
> it might be useful to have crossdev automatically inject glibc into
> package.provided for /usr/$CTARGET since attempting to install a native one in
> there will hit conflicts.

hmm, I always viewed glibc under /usr/$CTARGET as a native target glibc which
could be copied to the target directly, but now you say it is not?
So I should continue building glibc under my own tree (that is what I have been doing
but I figured I could optimize away that step)?
Jocke