uclibc patches

uclibc patches

[Reinoud Koornstra]

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,

Reinoud.

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

Re: uclibc patches

[Bryan Hundven]

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

Re: uclibc patches

[Reinoud Koornstra]

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