(sorry for multiple posting i had a problem)
Hello -
>Actually, I built dbus-libs and most of dbus-utils under m68knommu without too
>much trouble; Now I did have some manual hacking to do, and there were a few
>tools which did not build, but I did get hciattach, hciconfig, hcitool and
>hcid built. I could have sworn I had the sdp and pan utils too, but my build
>environment is a bit of a mess these days.
sounds like no-fun to me. but hey, if you can post the solution for this
you will probably help a lot of people.
>This would be my response as well. Marcel has purposely made it difficult to
>locate older versions of BlueZ in the (IMO) misguided attempt to force
>everyone to test and use the new stuff.
I think i found it :
http://bluez.sf.net/download/bluez-utils-2.10.tar.gz
http://bluez.sf.net/download/bluez-libs-2.10.tar.gz
>d-bus, but yes; it's seems to be unsuitable for light embedded systems and
>you're probably better off with another stack. There aren't many uses for a
>message bus in small embedded systems.
hmm going for a nother stack is no option for most of the projects
because Bluez has become a standard.
but.
maybe a fork of the bluez user space application is a good solution.
get rid of the dbus dependancies.
H.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thursday 10 May 2007 8:23 am, Voni Hakau wrote:
> sounds like no-fun to me. but hey, if you can post the solution for this
> you will probably help a lot of people.
It wasn't really all that difficult, as it does use the autoconf system, and
autoconf is generally pretty good about cross-compilation. Most of my
troubles came due to vfork(), but that wasn't difficult to fix, and also due
to my build environment being ... wonky. :-)
> hmm going for a nother stack is no option for most of the projects
> because Bluez has become a standard.
> but.
> maybe a fork of the bluez user space application is a good solution.
> get rid of the dbus dependancies.
See my other post about perhaps a better solution being "dbus-lite" -- an
API-matched library which strips away all of the magic and essentially gives
you a bare-bones IPC that lines up as good as possible to the dbus API.
-A.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Voni,
> >This would be my response as well. Marcel has purposely made it difficult to
> >locate older versions of BlueZ in the (IMO) misguided attempt to force
> >everyone to test and use the new stuff.
>
> I think i found it :
>
> http://bluez.sf.net/download/bluez-utils-2.10.tar.gz
> http://bluez.sf.net/download/bluez-libs-2.10.tar.gz
the latest 2.x release is actually 2.25 and there exists a
bluez-announce mailing list. Maybe time to subscribe to it.
> >d-bus, but yes; it's seems to be unsuitable for light embedded systems and
> >you're probably better off with another stack. There aren't many uses for a
> >message bus in small embedded systems.
>
> hmm going for a nother stack is no option for most of the projects
> because Bluez has become a standard.
And D-Bus has become a standard, too. And not only for the desktop. It
has been successfully used in various embedded projects. And yes I know
that embedded describes a lot of systems. If you go really really small
and D-Bus causes troubles then please fix D-Bus.
> but.
> maybe a fork of the bluez user space application is a good solution.
> get rid of the dbus dependancies.
Be my guest, but once you see the functional difference between 2.x and
3.x generation you might really wanna use 3.x and its D-Bus API. It
became really nice, easy and simple in the last two years.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users