Re: uclibc patches

[Bryan Hundven <bryanhundven at gmail dot com>]

Reinoud

On Fri, Dec 5, 2014 at 1:43 PM, Reinoud Koornstra
<reinoudkoornstra@gmail.com> wrote:
> Hi Everyone,
>
> Is it possible to merge the patches from buildroot for uclibc in?
> The have 65 patches for it and we could use them too.
> Any thoughts about this?
> Thanks,

There are two points of view on this topic, and it kinda goes the same
for other components like gcc, binutils, glibc, musl-libc, newlib,
gdb, etc...

The first is: Crosstool-NG is designed to create reproducible
toolchains. Meaning that I should be able to go to a previous branch
of crosstool-ng where I made an older toolchain, and it should still
work (although older branches have lacked maintenance) to build the
toolchain I built before. Toolchains you've built with 1.20.0 should
continue to work after we cut 1.20.1 or 1.21.0 (which will happen
sooner now). But these builds only use released source code. Say gcc
4.9.1 or 4.9.2. It would not be true for pre-released 4.9.3 or current
development versions of gcc 5.0.

The second is that a lot of these projects do "branch updates". Take
gcc for instance. Even after 4.9.2 was released, there are many
updates to the 4.9 branch
(https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gcc-4_9-branch)
that add bugfixes, where as the mainline development is happening in
the master branch for the 5.0 release which contains new features and
bug fixes.

Other projects like uClibc have not made releases in a very long time,
and live in that "Branch Update"/"Snapshot" state. In the past I had
sent patches and urged Yann to add support for "Branch
Update"/"Snapshot" support, and my efforts were rejected for the
reasons of the first point of view I listed above. I can't use a
git/svn tag to base the version of uClibc was based on for the
toolchain build, because tags are "movable objects". Meaning, if I
used HEAD... HEAD is always the latest. uClibc also hasn't made any
other tags then releases, so there is nothing else to reference
besides actual commits.

I've mentioned before that I don't like the idea of keeping a large
stack of patches for branch updates and fixes from upstream, when we
should just be pulling whatever upstream produces.

So with that, I feel that uClibc should be the first in-line to get
"Snapshot" support. How we handle that is another story or RFC on how
we keep track of commits used to create a toolchain and how we track
that to reproduce that toolchain in the future.

Lets keep this conversation open and have a community conversation
around this. I'd like to hear what others think.

Cheers,

-Bryan


> Reinoud.
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq