DragonFly kernel List (threaded) for 2009-07
DragonFly BSD
DragonFly kernel List (threaded) for 2009-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Wishlist for unfrozen base


From: Hasso Tepper <hasso@xxxxxxxxx>
Date: Fri, 3 Jul 2009 12:42:46 +0300

Compilers and stuff
===================

* gcc 3.4 removal. There are two options - remove it entirely or just 
  disable it by default (it still might be potentially useful, for example 
  gcc34 in the pkgsrc will never support stack protection). Opinions?

* gcc 4.x update. gcc 4.1.2 we use at the moment is too buggy - to the 
  point where some projects ignore bugreports at all if gcc-4.1.x is in 
  use (ffmpeg for example). We should decide what path to choose at all 
  with it though. There is several issues with newer gcc's - there is a 
  license issue (newer ones at some point use GPLv3) and gcc 4.3 and up 
  have a more dependencies (do we want all these in the base?).

  If we decide that GPLv3 in the base isn't OK for us, then we can choose 
  FreeBSD path - the latest 4.2.x with GPLv2 and some patches. If we 
  decide that GPLv3 is OK for toolchain at least (fyi, regardless of this 
  decision I don't like having (L)GPLv3 libraries in the base), we still 
  have to decide whether it's OK to pull in GMP and MPFR libraries (needed 
  for 4.3 and up).

  Note that I'm aware of BSD licensed alternatives (pcc and clang) we 
  might have soon, but these are not there for now. Maybe in 2011 ... 

* binutils update. The very same license issue potentially exists (2.18 
  and up are under GPLv3), but it would allow to use many performance 
  improvements introduced in newer versions.


Threading stuff
===============

Corecode expressed his view that we shouldn't get rid of libc_r entirely - 
it's actually good potential testcase and I tend to agree with him. But 
we should do two things IMHO:

* move both libc_r.so and libthread_xu.so out from /usr/lib so no app has 
  a chance to link against these directly (yes, corecode, I think now 
  it's a good idea ;)

* introduce stubs for stuff not in libc_r - barriers, spinlocks and some 
  more


Of course I'd like to see this happening ASAP. All this might introduce 
problems which take time to discover and fix.

There are also smaller items in the wishlist like updating ncurses and gdb 
(hint! ;P), but ... Yeah, I want a pony as well ...


-- 
Hasso Tepper



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]