diff options
| -rw-r--r-- | README | 25 |
1 files changed, 25 insertions, 0 deletions
@@ -15,6 +15,31 @@ between packages, and is most noticeable in builds that invoke libtool a large number of times, and which are characterized by the short compilation time of individual translation units. +## why reimplement libtool? + +Midipix targets use the PE binary format and so require import library +integration on the one hand, yet follow ELF naming conventions +(i.e. libfoo.so.x.y.z) on the other. In consequence, midipix shared +libraries are not fully supported by existing libtool implementations. +As an interim solution used for the porting of gcc, a libtool script +generated by ltmain.sh was hand-edited so that it would correctly produce +the host's shared libraries as part of the toolchain build process. + +Bypassing the libtool script generated by a package's ltmain.sh requires +overriding the `LIBTOOL` variable as part of invoking `make(1)`. In that +sense, and unless midipix support is added to every single ltmain.sh in +every single package that uses autotools, it does not truly matter whether +the surrogate libtool that one chooses be a script, a program written in C, +or something else. + +At the time of this writing, an average libtool script consists of about +`10K lines of code` with `several hundred case-esac statements` and a similar +number of `if-then blocks`. In view of the length of the generated script, +and in light of its challenging logic and overall complexity, a rewrite of +the tool in C seemed to be the right choice not only with respect to quality, +readability, and anticipated performance, but also in terms of development +effort, ease of customization, and long-term maintenance. + ## Requirements for building slibtool - a C toolchain, consisting of... |