Travis wrote: Why would you need any libs (regardless of gcc version) if it was a statically linked binary? I haven't touched the TTSynth but a few years ago worked on getting the tts part of viavoice working on newer versions of slackware and also on lfs. The problem is that when the tts was released, that statically built binary was built using the toolchain and runtime environment of the time, and at some point it stopped working for most people. You had the choice not upgrading your os (not a good choice!) or not having the tts, or trying to work around the problem. I forget the exact details but essentially glibc is tricky as far as distributions go, it is built as part of the toolchain since other stuff uses it, and the toolchain, that being the compiler, assembler, linker, binutils, etc, they work together in certain versions and they crash hard in others. You cannot take an old binutils and expect it to work with a newer gcc or glibc. I recall that on slackware I was able to get it working on newer versions using some additional binaries and creating some symbolic links, basically I copied over binaries from older version of slackware and added them with the necessary links so the tts could find and use them. LFS was a different story. I had to try building several different entire toolchains until I found one that worked. If you arbitrarily pick a combination of binutils, gcc, and glibc, odds are that you won't even get the toolchain built. It will fail in the compile somewhere because these are moving targets. It is actually quite a lot of work to get a stable toolchain built from source, even more so if you diverge from x86 into arm and other architectures. As I said, I forget the exact details, but don't forget that even if a binary is statically compiled, it's built to work with a runtime c library. At some point the old binary started crashing with unable to resolve symbol errors. If one wants to get ibm tts working on slackware or lfs they probably need to incorporate old runtime libraries that don't exist. With LFS in particular, the whole idea of the system is build it as you like it, so that's why I say you are on your own with that system. I often see how most software will have fedora or debian or whatever support or pre-compiled binaries, doubt you'll ever see them for LFS, it's not even reallt considered a distro, is it? On slackware, I'm used to having to do extra work because not many projects support slackware or have any slackware precompiled binaries. On the other hand I almost never add binaries, only build from source, so that never bugs me too much. It can be a challenge though, for example to get the latest vmware working on slackware you have to create a fake (empty) system v style init directory tree or the install will just fail. You also have to install pam and change a few things in the pam configuration that comes with vmware. I still like slackware and lfs because I can understand them. The other systems can be a bit mysterious at times, convenient when they work but not as easy to figure out when things break. > All linux distros can use statically linked binaries can't they? so > what's the problem? > unless static linked versions of said binary aren't possible to build > perhaps?
