Re: bluez 4.97: build failure when used in C++ apps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mo, 2012-01-16 at 10:24 +0100, Marcel Holtmann wrote:
> Hi Patrick,
> 
> > Bluez 4.97 has entered some distros recently (Fedora Core, MeeGo 1.2
> > update), which broke compilation of the C++ code in SyncEvolution
> > using /usr/lib/bluetooth.h.
> > 
> > The compiler error is:
> > /usr/include/bluetooth/bluetooth.h::131:9: error: invalid conversion from 'void*' to 'bt_get_le64(void*)::<anonymous struct>*'
> > ...
> > 
> > The reason is that C++, in contrast to C, does not allow conversion of
> > void * to anything, and this code gets compiled as C++ when the app is
> > written in C++. The macro with the assignment itself is older, but only
> > recent Bluez starts to use it in inline functions, thus triggering the
> > problem.
> > 
> > Attached is a proposed solution. Note that I have only verified that it
> > now compiles in C and C++, I have not actually tested the resulting
> > Bluez, because compilation fails for me on Debian Testing for another
> > reason (libcheck.a linked into shared object, doesn't work because not
> > relocatable).
> 
> please can we get inline patches from git format-patch.

Will do. 

> Also this topic
> has been raised before and I need confirmation for a GCC guru to confirm
> that this does exactly the same all all platforms.

Now that you mentioned it I found the previous patch:
http://article.gmane.org/gmane.linux.bluez.kernel/20276/match=invalid
+conversion+void+bt_get_le64+anonymous+struct

Note that my patch is different. It keeps the "struct
__attribute__((packed))" magic and merely changes the (void *) typecast
to something that works in C++ and C. I was uncomfortable to depend on
"typeof" for that initially, but the macro already uses that for the
struct member.

In the worst case it'll fail to compile with some (hypothetical) version
of gcc which supports typeof for the old case but not the new one. IMHO
that's less problematic than the known failure that we have now - but of
course I am biased. I'd like to keep SyncEvolution working with Bluez
without rewriting it in C++ ;-)

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux