On Wed, Dec 17, 2003 at 01:19:47AM +0100, Thierry Godefroy wrote:
On Mon, 15 Dec 2003 23:37:44 +0100, Richard Zidlicky wrote:
Hi,
a short roundup of issues I am messing with:
!!! WARNING !!! Kernel 2.4.18 (probably anything 2.4.21)
will eat filesystems on disks137GB.
* chuckles * I didn't even figured out how to get this damned
atari_fdisk to properly enable and setup extended partitions,
so my 20Gb HD is pretty much underused already...
strange, that was not the slightest problem for me.. currently
there are 2x60GB disks under the hood. At least you dont have
to think about the 137 GB problem.
plenty of updated user packages and libs
gcc issues:
- libgcc_so in gcc3.3 is incompatible with previous versions
due to a change (a real improvement actually ;) in m68k exception
handling and version number wasnt bumped accordingly.. this makes
system upgrades not practical for average user.
No chance to install the two libraries in parallele ?
would work, but each approach has some drawbacks:
- different so-numbers, also different than the rest of the world,
forgetting to patch a new gcc release would result in problems.
I am not really sure if the version numbers could ever meet again.
- different libdir, different loadpath. Default ld.so cant do that
without help.. supposedly it is possible to hardcode ldpath into
the old binaries but I have never tried.
Even worse, having 2 versions of libgcc_so would probably mean
to keep 2 version of some other c++ libs.
So far I simply ignore the few hundred c++ programs that are broken
by the new libs in the hope to get them recompiled soon.
So a gcc v3.2 or 3.3 for the Q60 soon ? :-)
perhaps 3.4, the coreutils/sha1 problem turned out to be very
likely another 3.3.x bug.. one of those really nasty to debug
ones.
On an obscure sidetrack of development, I have a functional
but slightly buggy native ocaml compiler for m68k
(http://www.ocaml.org/).. needed a fast and reliable RAD
language to update the dated, slow and insecure cgi scripts
in the Q40 distribution.
RAD ?
rapid application development, buzzword but you get the idea.
It beats most other langauages when comparing lines of code
length while still beeing slightly more readable than APL or
perl.
Ocaml is also one of the few high level languages that can beat
the speed of compiled c on many tasks.
Richard
