On 2009-12-20 at 14:43:01 [+0100], Colin Günther <coling@xxxxxx> wrote: > ingo_weinhold@xxxxxx schrieb: > > Author: bonefish > > Date: 2009-12-20 14:07:02 +0100 (Sun, 20 Dec 2009) > > New Revision: 34716 > > Changeset: http://dev.haiku-os.org/changeset/34716/haiku > > > > Modified: > > haiku/trunk/src/libs/compat/freebsd_network/compat/sys/systm.h > > Log: > > Fixed build. Since vprintf() is defined as a macro, it's a good idea to > > include the <stdio.h> first. I don't see, why the header defines stuff > > that > > is already defined in <stdio.h> anyway. > > > Did you see that vprintf is used to make driver_vprintf called instead > of vprintf, > #define vprintf(fmt, vl) driver_vprintf(fmt, vl) Yep, and exactly that is the problem. If you include <stdio.h> after this file, you'll also rename the vprintf() prototype there and the two don't match (void vs. int return type). > so there must be another solution to the borken build issue you > encounted. The nice thing of driver_vprintf is that it prints out the > corresponding driver name. I'd like to keep that feature :) It's still used as before. Though I don't see, why the function must be named driver_vprintf(). One could just as well implement it as vprintf() (with the correct return type). > Mmh, the header files under compat/ are designed in a way that they > match the inclusion pattern of their FreeBSD counterparts. There is no > stdio.h inclusion in FreeBSD's systm.h, this is why I'm feeling somewhat > uncomfortable with this change. > Can't reproduce a broken build here, for me all compat layer related > stuff compiles just fine. Can you tell me where the broken build occurs, > so maybe we can spot another solution? IIRC the error occurred when 3com/pci/if_xl.c was compiled. As another solution (and something that should be done anyway), you can fix the return type. But since <stdio.h>. seems to be included somewhere anyway, I'd rather just leave the include as is and remove the duplicate prototypes. CU, Ingo