You are here: Home » Topic » Avahi supportpage 2

Avahi support

This topic contains 22 replies, has 2 voices, and was last updated by  Mike 13 years ago.

Viewing 8 posts - 16 through 23 (of 23 total)
  • Author
  • #3574


    Here ya go. Simple enough fix. Hope you don’t mind slomo

    Gah, attachments :/

    Post edited by: saintdev, at: 2005/11/14 21:13



    Holy cow… I just thought I’d give avahi a little spin for kicks… what a pain in the ass. I run mt-daapd on a headless slackware box. God save anyone who walks down this path… I ended up running ./configure in avahi with about seven different –disable options and still it’s complaining. Why doesn’t specifying –disable-gtk disable all need to have gtk installed? Why is the configure script looking for python gtk support? Come to think of it, what the hell does an mDNS responder need all these graphical toolkits for? Anyway… I still can’t get Avahi to ./configure properly…
    Bottom line: Do Not, under Any circumstances, require Avahi to be installed on a system for any future releases of mt-daapd. This software is nowhere near prime-time yet.



    Here’s what I ended up with. I just used portage to emerge avahi, but I looked at the ebuild to come up with the options that would work on my headless.

    ./configure --disable-glib --disable-qt3 --disable-qt4 --disable-gtk --disable-pygtk --disable-mono --disable-mono-docs

    Now if you have Mono installed I’m sure you can remove –disable-mono/–disable-mono-docs. In theory all you should need to have if you just don’t have GTK is –disable-glib –disable-gtk –disable-pygtk

    Post edited by: saintdev, at: 2005/11/15 12:13



    That still didn’t do the trick. In order to get it to ./configure I had to use the following:

    ./configure --disable-glib --disable-qt3 --disable-qt4 --disable-gtk --disable-pygtk --disable-mono --disable-mono-docs --disable-gtk --with-distro=none --disable-python --prefix=/usr

    which is a little much. Wasn’t the point of automake and so forth that most of these things were “auto”-detected? Anyway, that’s beside the point. Now that it ./configure’s, make’s, and make install’s, it doesn’t build enough of avahi to be of any use. Trying to compile mt-daapd against the resulting build of avahi fails. How can a simple mDNS responder need so many darn bits of software on my system? I mean, Avahi may not be bloatware in an of itself, but apparently it wants me to install so many other pieces of software that I don’t need or intend to use in any way shape or form that it certainly deserves to be in the same catagory as openoffice or the best microsoft can produce…
    Sorry, just when a system service wants me to install everything this side of the moon to work it leaves a bad taste in my mouth.



    That was my take, too — that the bindings and whatnot should be abstracted into about 8 different packages.

    Still, I guess that is a distro problem.

    But no, it won’t require avahi. At some point, I hope that the only mDNS server out there is avahi, and then everything will be easier. Until then, it will support dns_sd.h (via apple, or Howl 2.0), Howl 1.0, or Avahi.

    That’s the goal, anyway. Getting that patch integrated is next on my list, after finding the stupid race that keeps killing the server.



    I have updated slomo’s patch for the stable release and for the 0.6.x API which can be found here:



    thx. I’ll look toward integrating this, but I’ll need help maintaining it. When they go changing the api again tomorrow, I’ll need help brushing the dust off.

    — Ron




    What’s the current status of the avahi support. I installed stable+patch and it is working fine, but I have not seen the code in SVN yet. A few days a ago I tried the patch on the devel branch but it needs some more work than a simple patching now (I guess due to some changes in mt-daapd).

    Kind regards,

Viewing 8 posts - 16 through 23 (of 23 total)

The forum ‘Feature Requests’ is closed to new topics and replies.