Re: [Demexp-dev] Succesful compilation of DemExp under Win32/Cygwin

[GISQUET Christophe]

Good evening,

On Thu, 3 Mar 2005, David MENTRE wrote:
> A GREAT thank you for your effort and realization! I have not yet read
> your instructions but will do.

It seems quite probable that installing a Cygwin environment may fix 
problems, and that's what is hiding the problems in my case.

> Regarding CDuce dependency, in fact you don't need CDuce to build the
> client. However, the Makefile needs to be slightly modified to avoid the
> uneeded dependency on cduce library in the client. I'll try to do that.

It was about getting latest version, but the 0.3 version works fine. Some 
minor strange behaviours (first choice always rejected, necessity to exit 
and rerun the program to update things)

> I have installed your demexp-setup.exe but I was unable to start the
> client. :(

Felix also reported such a problem. No idea why it fails executing; maybe 
it is unable to find some configuration files. I tried to have a minimal 
working set of required files, as I need to manually specify them in the 
installer script.

> I had following error:
> address@hidden /c/Program Files/DemExp

Huh, not /c/Program\ Files/DemExp ?
MinGW is notorious for being quite flaky with paths, see my comments in 
the build steps.

> $ ./bin/demexp-lablgtk2-client.exe
> Autotests compiled.
>  pref autotests...ERROR: cannot read file '/tmp/test-demexprc-file':
> /tmp/test-demexprc-file: No such file or directoryERROR: cannot write file
> '/tmp/test-demexprc-file': /tmp/test-demexprc-file: No such file or
> directoryERROR: cannot read file '/tmp/test-demexprc-file':
> /tmp/test-demexprc-file: No such file or directoryFatal error: exception
> Assert_failure("lablgtk2-clnt/pref.ml.nw", 225, 4)
>
> I tried in both a MinGW shell and a raw Windows2000 shell. In both
> cases, I had above failure.

I also have the same "errors" after make windows. However I don't have 
them when run using the shortcut or from the explorer.


> The /tmp directory exists. I was able to "touch" the test-demexprc-file 
> file in it. I really don't undesrtand why the test is failing.

I think it could be that /tmp is an abstraction that may only exist in a 
Cygwin shell (I thought cygwin1.dll would provide that emulation. I don't 
know how you do this, in particular with OCaml. In C I know one way to 
generate temp file(name)s: mkstemp. But it doesn't exist as such under 
Win32. I think it is mktemp on which you must then do a open(). For 
reference:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__mktemp.2c_._wmktemp.asp

Otherwise, maybe I could try to manually change strings with "/tmp" in 
them and add for instance "C:\" and see what happens. So far, I saw it was 
in lablgtk2-clnt/pref.ml
(btw rm -f in the Makefile is less disturbing as it won't produce the 
error message on compile :)

Last possibility, getenv may be usefull to get some pathes under Win32 
(dunno if it conforms to POSIX, as under linux):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_getenv.2c_._wgetenv.asp

Here are interesting values: USERPROFILE, TEMP, WINDIR, PROGRAMFILES, 
COMMONPROGRAMFILES, and SYSTEMROOT. You can check their actual values by:
- doing echo $VAR in a Cygwin/MinGW shell
- doing echo %VAR% in a Win shell (cmd.exe)


Now for a completely different matter...

The libxml2 dependancy from libglade, it seems the .lib files within the 
win32 -dev packages are the culprits. They are used by MinGW (at least) as 
the equivalent of .a files, so I copied them as such under Cygwin. This 
led to undefined symbols. So I tried again with a version compiled under 
MinGW, and this is working, removing the dependancies on cygxml2, cygiconv 
and cygz (I'm not sure it saves much space).

However, the dll is called libxml2-2.dll, which doesn't match the official 
GTK+ runtime name (libxml.dll). Maybe this could be emulated by a 
link/shortcut (as cygwin seems to do), but I really prefer to sort out 
autotools' obfuscating-like Makefile there... I believe cygwin1.dll 
remains because of ocaml functions and the hack I performed on 
lablgtk2/src/ml_glib.c

As I'm currently experimenting with this (rebuilding a proper libxml2), 
I'm currently not able to check the above problems. And rebuilding libxml2 
(2.6.17) is failing for now, so I'm a bit stuck.

Best regards,
--
Christophe GISQUET
Hello! This is a signature virus! Please copy me into your .signature