Re: [openobex-users] build problems with NetBSD

[Iain H. <pl...@ry...>]

On Mon, 20 Jun 2011, Hendrik Sattler wrote:

> Zitat von Iain Hibbert <pl...@ry...>:
>
> > On Mon, 20 Jun 2011, Hendrik Sattler wrote:
> >
> > > > <openobex/obex.h> file, the following:
> > > >
> > > > #if !defined(bt_addr_t)
> > > > #  if defined(SOL_RFCOMM)
> > > > #    if defined(_WIN32) /* Windows */
> > > > #      define bt_addr_t BTH_ADDR
> > > > #    else /* Linux, FreeBSD, NetBSD */
> > > > #      define bt_addr_t bdaddr_t
> > > > #    endif
> > > > #  else /* no bluetooth stack available */
> > > > #    define bt_addr_t unsigned long
> > > > #  endif
> > > > #endif
> > > >
> > > > does not actually work since SOL_RFCOMM is never defined on BSD at least
> > > > (we just use the BTPROTO_RFCOMM value instead), and on BlueZ/Linux it is
> > > > only defined where <bluetooth/bluetooth.h> is included prior (otherwise
> > > > the problem is masked, by using unsigned long)
> > >
> > > That is exactly the intended behaviour. If you want to use the bluetooth
> > > functions, you must include the proper bluetooth headers, see
> > > lib/bluez_compat.h.
> >
> > Trouble is, the prototypes exist no matter if the bluetooth support is
> > wanted, and detecting the type of bdaddr_t according to OS does not
> > necessarily mean that the bdaddr_t type is defined..
> >
> > For example, on NetBSD bt_addr_t will be set to bdaddr_t which is correct,
> > except that if you are writing an obex program that wants to use TcpOBEX
> > routines only then the compilation will fail because you didn't include
> > the bluetooth header and bdaddr_t is an unknown type..
> >
> > Looking at it further, the following would seem to be a more reliable way
> > to detect if the type has been declared
> >
> > 1. Windows
> >    BTH_ADDR_NULL is defined in <wga/bluetooth/bthdef.h>, included from
> >    <ws2bth.h>
> >
> > 2. FreeBSD
> >    NG_HCI_BDADDR_ANY is defined in <netgraph/bluetooth/include/ng_hci.h>,
> >    included from <bluetooth.h>
> >
> > 3. NetBSD (including DragonflyBSD, OpenBSD & OpenSolaris)
> >    BDADDR_ANY defined in <netbt/bluetooth.h>, included from <bluetooth.h>
> >
> > 4. BlueZ/Linux
> >    BDADDR_ANY defined in <bluetooth/bluetooth.h>
> >
> > all near the appropriate type declaration.. ?
>
> Maybe we should use whatever is apropriate for that system, see[1]:
> #if defined(_WIN32)

I actually disklike this method, for the reason that it breaks when the OS
changes even though the feature remains (eg _WIN64 will fail to work in
your example :) better to rely just on the feature itself, though it could
be better expressed the other way around for safety

#if !defined(bt_addr_t)
#  if defined(BDADDR_ANY)
#    define bt_addr_t	bdaddr_t
#  elif defined(NG_HCI_BDADDR_ANY)
#    define bt_addr_t	bdaddr_t
#  elif defined(BTH_ADDR_NULL)
#    define bt_addr_t	BTH_ADDR
#  endif
#endif

> Or just use your mentioned PF_BTH/PF_BLUETOOTH approach.

No that doesn't work correctly, for the reason I mentioned before..

> BTW: Solaris has bluetooth? That's news to me. Does OpenOBEX need any change
> to support this?

OpenSolaris (and I guess Illumos now) does contain parts of the NetBSD
Bluetooth stack, and the configure script may detect that and act
appropriately, but I don't know for sure..

iain