[Mono-dev] Mono on Windows/x64

Wed Apr 25 09:14:14 EDT 2007

Michael,

I fixed a test or two.

First, chage your define of strtok_r to (fixes string test):

#define strtok_r strtok_s

The path test is fixed by making all tests use g_getenv instead of getenv
and implementing g_getenv as (windows doesn't seem to like mixing
SetEnvironmentVariable with getenv; they seem to work on two different env
var sets):

const gchar *
g_getenv(const gchar *variable)
{
#ifdef G_OS_WIN32
    gunichar2 *var, *buffer;
    gchar* val = NULL;
    gint32 buffer_size = 1024;
    gint32 retval;
    var = u8to16(variable);
    buffer = g_malloc(buffer_size*sizeof(gunichar2));
    retval = GetEnvironmentVariable (var, buffer, buffer_size);
    if (retval != 0) {
        if (retval != buffer_size -1) {
            g_free (buffer);
            buffer_size = retval;
            buffer = g_malloc(buffer_size*sizeof(gunichar2));
            retval = GetEnvironmentVariable (var, buffer, buffer_size);
        }
        val = u16to8 (buffer);
    }
    g_free(var);
    g_free(buffer);
    return val;
#else
    return getenv(variable);
#endif
}

Also, your stuff doesn't build on linux, but I added some configure stuff to
fix that.

In configure.ac I added (at line 52):

AC_CHECK_FUNC(getopt_long,
    [AC_DEFINE(HAVE_GETOPT_H, 1,
      [Define this if there is a system getopt.h header])
    ],[])

Should eglib use the config.h generated by configure.ac, or the
eglib-config.h generated by eglib-config.h.in, or both? My change doesn't do
any good unless config.h is actually included.

I know you hard coded those values in glib.h, but the problem seems to be
build on linux, the system glib header gets pulled in perhaps?  Should
eglib/test be pulling in system glib headers, or just eglib headers?

Thanks,
Jonathan

On 4/25/07, Michael Jerris <mike at jerris.com> wrote:
>
>  Fixed a few more test failures…   The following are all that is left that
> fails, a couple of these (g_strsplit and g_file_test) I have a feeling are
> not msvc specific, could someone confirm if all the tests pass on linux
> please.
>
>
>
> The following tests are the ones still failing:
>
>
>
> g_strsplit: FAILED (Expected only 3 elements)
>
> g_find_program_in_path2: FAILED (It should find 'test_eglib.exe' in the
> current directory.)
>
> g_shell_spawn_sync: FAILED (Status is -1)
>
> g_shell_spawn_async_with_pipes: FAILED (2 child pid not returned)
>
> g_file_test: FAILED (tmp does not exist.)
>
> g_dir_*: FAILED (4 got no error)
>
> g_convert: FAILED (Expected 24 bytes, got: NULL)
>
>
>
> Mike
>
>
>
>
>   ------------------------------
>
> *From:* mono-devel-list-bounces at lists.ximian.com [mailto:
> mono-devel-list-bounces at lists.ximian.com] *On Behalf Of *Michael Jerris
> *Sent:* Wednesday, April 25, 2007 1:31 AM
> *To:* mono-devel-list at lists.ximian.com
> *Subject:* Re: [Mono-dev] Mono on Windows/x64
>
>
>
> The previous patch has been committed now.  This is a follow up patch
> that:
>
>
>
> 1. provides more standard ifdefs for conditionally including headers.  I
> did not do autoconf checks for header availability, how would you like that
> done?
>
>
>
> 2. Supply several replacement functions that were not available in msvc.
>
>
>
> 3. Provided a few windows specific implementations.
>
>
>
> 4. added building of the eglib test suite (including a getopt
> replacement).
>
>
>
> 5. add and/or ifdef a bunch of includes in the eglib tests.
>
>
>
> 6. resolve many warnings, mostly related to signedness or int type
> overflows.
>
>
>
> 7. standardized line endings to LF only.
>
>
>
> 8. change warning levels to the project files for eglib and it's tests to
> the max, warnings as errors, disable a few warnings.
>
>
>
> Current status of eglib and test build is that everything compiles and
> links but there are some now commented incomplete windows implementations as
> follows:
>
>
>
> gspawn.c:g_spawn_async_with_pipes (probably requires alternate
> implementation)
>
> gspawn.c:g_spawn_command_line_sync (probably requires alternate
> implementation)
>
>
>
> gunicode.c:g_convert (requires iconv or alternate implementation)
>
> gunicode.c:g_get_charset (requires iconv or alternate implementation)
>
>
>
> We still need to handle msvc/windows implementations for the 4 functions
> above so that we can run the test suite and see how much more work is to go.
>
>
>
> For the gunicode functions, do we really need iconv, or does windows
> already provide the functionality needed in other api's?
>
>
>
> Does anyone have windows api implementations for any of those 4 functions
> that they could provide or wish to write?
>
>
>
> Also, attached results.txt shows the test results of the code after this
> patch on windows.  There are still quite a few that need to get fixed.
>
>
>
> TODO:
>
>
>
> Test on gcc (if someone could provide feedback on the mailing list that it
> still builds and does not introduce any regressions I would appreciate it)
>
> Answer to the question posed in #1 above. (I can add the checks or
> implement as required, just need to know how it should go)
>
>
>
> Mike
>
>
>
>
>
> > -----Original Message-----
>
> > From: Miguel de Icaza [mailto:miguel at novell.com]
>
> > Sent: Monday, April 23, 2007 4:22 PM
>
> > To: Michael Jerris
>
> > Cc: mono-devel-list at lists.ximian.com; Kornél Pál; Jonathan Chambers
>
> > Subject: RE: [Mono-dev] Mono on Windows/x64
>
> >
>
> > Hey,
>
> >
>
> > > This patch is confirmed to compile clean on gcc now.  Feedback?
>
> >
>
> > It can go in;  Feel free to commit.
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070425/4bf97803/attachment.html 