Mon Dec 8 07:14:00 GMT 2014
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?
On Fri, Dec 5, 2014 at 3:16 PM, Bryan Hundven <email@example.com> wrote:
> On Fri, Dec 5, 2014 at 1:43 PM, Reinoud Koornstra
> <firstname.lastname@example.org> 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?
> 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
> 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.
>> For unsubscribe information see http://sourceware.org/lists.html#faq
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc