Jack
2016-02-14 22:25:19 UTC
I'm asking the cygwinports list first, because my hunting seems to hint
that at one point, mono was available under cygwinports, but I haven't
found any details. I'm hoping someone can either give me a useful
hint, or perhaps point me at a useful resource.
I have a mono program (f-spot) which I'd like to get running under
Windows. There are some dependencies which do not have native windows
ports (dbus, for example) so I'd like to see if I can possibly get it
working under cygwin. However, I'm getting stuck pretty early in the
process. I've found various web pages purporting to give instructions
for compiling mono under cygwin, but they give conflicting information,
and so far, none I've tried has worked. I suspect part of the problem
is they are all from different times, and so different version
combinations of mono and cygwin. The underlying issue always seems to
be some conflict between windows and posix paths.
The first issue is what prefix to give to mono. Some sites suggest a
short windows path (H:\MonoInstall) for example, and one site had you
later bind mount this to /usr/local. However, some part of the compile
always trips over the windows path, often trying to put a windows drive
(H:) in front of a posix path (/usr/local/...) giving
(H:/usr/local/...) which won't work for anyone. Using
prefix=/usr/local lets me compile and install, but later, compiling
gtk-sharp, some of the utilities seem to expect Windows paths as
arguments. Note that if I just do ./configure for mono, it only
outputs a few lines, and then says to do ./compile
--host=x86-pc-mingw32. As I understand it, this will produce mono
native windows executables, which is not what I want. I really do want
everything to run under cygwin. However, explicitly using any other
host just tells me to use mingw32.
I've avoided giving specific error messages, because every one I've
tried to deal with just seems to lead me down a rabbit hole of twisty
little passages. I've also tried so many variations, I'm no longer
sure which try produced which error.
Thanks for any suggestions or hints.
Jack
that at one point, mono was available under cygwinports, but I haven't
found any details. I'm hoping someone can either give me a useful
hint, or perhaps point me at a useful resource.
I have a mono program (f-spot) which I'd like to get running under
Windows. There are some dependencies which do not have native windows
ports (dbus, for example) so I'd like to see if I can possibly get it
working under cygwin. However, I'm getting stuck pretty early in the
process. I've found various web pages purporting to give instructions
for compiling mono under cygwin, but they give conflicting information,
and so far, none I've tried has worked. I suspect part of the problem
is they are all from different times, and so different version
combinations of mono and cygwin. The underlying issue always seems to
be some conflict between windows and posix paths.
The first issue is what prefix to give to mono. Some sites suggest a
short windows path (H:\MonoInstall) for example, and one site had you
later bind mount this to /usr/local. However, some part of the compile
always trips over the windows path, often trying to put a windows drive
(H:) in front of a posix path (/usr/local/...) giving
(H:/usr/local/...) which won't work for anyone. Using
prefix=/usr/local lets me compile and install, but later, compiling
gtk-sharp, some of the utilities seem to expect Windows paths as
arguments. Note that if I just do ./configure for mono, it only
outputs a few lines, and then says to do ./compile
--host=x86-pc-mingw32. As I understand it, this will produce mono
native windows executables, which is not what I want. I really do want
everything to run under cygwin. However, explicitly using any other
host just tells me to use mingw32.
I've avoided giving specific error messages, because every one I've
tried to deal with just seems to lead me down a rabbit hole of twisty
little passages. I've also tried so many variations, I'm no longer
sure which try produced which error.
Thanks for any suggestions or hints.
Jack