DragonFly kernel List (threaded) for 2009-07
Wishlist for unfrozen base
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.
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
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 ...