Re: [gentoo-embedded] latest changes for uclibc mainly

[Peter S. Mazinger]

---------- Forwarded message ----------
Date: Sun, 27 Jun 2004 08:40:05 +0200 (CEST)
From: Peter S. Mazinger <mps@×××××××××.intra>
To: Ned Ludd <solar@g.o>
Cc: toolchain@g.o, gentoo-embedded@l.g.o
Subject: Re: [gentoo-embedded] latest changes for uclibc mainly

On 26 Jun 2004, Ned Ludd wrote:

> For this there is no solution. use uclibc && PROVIDE= is not valid and
> till such a time as PROVIDES understand uclibc? ( stuff ) syntax we
> can't really run with that gnuconfig-uclibc stuff. The gnuconfig package
> has however been updated in stable, so all instances will get the proper
> config.sub,guess
>
> For now we have to seriously forget about conditional provides ;/

This PROVIDE does not have to be conditional (as almost all the patches 
added now to ebuilds as use uclibc &&)

>
> > I can't accept an approach, to add use uclibc && gnuconfig_update to all
> > ebuild that are used w/ uclibc.
>
> Thats fine we can  do it via econf but we have to hook this with a
> FEATURE so it may be disabled for any case where a problem could arise.
> Something like this should do the trick and keep everything running
> smooth.
>
> if ! hasq noautoeconf $FEATURES ; then
>    [ -e /usr/share/gnuconfig/ -a -x /bin/basename ] && \
>      for x in $(find ${S} -name config.guess -o -name config.sub) ; do
>         cp /usr/share/gnuconfig/$(basename ${x}) ${x}
>      done
> fi

Ok for me if it defaults to update the files.

> > I have attached my "last bits" from the uclibc overlay directory, so
> > you'll see what I am using (these were already sent earlier)
> >
> > Another problem that will surely arise, the uclibc patches are not
> > everywhere in the newest releases, and also if they are there, some devs
> > are ignoring them, leaving them out (see openssl), so who will check for each
> > update, that someone didn't removed the known uclibc support from one
> > package. Most of the uclibc patches are not influencing the normal
> > functionality, so they could apply unconditionally, maybe if they won't
> > get use uclibc, they will mostly remain in, so the devs will try to
> > update/port them to newer versions.
>
> Then we need to get as many versions updated that we can so that uclibc
> carries onto each new future version of an .ebuild.
>
> > On a side note:
> > tar ~arch is faulty on uclibc (tar jtf does not work on the created tbz2
> > files), only the stable one (1.13.92-r3) works. How can it be done to use
> > exclusively this version for uclibc? Should this be done in the profile
> > enforcing some version?
>
> masked now in the profile using
> <app-arch/tar-1.13.25-r3

the condition is =1.13.92-r3 (not higher, not lower)

Peter



--
gentoo-embedded@g.o mailing list