Re: uclibc patches

[Reinoud Koornstra <reinoudkoornstra at gmail dot com>]

Hi Bryan,

Even though uclibc hasn't had branch updates for a long time, it's
still alive and kicking.
Patches and additional functionalities go into the upstream git version.
Would it make sense to use the git version or a daily snapshot, just
because of the patches that are in?
Thanks,

Reinoud.


On Fri, Dec 5, 2014 at 3:16 PM, Bryan Hundven <bryanhundven@gmail.com> wrote:
> 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