No.435
…on a 90MHz Agestar NAS
32MB RAM, 512MB swap, 2 weeks.
finished without a single hiccup
No.436
are you fucking installing gentoo on 470 years old computer?
dude, the purpose of compiling shit yourself for that specific computer is to make it run blazing fast.
why don't you install gentoo on a brand new system to really see how fast can it be?
No.440
No.441
Well, for starters it proved that Gentoo Linux is as stable as fuck. No mainstream OS would even boot with 32MB..
No.442
>>441I respectfully disagree.
Many i386 and i486 Slackware based distros that I've tried run on such fucking toasters, it's hilarious.
And they run with such speed and stability that trying to run Win95 on the same computer is just sad.
It crashes, it's slow, it's shit, while Slackware, Porteus, Slax and Salix just glide.
No.443
>>441>>442and just to add, for me Slackware IS a mainstream OS
No.454
You should try it on a TANDY next!
:^)
No.526
>>442At least gentoo has some sort of package manager with dependency resolution :^)
No.527
>>526that's not really good, huh
but if you want dependency resolution in slackware you can always use swaret or whatever that shit was called
No.528
OP is being a fag again.
I've got the Agestar up and going, and it's upgraden its gentoo agains.
…something like 288 packages need rebuilding.
No.529
>>52870 or so packages in, udev became an issue– the Agestar has a 2.6.29 kernel, but devtmpfs requires 2.6.34 at the earliest
…so mdev (from busybox) got enabled instead. See
https://gist.github.com/jirutka/9496300 No.557
OP here. Still going at it.
Most of the packages were rebuilt within the week, however now the task is the huge bits of code like glibc and gcc.
There's already gcc-4.1.4 and gcc-4.4.4 installed, but trying to build anything else has been a task. binutils needed replacing, and in the end that would only build without cxx.
Very available version of gcc in portage has been attempted, but they've all failed with illegal instruction errors. It's known that the STAR9104 CPU doesn't do ARM Thumb instructions, and I had -mno-thumb-interwork, but flag-o-matic.eclass was stripping that from STAGE1_CFLAGS and BOOT_CFLAGS. When SIGILLs happened during a SHA1 test, I'm now suspecting it might be an overheating CPU.
No.558
>>435>2 weeksI will never complain about bloatfox taking 20 minutes to compile again.
I'm kind of curious though,
why not just cross-compile everything on a more modern box? No.561
>>558Cross compiling is a bad thing to do you should make the realize on the same hardware ideally and if it doesn't work oh well just work on it better. Do it like how openbsd does it. No.562
No.564
>>558>why not just cross-compile everything on a more modern box?I've tried building a canadian-cross, and had more success with the native builds. And that's not even getting to the can-cross-emerge stage. All the 'recent' toolchains will forcefully assume an EABI world, which the FA526 can't do. ('HAI YOU REALLY WANT EABI HURR I'LL MAKE IT FOR YOU EVEN THOUGH YOU'RE EXPLICITLY TELLING ME NOT TOO11')
No.643
No.644
…and the Agestar has hence been returned to the storage from whence it came.
One of the foremost problems with the update was that ARMv4 got left behind when EABI (which requires thumb instructions) became the accepted standard in the ARM world– so things like GCC and Glibc depreciated full support for the ancient thumbless systems. About the latest version of GCC that would build was 4.4.4 … When I got stuck, there wasn't a non-eabi binary package to use.
Quite a few other packages had problems building due to random issues that weren't worthwhile to hunt down, so what I did was just attempt ebuild'merging /all/ their *.ebuild versions in order just to see what the newest one was that would install.
The Agestar uses a 2.6.29-patched Linux kernel, and its network was falling over for certain types of TCP traffic (ssh, rsync..) Again, I wasn't feeling motivated enough to heroically hunt down the bug, or upgrade the FA526 patches to a newer kernel.
No.645
No.771
>>435
>32MB RAM
>-pipe
>90Mhz
>-O2 instead of just -O
it's like you hate yourself
No.774
>>771
Dude, it's compiling a utility consisting of a single C file.
...but I actually did the update using good compiler options on the first pass, and kept going when something bombed. On following passes, the VTEC_FLAGS were rolled back.