This is a somewhat negative “progress” report.
I decided that the 2.6.24-rc4 kernel is too immature, so I rolled
back to the 18.104.22.168 kernel. I compiled it with basically the same
configuration, including SMP and libata handling of IDE drives. This
time I also compiled a whole heap of third-party modules:
536, 537, ltmodem, pctel, slmodem, ungrab-winmodem.
Unfortunately, ess v0.3 does not compile.
acx, madwifi, iwlwifi, rt61, rt73, rt2400, rt2500, rt2570, ndiswrapper.
I wanted to compile just the USB module out of linux-wlan-ng but it would not compile.
Now for the negative news…
Running a full install with this new kernel, I connected to the
Internet using my usual DHCP, and that works, I am running it right
now. Unfortunately, it causes Rox windows to have a delay of about 4-5
seconds before appearing and SeaMonkey takes about 15 seconds to start.
If I do ‘ifconfig eth0 down’ or kill dhcpcd, these apps revert to their
normal fast startup (virtually instantaneous for Rox).
I’m just about to see if there’s a later version of ‘dhcpcd’ and try that…
This one really cheeses me off. I tried to compile RutilT and got
the message that ‘__sync_fetch_and_add_4′ function is missing at the
final link step.
I have already mentioned this problem, it affects a lot of packages.
They can be compiled inside T2, but not in Puppy. I asked Rene, the
main T2 developer, and he kind of confirmed the cause of the problem,
but I still have no solution.
Note, I’m not the only one with this problem, as a quick google
reveals. The problem is in gcc/libstdc++ and is something to do with
gcc thinking that the host CPU is a i386, and it then tries to link-in
a non-existent function. I found a discussion thread back in 2006 where
the gcc developers were discussing this bug, and the sentiment
expressed was that this bug should simply not be allowed to occur, and
they were looking at various patches.
Anyway, here we are at December 2007, with gcc version 4.2.2 and I’m
stuck with this show-stopper bug. For packages that exhibit this
problem, I have tried injecting ‘-march=i486′ or ‘-mcpu=i486′ as a C
flag, which is a solution suggested at various places on the Internet,
but no good.
So, I’m just about to approach the gcc developers directly…