From cf5ea49a2e7a8a9fb9d06b44c49ff4a11875e2ca Mon Sep 17 00:00:00 2001 From: "Gary V. Vaughan" Date: Sat, 16 Mar 2002 18:50:43 +0000 Subject: [PATCH] * TODO: Removed obsolete comments about RMS' package system. --- ChangeLog | 4 ++++ TODO | 15 ++++----------- 2 files changed, 8 insertions(+), 11 deletions(-) diff --git a/ChangeLog b/ChangeLog index ebebecf73..5dcb39c83 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2002-03-16 Gary V. Vaughan + + * TODO: Removed obsolete comments about RMS' package system. + 2002-03-07 Albert Chin-A-Young * libtool.m4: Allow LT_AC_PROG_SED to work under autoconf diff --git a/TODO b/TODO index aed518aea..2a3072e03 100644 --- a/TODO +++ b/TODO @@ -7,7 +7,7 @@ In the near future: * Fix the following bugs in libltdl: - Report dlerror() for dlclose and dlsym if available - Make sure that the dependency_libs of a dlpreopened module won't be loaded. - + * Check whether the version of libtool.m4 is compatible with ltconfig/ltmain.sh. Meanwhile, the recommended approach for developers using automake is to insert libtool.m4 in acinclude.m4. @@ -55,8 +55,8 @@ respective ltdl.m4 macros. * Godmar Back writes: libltdl uses such stdio functions as fopen, fgets, feof, fclose, and others. - These functions are not async-signal-safe. While this does not make - libltdl unusable, it restricts its usefulness and puts an + These functions are not async-signal-safe. While this does not make + libltdl unusable, it restricts its usefulness and puts an unnecessary burden on the user. As a remedy, I'd recommend to replace those functions with functions @@ -66,7 +66,7 @@ respective ltdl.m4 macros. out from which you can steal the latter. I believe relying on async-signal-safe functions to the greatest extent - possible would greatly improve libltdl's ability to be embedded in and + possible would greatly improve libltdl's ability to be embedded in and used by other systems. * Arrange that EXEEXT suffixes are stripped from wrapper script names @@ -146,13 +146,6 @@ properly with AC_CONFIG_AUX_DIR using projects. Things to think about: ********************** -* 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. -- 2.47.2