1. For this older version(that came from Slackware10.2), binutils on sparc32 and sparc64 does not support TLS well. Therefore, no NPTL support, and no "__thread support" from gcc. The glibc package is still built as if that support exists and will therefore contain extra files. There's not a whole lot anyone can do about it. Apparently, around the time this was originally released on x86, binutils was having TLS support for sparc32 debugged, as well as TLS support for sparc64 added. 2. coreutils are built with POSIX2_VERSION=200112 This is *not* apparently how original Slackware10.2 coreutils were built. POSIX2_VERSION=200112 causes problems during build of "compress" in the bin package, so the bin package has some patches to take care of that. (Specifically, "head -2" is old syntax while "head -n2" is new/correct now.) If you want older posix semantics for coreutils, alter the build recipe by adding "DEFAULT_POSIX2_VERSION=199209" to the ./configure line. further note: I rebuilt with the older posix settings. The newer settings just broke too many things. 3. tcpip package has a failure during build of "netkit-ntalk-0.11". talkd fails to build, but does not cause a bad package to be built, since that version is only included for the *client*. The server comes from 0.17, so the resultant package is fine. 4. cfdisk, sfdisk, and rdev from util-linux are not built. It seems that the maintainers of util-linux have decided that cfdisk and sfdisk should not build on sparc, and that rdev only builds on intel. Also, you really shouldn't have a need for rdev. A bootloader like SILO can take care of the need to select boot device, just as GRUB or LILO would on x86. I don't have any idea what the option to set videomode might even mean on a sparc. 5. gdbserver is not supported on sparc platforms currently 6. rpm. wow. debugedit will not build as slack does not apparently have elfutils... 7. svgalib is not built. I started to get this working and I've decided that it is too much trouble for the results. There's a LOT of ISA-bus specific whacking around in there and while there may be cards in supported list that might be PCI and workable on sparc, there is a *much* newer version of svgalib that even the real Slackware does not use. One result of this is that svgalib support is removed from netpbm. seejpeg is also therefore not built. 8. php was built against an earlier version of libxml2. php as built from the build recipe from Slackware 10.2 has --enable-wddx, which shipped with the version that ships with 10.2 (libxml2-2.6.21) has symbols in an enum that conflict with some from expat. The version of libxml2 from 10.1(2.6.16) does not contain those types. 9. Apparently, ALSA is not for 2.4.x series sparc kernels... so no alsa-lib. Therefore, I am not sure that there is any value in having alsa-lib or alsa-oss, as there isn't much of an alsa device for either one to talk to. 10. Java. The JRE from this era of Slack is x86 only. There exists source for the 1.5.x JDK, but it requires doing all sorts of things if you wish to distribute. During the 11.x era there will hopefully be Java that is truly free-software. This affects kdebindings, among other things. 11. oprofile does not support the sparc architecture and is therfore not built. 12. aaa_elflibs is going to be missing "libcurl.so.2.0.2". I haven't built anything against that library and I think it unwise to waste the time building an older version of libcurl. Same goes for "libgdbm.so.2.0.0". "libvga.so.1.4.3" and "libvgagl.so.1.4.3" are missing because svgalib wasn't built for sparc. 13. syslinux is not built. A bootloader for FAT filesystems doesn't make sense on sparc. 14. The busybox in mkinitrd does not have kernel module support because that's not supported on sparc. 15. There is no diethotplug for the boot/install iso. The dietlibc-derived klibc needed for diethotplug, has functionality missing for sparc. If you understand linux-sparc assembly, please let me know. 16. The build for xchat completes without error. It runs, but bus errors shortly after connecting to a channel. My suspicion is an unaligned structure member somewhere. I haven't really gotten that deep into it yet. I don't want it to hold things up, so I am releasing as is in the hope that someone else may also take a look at it. 17. This item lists for both firefox and thunderbird. 17a. firefox is not built with official branding. Firefox on linux-sparc is not currently even a tier-3 platform. Once we reach a more current version, we can perform more indepth smoketests and make the request to obtain permission for --enable-official-branding. 17b. firefox needs to be launched once as root to create the extensions store to eliminate a waning upon startup. This should be corrected in further releases. 17c. firefox has improperly set processor optimization options. Building on other platforms may result in binaries unable to run on some machines. 17d. thunderbird is not built. My theory is that, due to its age, the build process is different. 17e. 17b, c, and d should hopefully be cleared up during patching. The version shipped with 10.2 is extremely old and in general should not now be used on the internet at large. 18. usmdos-progs is not built. In theory it could work. In practice... a. umsdos is unlikely to be used under sparc. b. Some of the build process is x86 specific. c. It's built against kernel headers, but isn't distributed with the kernel. d. The last build was *really* old (kernel 2.2.x) and not automated as it should have been. 19. apmd does not have apmsleep built. apmsleep uses the PC RTC as an ISA device. 20. speakup is not supported. This is a niche platform and I doubt anyone is using it. I also have no way of testing any of the hardware synthesizers. Please let me know if I am wrong. notes: 1. rpm has apparently changed since sgml-tools was first built. rpm now halts with an error if there are "installed (but unpackaged)" files found. Sigh... and they didn't include a commandline option to ignore that and package those files anyways... or maybe even just totally ignore those extra "installed" files and create a package anyways. 2. For some incomprehensible reason, one of the docbook-utils packages that needs to be built for sgml-tools *requires* the file "COPYING" from /usr/share/automake. For whatever reason, I didn't have that path, so I just dropped a symlink in there to automake-1.9. 3. rpm has a problem with files that don't have valid UID's. "chown root *" after unpacking each source package, before building the rpms will fix that. 4. Many packages released as part of Slackware10.2 cannot actually be built with Slackware10.2 due to compiler/library changes/fixes. Openjade is one of them. Bug 742608 is something that needs to be taken into account when building this. See one of the patches I added to the sgml-tools build recipe for details. 5. rpm sucks. sgml-tools sucks. Someone was too clever by far, and it seems almost impossible to build the docbook-utils-0.6.14-2 package the same way that docbook-utils-0.6-13 was built. Recommendation: build the rpm, install it, then use the partial build -bi option to grab the missing html documentation files. 6. Ok. What retard on the rpm developer team decided that --short-circuit was not going to be valid on -bb? Seriously. I can single-step through the entire build process. I can make corrections at each step along the way, but then finally I am unable to simply package the result? This has cost me a LOT of time and aggravation in service to a totally unnecessary need to making an absolutely perfect spec file for a package that will probably never be built this way again. 7. kdevelop wants dot/graphviz. The kdevelop might be better with the "new graphical classbrowser"... 8. kdelibs probably should have "make apidox" added. 9. xpaint had an error duing imake. I compared to the original x86 package, and it seems to be unaffected. 10. xfractint is built and works. It seems to have stability issues. I don't know if this is due to my patching, as others have reported its relative instability to the original fractint. 11. gnu-gs-fonts. Just as the original Splack did, I am going to use this package unchanged. It is not a binary, so it should hurt nothing. 12. Building the kernel(2.4.x): There are two things that *must* be done cleanly, otherwise you will get oddly broken builds. #1. A clean config file. You may have a config file from x86-land that you have been shepherding along for many versions. Don't bother trying to use it on sparc. "make dep" may succeed, but some of the CONFIG_whatever options will confuse the build eventually. #2. A clean "make dep". If you ever use a tree for building more that one kernel, or you build a kernel, then remove feature(s), be aware that "make clean" will not always sufficiently clean the tree to get a good build. Try saving your kernel config elsewhere, then "make mrproper", then copy your config back in, then do one of the "make config"s (I do make menuconfig) to get the correct asm smylink, and only then will your kernel be ready for a make dep.