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

[Ned Ludd]

On Sat, 2004-06-26 at 02:53, Peter S. Mazinger wrote:
> On 25 Jun 2004, Ned Ludd wrote:
>
> > On Fri, 2004-06-25 at 09:27, Peter S. Mazinger wrote:
> > > Hello!
> > >
> > > some corrections and/or missing changes for uclibc support
> >
> > tar updated
> > perl updated
> > openssl updated
> >
> > binutils-2.15.91.0.1-r2 -
> > binutils - 2.14.90.0.8-r2
> >
> > This type of logic is not desired.
> > use uclibc && rm -f ${WORKDIR}/patch/*relro* && rm -rf
> > ${WORKDIR}/patch/*sparc1* || die
> >
> > Can you rewrite this one and repost it with 'if ; then ; else ; fi'
>
> I do not know what is not ok with my logic, so please change it as you
> please
> Now there are numbers that are used, I do not like it, because I want to
> know what I remove (in this case all the relro related patches, and a
> patch for sparc that could be ported)
>
> > gcc-3.4.0-r6 - I'll run this by somebody that works on 3.4.x
> > db-4.1.25_p1-r4 - I'll do this one in a few mins
> > catalyst-1.0.7 - Only zhen/releng can make cvs commits on this one.
>
> catalyst is not so important for now, because none of you gave me an idea
> how to produce a stage1/2/3 from tbz2 files, so I can't test stage building.
>
> >
> > Now assuming we get all the updates in where does this put us in your
> > minds eye?
> > I've got people asking me about uclibc by the boatload now.
>
> Due to the fact that not all patches were "accepted" you are missing
> following to really build an uclibc based system starting from buildroot +
> portage manually installed:
>
> config.sub/config.guess is updated by me all the time by econf, only
> those ebuilds got addition use uclibc && gnuconfig_update, that do not run
> econf, only use directly ./configure (the most of them should be corrected
> to use econf, but I wanted to hold my diffs at minimum, so that they are
> acceptable). There are also about 5-6 different versions of these files
> on the system, libtool and automakes, gnuconfig are delivering them, I
> have done patches for this, to use only one, but haven't seen them
> accepted (see my first patch related to gnuconfig-uclibc), If you do not
> remove all the diff. versions and use a "well known" one, updating lets
> say libtool brings a newer config.guess, but this one was forgotten to be
> patched for uclibc.


> After this step you can't build any libs for sure for
> uclibc (that's why I wanted the provide gnuconfig-uclibc, to be really
> sure about uclibc proper version)

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 ;/

> 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


> 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
 
> Peter
>
> ______________________________________________________________________
> --
> gentoo-embedded@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer