TTSynth Is Available Again

[Doug Sutherland]

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?