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>. [...]
I tried using the libreadline.a from downloaded binaries (the "all-but-source" package) given by the link http://gnuwin32.sourceforge.net/packages/readline.htm , but "-lreadline" in place of "-lreadline -ltermcap" is not sufficient to satisfy all references at link time. In fact, the reference page indicted way at the bottom of the page in not-quite-fine print that library libgw32c is also required; and clicking on the link provided leads to another page of information and a download link. To summarize, compiling and linking my simple test program required that I specify -lreadline , -lgw32c , -lole32 , -luuid, -lwsock32, and -lmsvcp60 . That second information page -- the page for libgw32c.a -- indicated that "standard" libraries libole32.a, libuuid.a, and libwsock32.a were required, but the need for libmsvcp60.a was not mentioned; that need was only discovered by "grep"ing in "C:/Dev-Cpp/lib" for one of the otherwise unresolved external references. These library specifications are a lot more than the two now required on the linker command line: "-lreadline -ltermcap" (or perhaps "-lreadline -lcurses"). This seems like a lot more complexity, and for what? To simply adhere more strictly to a legacy UNIX style? I guess that may make it easier to port new changes to Windows/cygwin/MinGW without having to add lots of complicated logic in conditional-compile preprocessor statements and/or add possibly other complicated logic in Makefiles. Is that true? I suppose that may translate into generally easier maintenance and fewer bugs. As far as I know, the only version of libreadline.a that will satisfy the _existing_ configure test for a usable readline function is the one I created by inserting the three termcap modules into the libreadline.a I built from source. Incidentally, I tried rebuilding ginsh with "C:/Program Files/GnuWin32/bin/readline5.dll" specified (quotes included or not) as part of the GINSH_LIBS value and got a linktime message: libtool: link: cannot find the library `' , but when I copied the .dll to "C:/Dev-Cpp/bin" and used "C:/Dev-Cpp/bin/readline5.dll" instead, there was no problem. "C:/Program Files/GnuWin32" is where the downloaded readline installer puts the installed package, but it seems that libtool probably chokes on the space in the pathname. So it seems that that modified readline ought to be moved or copied to some other location that doesn't have a space in its pathname. Note also that the downloaded binaries are for version 5.0, whereas the most recent stable, unmodified version as of June 19 is 5.1. Also, there seems to be no mention on the web page or in the downloaded files as to which version of MinGW gcc was used for compiling the packaged binaries. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com