Re: A patch for native PARI/GP build on Windows (Mingw+Msys)

[Vasili Burdo <vasili.burdo@gmail.com>]

Hi, Bill!

Sorry for late reply. I had VERY busy week start.
> Hello Vasili,
> I have some questions about your patch.
>
> On Thu, Dec 17, 2009 at 06:07:10PM +0200, Vasili Burdo wrote:
> > Index: config/get_dlld
> > ===================================================================
> > --- config/get_dlld	(revision 12034)
> > +++ config/get_dlld	(working copy)
> > @@ -27,6 +27,7 @@
> >  # On FreeBSD 2.2.5 (Y. Uchikawa) and Cygwin, this does not work.
> >  case "$osname" in 
> >    freebsd|cygwin) DL_DFLT_NAME="\\\"\$(LIBPARI_DYN)\\\"" ;;
> > +  mingw) DL_DFLT_NAME="\\\"\$(LIBPARI_SO)\\\"" ;;
> >    *) DL_DFLT_NAME=NULL ;;
> >  esac
>
> Do you know why DL_DFLT_NAME=$(LIBPARI_DYN) does not work here ? It did not
> work with wine and this is strange because LIBPARI_SO is a symlink to
> LIBPARI_DYN.
The problem is that Windows does not support symlinks. As result, we 
should maintain two copies: libpari.dll (because gp-dyn links to it) and 
libpari-2.4.dll (for install0).
I think keeping two copies is redundant.

> > @@ -84,6 +85,7 @@
> >    case "$osname" in
> >      os2) DLLDFLAGS="$CFLAGS -Zdll" ;; # assume DLLD = gcc
> >      cygwin) DLLDFLAGS="-Wl,--out-implib=\$(LIBPARI_SO)\$(_A),--export-all-symbols";;
> > +	mingw) DLLDFLAGS="-Wl,--out-implib=\$(LIBPARI_SO)\$(_A)";;
> >    esac
> >    if test -n "$DLLDisGCC"; then
> >      case "$arch" in
>
> Do you know why this is different from cygwin ?
IMHO --export-all-symbols is overkill. It exports all public symbols 
including symbols from static libgmp and gcc runtime. I think it's 
redundant.
A better way is to export only public symbols from libpari object files.
I implemented makefile rule (see Makefile.SH diff) which generates 
$(EXPORT_FILE) for Windows DLL. I think this rule can be used for cygwin 
as well.

> > Index: config/Makefile.SH
> > ===================================================================
> > --- config/Makefile.SH  (revision 12034)
> > +++ config/Makefile.SH  (working copy)
> > @@ -48,6 +48,10 @@
> >         export_file=pari.def; export_create="emxexp -u"
> >         # Actually, the build will fail until the switch to -Zomf
> >         dlld_ignore=- ;;
> > +  mingw)
> > +    CFLAGS="$CFLAGS -fno-omit-frame-pointer"
> > +    export_file='$(LIBPARI).def'
> > +    ;;
> >  esac
>
> What is the purpose of 'CFLAGS="$CFLAGS -fno-omit-frame-pointer"' ?
-fomit-frame-pointer ruins setjmp-based error handling - GP produces a 
lot of "Segfault" error messages. I dont understand why it happens, but 
-fno-omit-frame-pointer fixes it.
Probably, there is better place for this option, but I didnt find it yet.

> This cause CFLAGS to have -fno-omit-frame-pointer twice 
> (at least when cross-compiling).
>
> > +if test "$osname" = "mingw"; then
> > +cat >> $file << EOT
> > +
> > +#undef UNIX
> > +#undef GPDATADIR
> > +#define GPDATADIR win32_GPDATADIR()
>
> This does not seems correct.
Yes, That's dirty approach. I will think how to make it cleaner...
But "UNIX" breaks migw build.
See my comments for GPDATADIR below.

> > Index: src/systems/mingw/mingw.c
> > ===================================================================
> > --- src/systems/mingw/mingw.c	(revision 0)
> > +++ src/systems/mingw/mingw.c	(revision 0)
> > @@ -0,0 +1,93 @@
> > +#include <windows.h>
> > +#include <stdio.h>
> > +
> > +const char* 
> > +win32_GPDATADIR()
> > +{
> > +    static char datadir[1024] = {0};
> > +    if( 0 == *datadir ) {
> > +        char* slash;
> > +        GetModuleFileNameA(0, datadir, sizeof(datadir) );
> > +        slash = strrchr(datadir, '\\');
> > +        if( slash ) *(slash+1) = 0;
> > +        //while( (slash = strchr(datadir, '\\')) )
> > +        //    *slash = '/';
> > +        strcat(datadir, "gp-data");
> > +    }
> > +    return datadir;
> > +}
>
> I do not understand what this is doing. Cannot you do that in Configure
> instead ?
It generates default GPDATADIR based on location of executable module.
Let's have gp.exe at "C:\Program Files\GP\gp.exe". Then, this function 
will return GPDATADIR as "C:\Program Files\GP\gp-data"

The problem is that fixed path "/usr/local/share/pari" does not make any 
sense on Windows. I'd like to keep data along with executable module, so 
I can put it on memory stick and use it everywhere without extra 
reconfiguration.

On Windows standard location for data files is something like
"C:\Documents and Settings\(User Name|All Users)\Application 
Data\(Software Name)" and it may change depend on location where Windows 
is installed.
So, I believe my approach is correct, but we should negotiate correct 
location of GP data dir.

BTW, I'm playing with idea to put GP data files into single ZIP archive 
and pipe it through "unzip -p" - just like we handle .gz files.