|
From: | Bob Friesenhahn |
Subject: | Re: MinGW status |
Date: | Sun, 3 Oct 2004 10:37:54 -0500 (CDT) |
On Sun, 3 Oct 2004, Ralf Wildenhues wrote:
`lt__error_strings' assumed to have one element*snip* This is bad news indeed (but a different matter). It essentially means that we are breaking binary compatibility as soon as we add another warning, right? (The array size is part of the ABI). Very unfortunate.At first glance it does not appear to be a problem since the interface is merely an array of string pointers and the index into the array should be generated by libltdl itself so the array index should always be in bounds. Am I wrong?Well, I'm not an expert on this subject. In Drepper's `How To Write Shared Libraries', chapter 3.1, he mentions that ``On platforms which require copy relocations to handle access to variables defined in DSOs in the main application (such as IA-32) the size of the variable must not change at all. Otherwise variables might increase in size.'' I don't what exactly is meant here, and consequently I don't know if it applies to this case.
The array is represented by a single pointer, and that pointer has a fixed size, so it seems ok to me.
As far as how libltdl's build goes, I do not like it at all that libltdl is unnecessary introducing another installed library. I don't see a need for it. I also don't like it that libltdl's Makefile.am is referencing Automake's internal variables.Which ones are Automake internal and not published interface?
Any name which is generated by Automake and not described by the Automake documentation is not a published interface. These internal variables are easily learned by reading the generated Makefile, but using them is essentially a statement that Automake will work the same for the rest of time, or that it worked the same in previous versions.
Bob ====================================== Bob Friesenhahn address@hidden http://www.simplesystems.org/users/bfriesen
[Prev in Thread] | Current Thread | [Next in Thread] |