mirror of
git://git.savannah.gnu.org/libtool.git
synced 2024-11-27 06:09:57 +08:00
106 lines
4.2 KiB
Plaintext
106 lines
4.2 KiB
Plaintext
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.
|