| For next public release: |
| ************************ |
| |
| * Create a new library version_type, `irix'. Janos Farkas writes: |
| |
| I just realized I also have mortal access to an SGI system, and found |
| this in the dso.5 page, this looks more informative :) |
| |
| Versioning of Shared Objects. |
| |
| QUICK OVERVIEW |
| |
| For a shared object to be versioned the following needs to be done: |
| |
| * Version strings consist of 3 parts and a dot: The string "sgi", |
| a decimal number (the major number), a dot, and a decimal number |
| (the minor number). |
| |
| * Add the command -set_version sgi1.0 to the command to build |
| the shared object (cc -shared, ld -shared, etc.). |
| |
| * Whenever you make a COMPATIBLE change update the minor version |
| number (the one after the dot), and add the latest version string |
| to colon-separated list of version strings, e.g., -set_version |
| sgi1.0:sgi1.1:sgi1.3 |
| |
| * Whenever you make an INCOMPATIBLE change, update the |
| major version number. Pass this as the version list, e.g., |
| -set_version sgi2.0. Change the filename of the OLD shared object |
| by adding a dot followed by the previous major number to the filename |
| of the shared object. DO NOT CHANGE the soname of the object. |
| No change to the file contents are necessary or desirable. Simply |
| rename the file. |
| |
| * Inter-library dependencies should be fully tracked by libtool. |
| Reminded by Alexandre Oliva. This requires looking up installed |
| libtool libraries for transparent support. |
| |
| * Alexandre Oliva suggests that we hardcode paths into libraries, as |
| well as binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. Tim |
| Mooney wants the same thing. |
| |
| * Tom Lane adds that HP-UX's linker, at least (I've also found this on |
| AIX 4), distinguishes between global function and global variable |
| references. This means that we cannot declare every symbol as `extern |
| char'. Find a workaround. |
| |
| In the future: |
| ************** |
| |
| * If not cross-compiling, have the static flag test run the resulting |
| binary to make sure everything works. |
| |
| * Implement full multi-language support. Currently, this is only for |
| C++, but there are beginnings of this in the manual (Other Languages). |
| This includes writing libtool not to be so dependent on the compiler |
| used to configure it. |
| |
| We especially need this for C++ linking, for which libtool currently |
| does not handle static constructors properly, even on operating |
| systems that support them. ``Don't use static constructors'' is no |
| longer a satisfactory answer. |
| |
| People who need it: |
| Jean Daniel Fekete <Jean-Daniel.Fekete@emn.fr> |
| Thomas Hiller <hiller@tu-harburg.d400.de> |
| |
| * Another form of convenience library, suggested by Alexandre Oliva, |
| is to have undocumented utility libraries, where only the shared |
| version is installed. |
| |
| * We could use libtool object convenience libraries that resolve |
| symbols to be included in a libtool archive. This would require some |
| sort of -whole-archive option, as well. |
| |
| * Somehow we need to make sure that static libraries never appear in |
| $deplibs. This, will probably require that libtool discover exactly |
| which files would be linked from which directories when somebody says |
| `-lsomething'. This adds a lot of complexity, but I see no other way |
| around it. |
| |
| * Need to finalize the documentation, and give a specification of |
| `.la' files so that people can depend on their format. This also |
| needs to be done so that DLD uses a public interface to libtool |
| archives. This would be a good thing to put before the maintainance |
| notes. |
| |
| Things to think about: |
| ********************** |
| |
| * For OSes with symbol export lists, we should add some flags to allow |
| packages to specify explicit lists, or to bypass them entirely. |
| Automatic-generation using nm must be the default, since that is |
| simplest. |
| |
| * Talk with RMS about his so-called `automatic package generation |
| tool.' This is probably what Thomas has been murmuring about for the |
| Hurd. We'll need to integrate package-supplied programs such as |
| libtool into that scheme, since it manages some of the preinstall and |
| postinstall commands, but isn't installed itself. Probably, things |
| like libtool should be distributed as part of such a binary package. |
| |
| * Maybe implement full support for other orthogonal library types |
| (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc). Make these types |
| configurable. |
