This topic contains 22 replies, has 2 voices, and was last updated by Mike 13 years ago.
- 15th November 2005 at 5:12 am #3574
Here ya go. Simple enough fix. Hope you don’t mind slomo
Gah, attachments :/
Post edited by: saintdev, at: 2005/11/14 21:1315th November 2005 at 3:49 pm #3575
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.15th November 2005 at 8:13 pm #3576
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:1316th November 2005 at 12:21 am #3577
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.16th November 2005 at 7:25 am #3578
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.8th March 2006 at 8:02 am #3579
I have updated slomo’s patch for the stable release and for the 0.6.x API which can be found here: http://willrea.be/mt-daapd/mt-daapd-stable-avahi.diff8th March 2006 at 10:51 am #3580
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.
— Ron7th May 2006 at 1:39 pm #3581
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).
The forum ‘Feature Requests’ is closed to new topics and replies.