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

[Ned Ludd]

Please test with this patch. If it works for you then I'll open a bug
and request the dev-portage@ team cvs commit it.

On Sat, 2004-06-26 at 18:21, Ned Ludd wrote:
> 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