[GiNaC-list] [patch] Document that shared libraries are not supported on some weird platforms

[Richard Haney]

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