libtool ChangeLog HACKING
CVSROOT:/sources/libtool Module name:libtool Changes by: Gary V. Vaughan gary 07/03/28 16:52:26 Modified files: . : ChangeLog HACKING Log message: * HACKING (Abstraction layers in libltdl): Rewritten somewhat for (hopefully) better clarity. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2439r2=1.2440 http://cvs.savannah.gnu.org/viewcvs/libtool/HACKING?cvsroot=libtoolr1=1.37r2=1.38 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
327-gary-clarify-libltdl-api-docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Whilst becoming reacquainted with the guts of libltdl in order to work on release blockers, I found myself rewriting this part of the HACKING file. Okay to commit to HEAD? Index: ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * HACKING (Abstraction layers in libltdl): Rewritten somewhat for (hopefully) better clarity. Index: HACKING === RCS file: /sources/libtool/libtool/HACKING,v retrieving revision 1.37 diff -u -u -r1.37 HACKING --- HACKING 25 Mar 2007 21:09:42 - 1.37 +++ HACKING 28 Mar 2007 11:53:23 - @@ -287,84 +287,99 @@ * The libltdl API uses a layered approach to differentiate internal and external interfaces, among other things. To keep the abstraction consistent, files in a given layer may only use APIs from files in the - lower layers. The exception to this is lt__glibc.h which serves a - dual purpose, as explained later. + lower layers. The ASCII art boxes below represent this stack, from + top to bottom... -* At the bottom of the stack we have the system abstraction layer, - which tries to smooth over the cracks where there are differences - between host systems and compilers. config.h is generated at - configure time and is not installed; lt_system.h is an installed - file and cannot use macros from config.h: +* But first, outside of the stack, there is a convenience header that + defines the internal interfaces (as evidenced by the `lt__' prefix to + the filename!) shared between implementation files in the stack, that + are however not exported to libltdl clients: + + ,-. + |lt__private.h| + `-' + +* The top layer of the stack is the libltdl API proper, which includes + the relevant subsystems automatically. Clients of libltdl need only + invoke: - lt_system.h ../config.h + #include ltdl.h + + ,--. + |ltdl.h| + +--+ + |ltdl.c| + `--' -* Next up is the libc abstraction layer, which provides a uniform api - to various system libc interfaces that differ between hosts supported - by libtool. Typically, the files that implement this layer begin: - - #if defined(LT_CONFIG_H) - # include LT_CONFIG_H - #else - # include config.h - #endif - #include lt_system.h +* The next layer is comprised of the subsystems of the exported libltdl + API, which are implemented by files that are named with a leading `lt_' + (single underscore!): + + ,v---. + | lt_error.h | lt_dlloader.h | + ++---+ + | lt_error.c | lt_dlloader.c | + `^---' + +* The next file is used both by the headers that implement it (in which + case its function is to avoid namespace clashes when linking with the + GNU C library proper) and is included by code that wants to program + against a glibc like interface, in which case it serves to pull in all + the glibc-like functionality used by libltdl with a simple: + +#include libltdl/lt__glibc.h + + It consists of a single file: + + ,---. + |lt__glibc.h| + `---' + +* Next to last is the libc abstraction layer, which provides a uniform + api to various system libc interfaces that differ between hosts + supported by libtool. Typically, the files that implement this layer + begin: + +#if defined(LT_CONFIG_H) +# include LT_CONFIG_H +#else +# include config.h +#endif +#include lt_system.h Or if they are installed headers that must work outside the libtool source tree, simply: - #include libltdl/lt_system.h +#include libltdl/lt_system.h This layer's interface is defined by files that are usually named with a leading `lt__': - ,. ,---. ,--.,---. - |lt__dirent.h| |lt__alloc.h| |argz.h||slist.h| - ++ +---+ +--++---+ - |lt__dirent.c| |lt__alloc.c| |argz.c||slist.c| - `' `---' `--'`---' - - The exceptions here are argz.h and slist.h which are used - independently of libltdl in other projects. - -* There is also a sub-layer that can be used either by the headers that - implement it, in which case its function is to avoid namespace clashes - when linked with the GNU C library; Or it can be included by code that - wants to program against a glibc like interface, where it also serves - the function of pulling in all the glibc-like functionality used by - libltdl from a single: - - #include libltdl/lt__glibc.h - - It consists of the single file: - - lt__glibc.h -
FYI: 327-gary-clarify-libltdl-api-docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Applied to HEAD. Index: ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * HACKING (Abstraction layers in libltdl): Rewritten somewhat for (hopefully) better clarity. Index: HACKING === RCS file: /sources/libtool/libtool/HACKING,v retrieving revision 1.37 diff -u -u -r1.37 HACKING --- HACKING 25 Mar 2007 21:09:42 - 1.37 +++ HACKING 28 Mar 2007 16:52:04 - @@ -287,84 +287,99 @@ * The libltdl API uses a layered approach to differentiate internal and external interfaces, among other things. To keep the abstraction consistent, files in a given layer may only use APIs from files in the - lower layers. The exception to this is lt__glibc.h which serves a - dual purpose, as explained later. + lower layers. The ASCII art boxes below represent this stack, from + top to bottom... -* At the bottom of the stack we have the system abstraction layer, - which tries to smooth over the cracks where there are differences - between host systems and compilers. config.h is generated at - configure time and is not installed; lt_system.h is an installed - file and cannot use macros from config.h: +* But first, outside of the stack, there is a convenience header that + defines the internal interfaces (as evidenced by the `lt__' prefix to + the filename!) shared between implementation files in the stack, that + are however not exported to libltdl clients: + + ,-. + |lt__private.h| + `-' + +* The top layer of the stack is the libltdl API proper, which includes + the relevant subsystems automatically. Clients of libltdl need only + invoke: - lt_system.h ../config.h + #include ltdl.h + + ,--. + |ltdl.h| + +--+ + |ltdl.c| + `--' -* Next up is the libc abstraction layer, which provides a uniform api - to various system libc interfaces that differ between hosts supported - by libtool. Typically, the files that implement this layer begin: - - #if defined(LT_CONFIG_H) - # include LT_CONFIG_H - #else - # include config.h - #endif - #include lt_system.h +* The next layer is comprised of the subsystems of the exported libltdl + API, which are implemented by files that are named with a leading `lt_' + (single underscore!): + + ,v---. + | lt_error.h | lt_dlloader.h | + ++---+ + | lt_error.c | lt_dlloader.c | + `^---' + +* The next file is used both by the headers that implement it (in which + case its function is to avoid namespace clashes when linking with the + GNU C library proper) and is included by code that wants to program + against a glibc-like interface, in which case it serves to pull in all + the glibc-like functionality used by libltdl with a simple: + +#include libltdl/lt__glibc.h + + It consists of a single file: + + ,---. + |lt__glibc.h| + `---' + +* Next to last is the libc abstraction layer, which provides a uniform + API to various system libc interfaces that differ between hosts + supported by libtool. Typically, the files that implement this layer + begin: + +#if defined(LT_CONFIG_H) +# include LT_CONFIG_H +#else +# include config.h +#endif +#include lt_system.h Or if they are installed headers that must work outside the libtool source tree, simply: - #include libltdl/lt_system.h +#include libltdl/lt_system.h This layer's interface is defined by files that are usually named with a leading `lt__': - ,. ,---. ,--.,---. - |lt__dirent.h| |lt__alloc.h| |argz.h||slist.h| - ++ +---+ +--++---+ - |lt__dirent.c| |lt__alloc.c| |argz.c||slist.c| - `' `---' `--'`---' - - The exceptions here are argz.h and slist.h which are used - independently of libltdl in other projects. - -* There is also a sub-layer that can be used either by the headers that - implement it, in which case its function is to avoid namespace clashes - when linked with the GNU C library; Or it can be included by code that - wants to program against a glibc like interface, where it also serves - the function of pulling in all the glibc-like functionality used by - libltdl from a single: - - #include libltdl/lt__glibc.h - - It consists of the single file: - - lt__glibc.h - -* The next layer are the subsystems of the exported libltdl API, which - are defined by files that are named with a leading `lt_' (no double -
Re: 327-gary-clarify-libltdl-api-docs
Hallo Ralf, On 28 Mar 2007, at 17:12, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Mar 28, 2007 at 01:55:02PM CEST: Whilst becoming reacquainted with the guts of libltdl in order to work on release blockers, I found myself rewriting this part of the HACKING file. Okay to commit to HEAD? Sure, with nits below addressed. Nits addressed and committed. Thanks for the review. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
Re: Support for Interix 5.2 and 6.0?
Hello Ralf,
On Tue, 27 Mar 2007, Ralf Wildenhues wrote:
* Martin Koeppe wrote on Tue, Mar 27, 2007 at 10:32:41PM CEST:
For libtool-2.1a I replaced the outdated config.* and also put a copy
in the root source dir, ran ./configure make (i.e. GNU make!), then
make -k check. The output is attached, 2 errors besides hardcode!
Cool. Gary's fixes for non-GNU make took care of the build issues,
the test failures (beside hardcode) are due to one issue only.
I ran the test with GNU make, not Interix make!
I guess the XPASS we observed back then must be on Interix 3 only then.
Does the patch below fix both failures? You can test faster by
make check-local TESTSUITEFLAGS='47 49'
after applying the patch.
I now downloaded libtool-2.1a as of 20070328 13:48 +0200,
applied the patch below and did a complete re-test, i.e. I
renamed both the makes to make.gnu and make.itx respectively,
made sure that there is no plain make in PATH, and built both on 3.5
and 5.2 with both make's. (./configure MAKE=make.{gnu,itx})
Unfortunately, the build on 3.5 has stopped for reasons not related to
libtool. Will retest that later.
On 5.2 with GNU make the check-local test now finishes as expected: 47
expected, 2 skipped.
On 5.2 with Interix make, however, there is no build! I ran:
$ ./configure MAKE=make.itx
[ normal configure output ]
$ make.itx
[ configure is rerun here and the last lines are: ]
checking for gcj... no
checking for windres... no
configure: creating ./config.status
cd . /bin/sh /tmp/libtool-2.1a-itx/libltdl/config/missing --run
autoheader
rm -f stamp-h1
touch ./config-h.in
cd . /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make: not found
*** Error code 1
Stop.
So Interix make decides to rerun ./configure while GNU make doesn't,
and at some point there must be hardcoded make! configure isn't
rerun by GNU make, so the bug might be hidden for it.
- Native make on interix is not usable, only to build GNU make ;o)
Apparently it is now, for Libtool. :-)
No, not yet!
Martin
Markus is right, it was the native interix make, which is some 4.4BSD
make. I have the man page attached. That man page says something about
a difference to gmake with recursive make calls.
Thanks. The issues noted in the manpage shouldn't matter now, I guess.
Cheers,
Ralf
2007-03-27 Ralf Wildenhues [EMAIL PROTECTED]
* tests/deplibs-ident.at: XPASS only on Interix 3.
Report by Martin Koeppe [EMAIL PROTECTED].
Index: tests/deplibs-ident.at
===
RCS file: /cvsroot/libtool/libtool/tests/deplibs-ident.at,v
retrieving revision 1.7
diff -u -r1.7 deplibs-ident.at
--- tests/deplibs-ident.at 25 Mar 2007 12:12:43 - 1.7
+++ tests/deplibs-ident.at 27 Mar 2007 21:07:12 -
@@ -67,7 +67,7 @@
[0],[stdout],[ignore])
AT_CHECK([$EGREP 'cee.*cee' stdout], 1, [ignore], [ignore])
AT_XFAIL_IF([case $host in
- *-*-aix*|hppa*-*-hpux*|*-*-interix*|*-*-openbsd*) false;;
+ *-*-aix*|hppa*-*-hpux*|*-*-interix3|*-*-openbsd*) false;;
*):;;
esac])
dnl This is currently broken in libtool
Re: [RFC] New library type needed?
Ralf Wildenhues wrote: Here's a review based on the question how such a concept could be expressed portably. I don't see how something like this would be of great help if it could not be made to gracefully decay into something still usable, on at least a useful set of platforms if not all of them. Agreed. While I was considering the problem, I kept getting the feeling that either (1) I was missing something, or (2) this was very win32 specific: it's a problem only for platforms that require -no-undefined for shared libraries, which I think is only win32 and AIX. * Charles Wilson wrote on Sun, Mar 25, 2007 at 09:34:47PM CEST: What I really want is a type of convenience library (call it a resolver library?) that (1) is built both PIC and non-PIC, depending of course on the value of enable_shared and enable_static. So far, just like a normal convenience lib. Well, currently a convenience lib is not built in both ways at the same time, but that's only a side issue for the discussion at hand. Really? I thought I had both; perhaps it was just accumulated clutter from multiple builds with different settings. In any case, I can see where the current behavior you describe could be problematic on some platforms, including win32, in certain cases. (2) where the non-PIC resolver library is ignored when building dependent static libraries (and dependent static [dlpreopened] modules). That is, NOT exploded and included within the dependent. However, the non-PIC resolver library should be used like a normal convenience library when building dependent, in-package executables that depend on it directly OK so far. You want a convenience archive without the whole-ness. Should it be possible to install this thing or not? Ummm...maybe? Let me ping back a few more questions: how would you install/distinguish between the two versions (no-pic and pic)? Would we need a naming convention of some sort and teach ld/gcc about it (a la' .dll.a) This could get ugly. On the other hand, currently binutils/gcc/etc install libiberty.a -- but do not install any headers for it. So the only was to use an *installed* libiberty is to declare the relevant functions yourself (or go dig around in the src for the headers), AND hope that whoever built the libiberty.a you want to link against, built it in such a way that it includes all the functions you want. In short, *currently* libiberty is not well-handled. Since the intent for that library is to share at the source level, a better policy would be for binutils/gcc/etc to affirmatively change their build structure to NOT install libiberty.a. And nobody talks about installing a libgnulib.a -- especially as gnulib-tool lets you change the library name... So maybe the answer to the question SHOULD BE no, even if at present the actual practice IS to install libiberty.a. Can it itself have nontrivial (i.e., non-convenience) dependencies? Errr...the two extant examples (libiberty and gnulib) do not, but... The first of these questions is really a crux of the matter: if libbfd can be shared and installable, then really I don't see any way except - either explicitly forbid any third party to use your library, even though you install it shared, - or have at least some sort of stable interface notion. Yes. Since libiberty is explicitly unstable in its interface, I believe it really makes no sense to install it; it's just of no use outside the build tree. Following this line of reasoning, I think my resolver library concept is really just a variant of a convenience lib -- in the sense that convenience libs are not usually (ever?) considered as installable objects. (worry about PIE here? We don't worry about it at present anywhere that I can see). We have very minimal PIE support only currently in CVS HEAD, in compile mode. Don't know enough about this issue; I'll let it pass... (3) where the PIC resolver library is used *like a static library* when building dependent shared libraries -- that is, used to satisfy undefined symbols in the shared library if -no-undefined, but where the objects in the PIC resolver library are not included wholesale via [ not correction included ] --whole-archive/--no-whole-archive -- and better yet, on win32 they should be excluded from auto-export using -Wl,--exclude-lib -Wl,PIC resolver library name. Lots of systems don't allow symbol hiding (or, at least, Libtool currently doesn't support it well on most systems). What should happen for them? More to the point: what if libbfd uses the resolver libiberty release x, while libfoo used release y of libiberty, we're on a system without symbol hiding, and my program links against both libbfd and libfoo? The order of linkage will determine in which library the blow up occurs, be that silent or spectacular, depending on how incompatible x and y are. But on how many systems are BOTH of the following true: (1) to build shared
