* Work out what to do when the dynamic linker loads needed dependencies.
* We could have an option to hardcode paths into libraries, as well as
- binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not
+ binaries: '... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not
possible on all platforms, and is in part obviated by the ability of
linking libtool libraries specified with -lname, but it might still
be desirable.
most packages that use pkg-config also use libtool, I think this
would be a good way to reduce maintainer and developer dependencies.
-* Have libtoolize install `install-sh' if a newer version is available,
+* Have libtoolize install 'install-sh' if a newer version is available,
and/or Automake is not used.
* Allow to specify linking some dependent libraries statically and some
* Fix -dlopen "self" on AIX. Reported by Gary Kumfert <kumfert@llnl.gov>.
-* Fix denial of service if using installed `libtool' on a different mount point
- together with a compiler which does not understand `-c -o'.
+* Fix denial of service if using installed 'libtool' on a different mount point
+ together with a compiler that does not understand '-c -o'.
Reported by Marcin Siennicki.
* Look at better -no-undefined support, maybe along the idea of
* Fix the following bugs in libltdl:
- error reporting of tryall_dlopen():
if the file actually doesn't exist (stat() fails or it wasn't dlpreopened)
- -> report `file not found'
+ -> report 'file not found'
if it cannot be loaded (e.g. due to missing dependencies)
-> report dlerror
- open question: which error should be reported if all dlloaders fail
+ open question: what error should be reported if all dlloaders fail
or if a specific module type can only be loaded by one of them, how report its dlerror?
Also report dlerror() for dlclose and dlsym if available
- Make sure that the dependency_libs of a dlpreopened module won't be loaded.
------------------
* Need to finalize the documentation, and give a specification of
- `.la' files so that people can depend on their format. This would be
+ '.la' files so that people can depend on their format. This would be
a good thing to put before the maintainance notes.
-* Document the installed `libtool' and its limitations clearly (maybe implement
+* Document the installed 'libtool' and its limitations clearly (maybe implement
--disable-script-install as well). Or, even better, remove its limitations.
* Platform notes redo.
static libraries, we should probably create a .al out of .lo objects
and also a .a out of .o objects. The .al would only be used to create
shared libraries, whereas the .a would be used for creating static
- libraries and programs. We could also explicitly support `empty'
+ libraries and programs. We could also explicitly support 'empty'
convenience libraries, that behave as macros that expand to a set of
-Rs, -Ls and -ls switches.
-* Audit use of object names so we can allow `$' not only within
+* Audit use of object names so we can allow '$' not only within
source file names. Necessary especially for java.
* We could introduce a mechanism to allow for soname rewriting, to
* Audit the GCJ tag section in libtool.m4.
-* Add caching mechanism. Look at `libtool-cache' from Robert Ögren.
+* Add caching mechanism. Look at 'libtool-cache' from Robert Ögren.
2.4. libtool autoconf macros
* The definitions for LT_SYS_MODULE_EXT, LT_SYS_MODULE_PATH and
LT_SYS_DLSEARCH_PATH should not rely on the _LT_SYS_DYNAMIC_LINKER
- macro. This involves moving the code which sets the variables
+ macro. This involves moving the code that sets the variables
library_names_spec, shlibpath_var and sys_lib_dlsearch_path_spec from
into a separate macro, and AC_REQUIRING the newly extracted macro in the
respective ltdl.m4 macros.
* Arrange that EXEEXT suffixes are stripped from wrapper script names
only when needed, and that a timestamp file or a wrapper program is
- created with the EXEEXT suffix, so that `make' doesn't build it every
+ created with the EXEEXT suffix, so that 'make' doesn't build it every
time.
* Figure out how to use data items in dlls with win32.
- The difficult part is compiling each object which will be linked with an
+ The difficult part is compiling each object that will be linked with an
import lib differently than if it will be linked with a static lib. This
will almost definitely require that automake pass some hints about linkage
in to each object compilation line.
it easier to add new platforms.
--
- Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2004-2005, 2007-2008, 2011-2019, 2021-2022 Free Software
+ Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Libtool.
projects / platform / upstream / libtool.git / blobdiff