[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>.
[...]

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