Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] The uClibc saga: next steps
@ 2014-04-30 10:48 Thomas De Schampheleire
  2014-04-30 14:50 ` Thomas Petazzoni
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas De Schampheleire @ 2014-04-30 10:48 UTC (permalink / raw)
  To: buildroot

All,

At the last buildroot developer days, we discussed the uClibc
situation at length [1]. We finally decided to try, once more, to take
it up with the uClibc community, requesting them to make a release. We
told them that we are considering to stop using uClibc as the default
C library in Buildroot.

Unfortunately, this approach failed to work, as did previous attempts.
The discussion on the uClibc mailing list is at [2].

Hence, I think it is time to discuss the next steps, which could possibly be:
- create a 'fork' of uClibc that just makes releases out of the
existing code in the uClibc sources.
- go forward with the plan to stop using uClibc as default C library,
and either promote musl or (e)glibc.
- (other possible steps here...)

What do you think?

Best regards,
Thomas


[1] http://elinux.org/Buildroot:DeveloperDaysFOSDEM2014#How_to_handle_the_uClibc_problem

[2] http://lists.uclibc.org/pipermail/uclibc/2014-February/048252.html
http://lists.uclibc.org/pipermail/uclibc/2014-March/048269.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Buildroot] The uClibc saga: next steps
  2014-04-30 10:48 [Buildroot] The uClibc saga: next steps Thomas De Schampheleire
@ 2014-04-30 14:50 ` Thomas Petazzoni
  0 siblings, 0 replies; 2+ messages in thread
From: Thomas Petazzoni @ 2014-04-30 14:50 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Wed, 30 Apr 2014 12:48:10 +0200, Thomas De Schampheleire wrote:

> Unfortunately, this approach failed to work, as did previous attempts.
> The discussion on the uClibc mailing list is at [2].
> 
> Hence, I think it is time to discuss the next steps, which could possibly be:
> - create a 'fork' of uClibc that just makes releases out of the
> existing code in the uClibc sources.
> - go forward with the plan to stop using uClibc as default C library,
> and either promote musl or (e)glibc.
> - (other possible steps here...)
> 
> What do you think?

I met Khem Raj yesterday at ELC, and we spent a good amount of time
discussing the uClibc status. He is in contact with Bernhard, the
official maintainer, and tries to get things moving. Hopefully, we
should see something changing in the next few months.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-04-30 14:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-30 10:48 [Buildroot] The uClibc saga: next steps Thomas De Schampheleire
2014-04-30 14:50 ` Thomas Petazzoni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox