--- Mattia Barbon <mbarbon@...> wrote: > > Mattia, could you test
these with the TEST target in
> w32api/lib/makefile?
> All OK
>
> > Also it would be helpful to try out the same test using Watcom to see
> if
> > you've missed anything (I suspect more DECLARE_STDCALL_P needed in
> > winsock2.h)
> This is one.
> There are other problems with rpcproxy.h
> 1 - Watcom C/C++
> void *Vtbl[0];
>
> Solution: #ifdef out if Watcom
>
That one is easy. Just change array length to 1 if def __STRICT_ANSI__ or
WATCOMC. zero-length arrays throw pedantic warnings on mingw as well
> 2 - Watcom C++
> const PCInterfaceProxyVtblList *pProxyVtblList;
> and the other const members in a struct without constructor
>
> Solution: #ifdef non-const versions for Watcom
>
> 3 - Watcom C++
> IRpcStubBufferVtbl and CStdPSFactoryBuffer not declared
>
> Solution: ?
>
These 2 are not easy. Currently, rpcproxy.h has only CINTERFACE types of
definitions for many (most?) structs. They fail in C++ on mingw as well.
Until C++ interface is fixed, probably need to guard much of that header
with #ifndef __cplusplus
> I can correct 1 and 2, I don't know what to do with 3
> Other than that it is all OK
>
> > If these compatability patches are committed, does that mean that we
> can
> > expect more input from Watcom users? That could be a very nice
> > side-effect.
> I think so: currently OpenWatcom can create executables using w32api
> only if installed over a previous Watcom version, with these patches
> one can create Win32 programs using just the packages from
> http://www.openwatcom.org and w32api.
>
> Regards
> Mattia
>
Thanks Mattia. Please provide a ChangeLog and I'll commit to CVS. I'll
have a closer look at the rpcproxy.h problems.
Danny
http://briefcase.yahoo.com.au - Yahoo! Briefcase
- Manage your files online.

Hello list,
I get the following annoying warnings from an uptodate MinGW installation
when passing -Wall -Wmissing-prototypes to gcc and including <winsock2.h>:
winnt.h:2521: warning: no previous prototype for `GetCurrentFiber'
winnt.h:2532: warning: no previous prototype for `GetFiberData'
This would not happen when declaring in front of their actual definition
in winnt.h via:
PVOID GetCurrentFiber(void);
PVOID GetFiberData(void);
Is that already in CVS or unnecessary overhead?
My sencond request for changes is related to the file <sys/locking.h>:
There you define _LK_UNLOCK and LK_UNLOCK which should be _LK_UNLCK and
LK_UNLCK. I guess this is a typo. Could you please correct it?
You can verify this at
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__locking.asp&gt;.
Thanks in advance,
stefan@...

Hello list,
I get the following annoying warnings from an uptodate MinGW installation
when passing -Wall -Wmissing-prototypes to gcc and including <winsock2.h>:
winnt.h:2521: warning: no previous prototype for `GetCurrentFiber'
winnt.h:2532: warning: no previous prototype for `GetFiberData'
This would not happen when declaring in front of their actual definition
in winnt.h via:
PVOID GetCurrentFiber(void);
PVOID GetFiberData(void);
Is that already in CVS or unnecessary overhead?
My sencond request for changes is related to the file <sys/locking.h>:
There you define _LK_UNLOCK and LK_UNLOCK which should be _LK_UNLCK and
LK_UNLCK. I guess this is a typo. Could you please correct it?
You can verify this at
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__locking.asp&gt;.
Thanks in advance,
stefan@...

> Mattia, could you test these with the TEST target in
w32api/lib/makefile?
All OK
> Also it would be helpful to try out the same test using Watcom to see
if
> you've missed anything (I suspect more DECLARE_STDCALL_P needed in
> winsock2.h)
This is one.
There are other problems with rpcproxy.h
1 - Watcom C/C++
void *Vtbl[0];
Solution: #ifdef out if Watcom
2 - Watcom C++
const PCInterfaceProxyVtblList *pProxyVtblList;
and the other const members in a struct without constructor
Solution: #ifdef non-const versions for Watcom
3 - Watcom C++
IRpcStubBufferVtbl and CStdPSFactoryBuffer not declared
Solution: ?
I can correct 1 and 2, I don't know what to do with 3
Other than that it is all OK
> If these compatability patches are committed, does that mean that we
can
> expect more input from Watcom users? That could be a very nice
> side-effect.
I think so: currently OpenWatcom can create executables using w32api
only if installed over a previous Watcom version, with these patches
one can create Win32 programs using just the packages from
http://www.openwatcom.org and w32api.
Regards
Mattia

Greetings,
Here is little problem I've been having.
I need to share couple of variables between .exe and .dll. With MSVC its no
problem #pragma data_seg(".SHARED"), but with MinGW there seems to be
something really funny...
First, I tried it like this:
--------------------------------
static bool test __attribute__((section (".SHARED"), shared)) = false;
Well, no warnings, but Mingw just doesn't create shared section at all.
*sigh*
Okay next attempt:
--------------------------------
asm (".section .SHARED");
static bool test __attribute__((section (".SHARED"), shared)) = false;
Now we get .SHARED section, but we get warnings:
Warning: Ignoring changed section attributes for .SHARED
And shared section only has IRW flags. Does not work. Doh!
03 .SHARED 00000440 00003000 00000600 00000C00 C0000040 [IRW]
---------------------------------------------------
Then I went and digged thru SOURCE code of binutils.implement and found this
little note (obj-coff.c):
.section name {, "flags"}
And I tried it:
asm (".section .SHARED,"s"");
static bool test __attribute__((section (".SHARED"), shared)) = false;
and guess what? Yes, does not work :)
"unterminated string or character constant" *scream*
I'd be most pleased to have quick answer what a heck is correct format of
.section to use with Mingw v1.1 to produce shared sections? (or do I have to
compile and fix that "feature" myself?)
(No, I cannot use memory mapped files for this purpose. I NEED shared
section.)
Thank you for reading this,
Dabb
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

On Fri, Nov 02, 2001 at 12:12:15AM +1000, svz@... wrote:
>Hi there...
>yet another problem for me with gdb and mingw
>
>this time i am using opengl and multimedia libraries in the same program:
>
>-lwinmm -lglu32 -lopengl32
>
>it would appear that in the such a case when both opengl
>and multimedia libs are used - gdb crashes when trying
>to show source code at any breakpoint in the code.
I traced a recent cygwin core dumping issue to the fact that gdb didn't
properly recognize c:/ as indicating an absolute path. So, when it went
to open a file, gdb prepended the current working directory to it, the
file never got opened, and gdb crashed later on trying to access the
unopened fp.
I think I fixed this in the current CVS code, and possibly in the gdb
5.1 branch, as well, if you want to try building from a snapshot. The
fix was to make gdb recognize that both '/' and 'c:/' were valid. This
was done by making a very trivial change to include/filenames.h .
cgf

On Thu, Nov 01, 2001 at 11:59:36AM +0300, Dmitry Bely wrote:
>OK, that's the reason. I just hope that MinGW libraries/headers included
>into Cygwin will also be updated from time to time :-)
I can guarantee this will happen, one way or the other.
cgf

--- Mattia Barbon <mbarbon@...> wrote: > Changes from the last
are:
> * some more corrections
> * the introduction of
> DECLARE_STDCALL_P( type ) that resolves ( in an ugly way )
> the problem of __stdcall foo* functions
>
> DECLARE_STDCALL_P( type ) expands to
> __stdcall type for GCC and
> type __stcall for watcom
>
> If the patch looks ok I'll submit a changelog, too
>
> Regards
> Mattia
>
>
Mattia, could you test these with the TEST target in w32api/lib/makefile?
Also it would be helpful to try out the same test using Watcom to see if
you've missed anything (I suspect more DECLARE_STDCALL_P needed in
winsock2.h)
If these compatability patches are committed, does that mean that we can
expect more input from Watcom users? That could be a very nice
side-effect.
Danny
http://briefcase.yahoo.com.au - Yahoo! Briefcase
- Manage your files online.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details