Sheplyakov Alexei wrote:

So I propose to document that shared libraries are not supported on MinGW. What about this patch?

Index: INSTALL =================================================================== [...] --- INSTALL 19 Oct 2005 20:54:13 -0000 1.54 +++ INSTALL 20 Jul 2006 13:37:43 -0000 [...] +To build ginsh modified version of GNU readline library is necessary. It +is available at <http://gnuwin32.sourceforge.net/packages/readline.htm>. [...]

There is one more thing about the proposed use of the modified readline library. Since it seems that the primary advantage of the modified readline library is that it might permit an "automatic" default linkage to legacy UNIX functions in libgw32c.a , there is also a need for "automatic" default include directories as well. Having to explicitly specify prototypes for legacy functions in libgw32c.a would seem to defeat or complicate the purpose of using libgw32c.a . I suppose one possibility would be to use cygwin headers as a last resort (included farthest down in the source code if their inclusion is needed) and to use cygwin include directories as default include directories to be searched _after_ the default MinGW gcc system include directories, but how would one specify that to gcc? All the methods I know for specifying include directories to gcc place those directories ahead of the standard gcc system directories in priority. So I suppose that in order for the modified readline and libgw32c.a to be effectively useful, gcc would need to be rebuilt with such default lower priority directories specified automatically, but then the default legacy header files would also need to be supplied with the MinGW gcc standard header files in the packaging of the MinGW gcc standard runtime libraries. There is also the question whether inclusion of such a legacy header for a function xyz could cause a conflict between the legacy and main system prototypes for another function uvw whose prototype is specified in that legacy header and also in a main system header. Moreover, macro definitions and the like used for prototypes in system header files are often extremely complex so that a "casual" programmer might be extremely intimidated in attempting to make any ad hoc debug adjustments as to specifying prototypes. (I remember once having to modify a MinGW gcc system header because a simple macro variable in it collided with a variable of the same name in a build package; but fortunately only a simple change in the variable name in the MinGW gcc system header was sufficient to solve the problem so that I didn't have to understand everything that the header file was doing and how it related to other parts of gcc and the runtime libraries. I think this event probably occurred when I was doing a build of CLN or GiNaC a few years ago.) Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com