dlls/kernel/comm.c build failure

[Gerald Pfeifer]

The following patch

revision 1.56
  date: 2002/04/21 22:06:09;  author: julliard;  state: Exp;  lines: +24 -0
  
  Faster serial speed cases for non Linux systems.

broke dlls/kernel/comm.c on FreeBSD 4.5 (and probably all non-Linux
systems)

/usr/bin/gcc -c -I. -I. -I../../include -I../../include  -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__  -D_REENTRANT -I/usr/X11R6/include -o comm.o comm.c
  comm.c: In function `SetCommState':
  comm.c:1063: `CBR_230400' undeclared (first use in this function)
  comm.c:1063: (Each undeclared identifier is reported only once
  comm.c:1063: for each function it appears in.)
  gmake[2]: *** [comm.o] Error 1
  gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/kernel'
  gmake[1]: *** [kernel/kernel32.dll.so] Error 2

apparently because CBR_230400 is not #defined in include/winbase.h.

The patch below fixes this, but I suppose it's not what will go in
finally...

Gerald

ChangeLog:
  Only use CBR_230400 and CBR_460800 if they have been defined.
Index: dlls/kernel/comm.c
===================================================================
RCS file: /home/wine/wine/dlls/kernel/comm.c,v
retrieving revision 1.56
diff -u -3 -p -r1.56 comm.c
--- dlls/kernel/comm.c	21 Apr 2002 22:06:09 -0000	1.56
+++ dlls/kernel/comm.c	22 Apr 2002 06:44:43 -0000
@@ -1060,13 +1060,17 @@ BOOL WINAPI SetCommState(
 #endif
 #ifdef B230400
    	case 230400:
+#ifdef CBR_230400
    	case CBR_230400:
+#endif
    		port.c_cflag |= B230400;
    		break;
 #endif
 #ifdef B460800
    	case 460800:
+#ifdef CBR_460800
    	case CBR_460800:
+#endif
    		port.c_cflag |= B460800;
    		break;
 #endif

[Marcus Meissner]

On Mon, Apr 22, 2002 at 08:46:03AM +0200, Gerald Pfeifer wrote:
> The following patch
>
> revision 1.56
>   date: 2002/04/21 22:06:09;  author: julliard;  state: Exp;  lines: +24 -0
>   
>   Faster serial speed cases for non Linux systems.
>
> broke dlls/kernel/comm.c on FreeBSD 4.5 (and probably all non-Linux
> systems)
>
> /usr/bin/gcc -c -I. -I. -I../../include -I../../include  -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__  -D_REENTRANT -I/usr/X11R6/include -o comm.o comm.c
>   comm.c: In function `SetCommState':
>   comm.c:1063: `CBR_230400' undeclared (first use in this function)
>   comm.c:1063: (Each undeclared identifier is reported only once
>   comm.c:1063: for each function it appears in.)
>   gmake[2]: *** [comm.o] Error 1
>   gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/kernel'
>   gmake[1]: *** [kernel/kernel32.dll.so] Error 2
>
> apparently because CBR_230400 is not #defined in include/winbase.h.
>
> The patch below fixes this, but I suppose it's not what will go in
> finally...

I would suggest just dropping those 2 cases, MSDN does not list them
either.

-  		case CBR_230400:
-  		case CBR_460800:

Ciao, Marcus

[Gil Kloepfer Jr.]

I think I probably need to get on the mailing list, but...

On Mon, Apr 22, 2002 at 08:46:03AM +0200, Gerald Pfeifer wrote:
> The following patch
>
> revision 1.56
>   date: 2002/04/21 22:06:09;  author: julliard;  state: Exp;  lines: +24 -0
>   
>   Faster serial speed cases for non Linux systems.
>
> broke dlls/kernel/comm.c on FreeBSD 4.5 (and probably all non-Linux
> systems)

The 57600 and up case (even for Linux) didn't have the CBR_ prefix before
them, which is why I didn't have them in the patch I sent to Bugzilla.
I compiled the changes I submitted successfully on FreeBSD 4.5-RELEASE,
so it should have worked OK.

I'll admit to being a newbie at the entire innards of Wine, so I may have
misunderstood something.  But the code inside the "CBAUD" (I assume this
is what Linux uses) #ifdef has all baud rates >38400 without
the CBR_ prefix in the switch statement.  I simply copied this same
set of case statements to the non-CBAUD version (the #elif !defined(__EMX__)
case) and changed the port.c_cflag to port.c_ospeed.

Hope this helps explain my thought processes.  It looks like that whole
pair of switch/case/#ifdef statements is screaming for a bit of
simplification.

(PS: I'll try to cc the mailing lists, but if it doesn't make it, would
someone please forward it along ... thanks)

---
Gil Kloepfer
[e-mail]