FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › General Discussion › How to build?
- This topic has 5 replies, 2 voices, and was last updated 18 years, 4 months ago by rpedde.
-
AuthorPosts
-
03/07/2006 at 5:12 PM #409pellerGuest
Sorry if this is obvious, but can anyone help me figure out how to do a build on Linux? I looked at the readme which starts at ./configure. I tried doing an autoconf, but I must be missing some dependencies and/or switches?
autoconf says:
configure.in:6: error: possibly undefined macro: AM_CONFIG_HEADER
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:7: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:13: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.in:21: error: possibly undefined macro: AM_CONDITIONALthen ./configure says:
configure: error: cannot find sources (config.h.in) in . or ..
(Sorry, I’m pretty ignorant when it comes to autoconf)
I’d like to try fixing #78 and #79, which don’t look too hard.
-Adam
04/07/2006 at 5:14 AM #5408rpeddeParticipant@peller wrote:
Sorry if this is obvious, but can anyone help me figure out how to do a build on Linux? I looked at the readme which starts at ./configure. I tried doing an autoconf, but I must be missing some dependencies and/or switches?
autoconf says:
configure.in:6: error: possibly undefined macro: AM_CONFIG_HEADER
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:7: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.in:13: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.in:21: error: possibly undefined macro: AM_CONDITIONALthen ./configure says:
configure: error: cannot find sources (config.h.in) in . or ..
(Sorry, I’m pretty ignorant when it comes to autoconf)
I’d like to try fixing #78 and #79, which don’t look too hard.
-Adam
Copy reconf.sh.templ to reconf.sh, and run that. You’ll need libtool installed, as well as automake. That should go, so long as you have reasonably recent auto tools.
If you want the fix for #78 and #79 merged, make it an environment variable, and replace popen with exec. Something like http://www.iu.hio.no/~mark/unix/unix.html#SEC178 might be helpful. Also, kill the process if it doesn’t die by itself when stdin closes. That’s what #78 and #79 are waiting on, so you can speed the process by doing it that way to being with.
— Ron
04/07/2006 at 5:36 AM #5409pellerGuestYou read my mind about the exec()… though I’m extremely rusty at unix/C++ so this trivial exercise may take me a while.
04/07/2006 at 7:22 AM #5410rpeddeParticipant@peller wrote:
You read my mind about the exec()… though I’m extremely rusty at unix/C++ so this trivial exercise may take me a while.
yeah, the exec way is definitely the Right Thing To Do, and fixes the zombie process thing on decoders that don’t exit on stdin closing (alac decoder, I’m talking about you).
Do look at that link, though, it’s got a popen-compatable interface for exec. Should be easy to drop in almost as-is.
— Ron
04/07/2006 at 6:52 PM #5411pellerGuestSo where does one find id3tag.h? (Again, silly n00b question)
Taking this a bit further, can the mt-daapd.sh script be modified to do script execs to spawn off the corresponding transcoder? This would mean one less process per transcode, and every little bit helps on the slug. (I’ll try to do this as well, provided I get around to making the build work)
I like the idea of putting the parameters in environment variables instead of $1, $2… I’m thinking all the HTTP headers are useful to the transcoding script, including accepted deflaters (gzip) etc.
05/07/2006 at 1:15 AM #5412rpeddeParticipant@peller wrote:
So where does one find id3tag.h? (Again, silly n00b question)
It’s part of libid3tag.
Taking this a bit further, can the mt-daapd.sh script be modified to do script execs to spawn off the corresponding transcoder? This would mean one less process per transcode, and every little bit helps on the slug. (I’ll try to do this as well, provided I get around to making the build work)
Yeah, you could, but it would make it a lot less flexible at the expense of one process (and processes are cheap on linux — plus, you already probably have a couple busyboxes running, so you’re sharing whatever pages are shareable anyway). I’d consider it to be not worth it.
I like the idea of putting the parameters in environment variables instead of $1, $2… I’m thinking all the HTTP headers are useful to the transcoding script, including accepted deflaters (gzip) etc.
Yup. Source IP, song ID, any number of other pieces of info.
-
AuthorPosts
- The forum ‘General Discussion’ is closed to new topics and replies.