On Tue, Feb 23, 2010 at 09:10:27PM +0000, Richard Jones wrote:
>
> It would be great if Debian could push changes for cross-compilation
> back upstream. Perhaps this is something we will be able to discuss
> at the OCaml Users Conference in April?
>
Yes, that would be nice...
>
> In Fedora we maintain over 100 mingw32-* packages (not OCaml
> specifically, but many C and C++ libraries), and there are often quite
> a lot of changes from upstream and from the native package.
Indeed, I should have started looking in this direction. In particular
I've now found your mingw32-ocaml-lablgtk.spec, but in fact _after_
having made my own mingw32-lablgtk2*.deb. I should try to factorize
the two someday.
> > Yes, this can be an issue. In general, I recommend to set the PATH with the
> > cross-compiler binaries first:
> > export PATH=/usr/i586-mingw32msvc/bin:$PATH
>
> Oooo, I don't like this at all. This is not necessary for any Fedora
> cross-compiled packages, so I'm not clear why it should be needed for
> Debian ones.
>
As I said earlier I indeed think this export PATH should (and can) be
avoided as much as possible.
So anyway, here's the current status of my effort to cross-compile Coq:
- With the help of Stephane Glondu, we now have debian packages for
mingw32-{camlp5,gtk2,lablgtk2}, see http://debian.glondu.net/mingw32
- With these packages, my initial goal is fulfilled: I'm able to
compile the native opt win32 binaries for coq (including gtk gui
coqide) while comfortably seated in front of my linux box. I've even
prepared a windows installer by re-using a nsis script of someone of
our group. I still have to thoroughly test these binaries, but
initial tests look ok :-)
- My mingw32-gtk2 package is a "fake", I was too lazy to properly
adapt gtk2 and its dependencies. I think that even with indications
coming from the fedora mingw32-*.spec, this is a non-trivial task.
Instead, this .deb repacks an official gtk+-bundle-2.8.17*-win32.zip
coming from ftp.gnome.org.
- My mingw32-lablgtk2 is quite stripped-down: only gtk, no extensions
such as glade, sourceview, gnome-ui or whatever. Moreover it only
contains the "opt" files. Concerning byte version, the build fails
on ocamlc (and hence ocamlrun) trying to load a .so while a .dll has
been produced. To reproduce the issue, simply replace "lablgtkopt"
with "all" in debian/rules. Since I'm focused on getting native .exe
binaries, I've gladly ignored this :-) ...
- But I've nonetheless spent some time trying to understand what's
going on. And I got the feeling that current ocamlrun and ocamlc
from mingw32-ocaml aren't really emulating a mingw32 environment.
For instance:
echo "print_string Sys.os_type" >> test.ml
/usr/i586-mingw32msvc/ocamlc -o test test.ml
./test # answers Unix
Similarly:
/usr/i586-mingw32msvc/ocamlmktop -o mytop
./mytop
print_string Sys.os_type;; (* answers Unix *)
[Btw this ocamlmktop isn't working out-of-the-box, since
toplevellib.cma isn't installed by mingw32-ocaml.]
So, are these ocamlrun/ocamlc/ocamlmktop meant to have different
behavior than the /usr/bin/ ones ? If this is not the case, maybe
they could simply be removed from the package...
When looking at the build process of ocamlrun, I first noticed that
byterun/libcamlrun.a was not remade after switching to the mingw
config/Makefile. But then I realized that ocamlrun itself was not
a remade one, otherwise we would have had a ocamlrun.exe. Which
by the way would be handy to create -custom win32 byte .exe...
Not that I care much about byte when opt is working, but that
might interest some other persons.
Best regards,
Pierre
_______________________________________________
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
