Erik van Pienbroek wrote:
> Hi,
> 
> As promised, here are the patches to make wxWinCE compile using
> arm-wince-minw32ce.
> 

Neat!

> CeGCC patch:
> - The declaration of 'gettimeofday' was #ifndef'ed out in sys/time.h
>   I removed this #ifndef as this function is provided by mingwm10.dll

Not really from mingwm10.dll, but from libmingwex.a, which gets linked
statically into your dll/app.  mingwm10.dll doesn't export any public api,
and is needed to support multithreaded c++ apps with exception
support enabled.

> - There are some #define's which have a value of 0x0. I don't know
>   how to retrieve these values legally. Can somebody else look at this? 
> 
> wxWinCE patch:
> - A macro which translates a system() call to a ShellExecuteEx()
>   call needs to be added (include/wx/wxcrtbase.h)
> - The wxCRT_GetenvA/wxCRT_GetenvW macro's cause (innocent)
>   compiler warnings (include/wx/wxcrtbase.h)
> - WinCE doesn't have the DrawState() function. A alternative for
>   this needs to be implemented (src/msw/ownerdrw.cpp)
> - Some wxWidgets features are disabled. These are wxConfig, wxIntl,
>   wxMDI, wxHTML, wxXRC, wxAUI, wxMimeType and wxRichText.
> - Window placement is borked up; In most samples half of the window
>   isn't visible because the window is bigger than the screen of the PDA.
>   I don't know if this is a known bug in wxWinCE, but it definately
>   needs more investigating.
> 
> Enjoy!
> 


I know nothing wxWidgets, but still let me comment on your patch, as
it may reveal things needing to be fixed on the mingw32ce side.


  if test "$USE_WIN32" = 1 ; then
-    AC_CHECK_HEADERS(w32api.h,,, [ ])
-    AC_CHECK_HEADER(windows.h,,
-    [
-        AC_MSG_ERROR(please set CFLAGS to contain the location of windows.h)
-    ],
-    [ ])
+    if test "$wxUSE_WINCE" != 1 ; then
+        AC_CHECK_HEADER(w32api.h,,, [ ])
+        AC_CHECK_HEADER(windows.h,,
+        [
+            AC_MSG_ERROR(please set CFLAGS to contain the location of 
windows.h)
+        ],
+        [ ])
+    fi

Why did you need this hunk?  Those headers should be available in mingw32ce.

+    if test "$wxUSE_WINCE" = 1 ; then
+        LIBS="$LIBS -lcommctrl -lcommdlg -lws2 -lceshell -laygshell -lstdc++"
+    else
+        LIBS="$LIBS -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32
-lctl3d32 -ladvapi32 -lwsock32 -lgdi32"
+    fi

-lstdc++ ?  Why did you need to add it manually?  Using g++ to link does that
for you.


+    if test "$wxUSE_WINCE" = 1 ; then
+        TOOLKIT=WINCE
+        GUIDIST=WINCE_DIST
+        WXCONFIG_CPPFLAGS="${WXCONFIG_CPPFLAGS} -D_WIN32_WCE=0x300
-D__MSVCRT__"   // -D__MSVCRT__ kan mogelijk weg
+    fi
+


-D__MSVCRT__ looks very wrong here.  mingw32ce uses __COREDLL__ (defined
automatically by the compiler) to signal the native runtime is coming from
coredll.dll with all its (mis)features.  __MSVCRT__ means that the app is
linking to msvcrt.dll, which doesn't happen with (any recent) CE.  Defining
that for CE will may break things subtilly. Take a grep at
src/mingw/include to see what I mean.


<set var="BASE_WINCE_SRC" hints="files">
      <if cond="TOOLKIT=='WINCE'">src/msw/wince/time.cpp</if>
  </set>
+<set var="BASE_WINCE_SRC" hints="files">
+    src/msw/wince/filefnwce.cpp
+    src/msw/wince/crt.cpp
+</set>

I know nothing Bakefiles, but that looks suspicious.  You're setting
BASE_WINCE_SRC twice ?


+++ src/msw/gsocket.cpp (working copy)
@@ -45,7 +45,7 @@

  #endif /* _MSC_VER */

-#if defined(__CYGWIN__)
+#if defined(__CYGWIN__) || defined(_WIN32_WCE)
      //CYGWIN gives annoying warning about runtime stuff if we don't do this
  #   define USE_SYS_TYPES_FD_SET
  #   include <sys/types.h>

Just wondering (without really looking), why you needed this in mingw32ce,
but it isn't needed in MinGW?

-    return (unsigned long)::GetCurrentThreadId();
+    return (unsigned long) GetCurrentThreadId();

I'd be willing to accept patches to our headers to change these macros to
inline functions.  Then these changes wouldn't be needed.  I'm sure
there's more software out there that would need this, so better do it
one in our headers.


-        i64 = i64 * 10000000 + 116444736000000000;
+        i64 = (i64 * 10000000 + (1164447360) * 100000000);

This doesn't solve the issue.  You'll get an overflow here:
(1164447360) * 100000000

You need to either use LL on gcc and i64 on MSVC, or load those constants
into 64bit variables, step by step, like so:

-        i64 = i64 * 10000000 + 116444736000000000;
+        i64_2 = 1164447360;
+        i64_2 *= 100000000;
+        i64 = (i64 * 10000000 + i64_2;


-struct servent * WINSOCKAPI getservbyport(int port, const char * proto)
+struct servent * WINAPI getservbyport(int port, const char * proto)

How did these build in MinGW/Cygwin?  Where is WINSOCKAPI defined?



+// FIXME: find out the real values these defines:
http://msdn2.microsoft.com/en-us/library/ms901140.aspx
+#define ANTIALIASED_QUALITY      0x0
+#define NONANTIALIASED_QUALITY   0x0
+#define CLEARTYPE_COMPAT_QUALITY 0x0
+#define CLEARTYPE_QUALITY        0x0
+#define DEFAULT_QUALITY          0x0
+#define DRAFT_QUALITY            0x0
+

Please don't.  Better have it failing to compile, than having hard to
debug unexpected behaviour.  I'd prefer that you'd do it in wx side,
if you still want to provide the funcionality:

#ifndef ANTIALIASED_QUALITY
#define ANTIALIASED_QUALITY      0x0
#endif
...

You can move up with a test application that brute forces those
the possible numbers?  Maybe there is a function that fails if you
pass an invalid _QUALITY?  That would make it much easier.

The rest looks pretty much OK for mingw32ce.  Could you remove the
java url and resubmit?

Thanks!

Cheers,
Pedro Alves




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

Reply via email to