From: Orama A. <ora...@gm...> - 2009-03-25 20:52:37
|
Hello, First of all I would like to say big thanks to Savonet team for great software. The purpose of this email is to share my experiences of building liquidsoap on FreeBSD 7, which was difficult but finally positively resulted. Perhaps some of this information could be used in future development to make building on BSD platforms easier. I have played with liquidsoap for some time on local Ubuntu machine, which was easily installed from debian package. The real life server unfortunately (or luckily) was FreeBSD 7, so I had no other choice as to try to build it from source. My setup required streaming of MP3 to Icecast server, so these are FreeBSD ports I have installed on top of exosting Icecast/liblame setup: lang/ocaml devel/ocaml-findlib audio/libao audio/jack audio/libmad audio/taglib audio/faac audio/faad audio/ladspa audio/soundtouch multimedia/gavl devel/ocaml-pcre audio/libvorbis Needless to mention that your ports tree must be uptodate. Next was to edit PACKAGES file to comment out things which I did not need and/or which are not available on FreeBSD or most probably will not work: #ocaml-portaudio-0.1.2 #ocaml-alsa-0.1.3 #ocaml-pulseaudio-0.1.0 #ocaml-bjack-0.1.2 #ocaml-xmlplaylist-0.1.1 #ocaml-lastfm-0.1.3 The reason for excluding JACK I will explain later (build problem) Xmlplaylist was excluded because there is no FreeBSD port for ocaml-xml-light library. Next it was necessary to set some environment variables; setenv CPPFLAGS -I/usr/local/include setenv LDFLAGS -L/usr/local/lib then ./configure could be run with no special attributes. Due to problem with gmake / make, the fastest (but obviously not the proper) way was to edit Makefile and replace all occurences of "make" with "gmake". Those were only few, and it worked fine. gmake: ------------ The build immediately started to complain about linker problems: /usr/bin/ld -lshout ld: cannot find -lshout and so forth for each library. In fact, they are installed in /usr/local/lib, but expected in /usr/lib. The reasons fir this are beyond my uderstanding and after several hours trying and googling I ended up with creating symlinks for each and every missing .so file: example: ln -s /usr/local/lib/libvorbisfile.so /usr/lib/libvorbisfile.so ln -s /usr/local/lib/libmp3lame.so /usr/lib/libmp3lame.so etc... This is obviously dumb solution, but please excuse me my way of problem solving ... After this all went file with except of JACK, which, I belive has some mistake in configfile related to LDFLAGS or CPPFLAGS because it produces following error: gmake[3]: `libbjack_stubs.a' is up to date. ocamlmklib \ -o bjack_stubs jack_stubs.o jack_wrapper.o -l-L/usr/local/lib -lsamplerate -ljack \ /usr/bin/ld: cannot find -l-L/usr/local/lib gmake[3]: *** [dllbjack_stubs.so] Error 2 After disabling JACK, all went fine. gmake install: ----------------------- Almost all is fine, the only thing is that you have to manually create user liquidsoap and group liquidsoap before running gmake install. I have chosen nologin shell due to security reason, but at the end could not find the way how to start it as liquidsoap user, so I started it as regulat unprivileges user. Also log file and pid file directory must be created manually. That is basically all, it started up without single glitch. Thanks again for your work and I hope my 2cents will help other users who may have similar problem |
From: David B. <dav...@gm...> - 2009-03-26 01:45:58
|
Hi, Thanks for the feedback, it might indeed be useful. 2009/3/25 Orama Avis <ora...@gm...>: > setenv CPPFLAGS -I/usr/local/include > setenv LDFLAGS -L/usr/local/lib Okay. There might also be a way to pass them as parameters to configure. > Due to problem with gmake / make, the fastest (but obviously not the proper) > way was to edit Makefile and replace all occurences of "make" with "gmake". > Those were only few, and it worked fine. We should get rid of those. A quick check showed that many libraries call make in the doc target, instead of calling $(MAKE) which would implicitly be gmake. In liquidsoap, the situation might not be ideal: the MAKE variable is set in Makefile.defs, depending on what configure detects -- I'm wondering if this definition is ever needed. > gmake: > ------------ > > The build immediately started to complain about linker problems: > > /usr/bin/ld -lshout > ld: cannot find -lshout This is also bad. The problem should be reported at configure-time. It's a matter of passing the right variable at the right place -- easy to say.. > /usr/bin/ld: cannot find -l-L/usr/local/lib > gmake[3]: *** [dllbjack_stubs.so] Error 2 Yuk. > gmake install: > ----------------------- > > Almost all is fine, the only thing is that you have to manually create user > liquidsoap and group liquidsoap before running gmake install. > Also log file and pid file directory must be created manually. This is all normal. We leave the creation of users and directories to the user, or the distro-specific packages. Have fun! -- David |
From: Romain B. <to...@ra...> - 2009-03-26 17:56:57
|
Le Thursday 26 March 2009 02:34:23 David Baelde, vous avez écrit : > Hi, Hi all ! Thanks for your nice feedback ! > Thanks for the feedback, it might indeed be useful. > > 2009/3/25 Orama Avis <ora...@gm...>: > > setenv CPPFLAGS -I/usr/local/include > > setenv LDFLAGS -L/usr/local/lib > > Okay. There might also be a way to pass them as parameters to configure. Indeed, calling configure like: ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" should make this permanent, including during build. > > Due to problem with gmake / make, the fastest (but obviously not the > > proper) way was to edit Makefile and replace all occurences of "make" > > with "gmake". Those were only few, and it worked fine. > > We should get rid of those. A quick check showed that many libraries > call make in the doc target, instead of calling $(MAKE) which would > implicitly be gmake. In liquidsoap, the situation might not be ideal: > the MAKE variable is set in Makefile.defs, depending on what configure > detects -- I'm wondering if this definition is ever needed. Ok, I just fixed this in trunk/ > > gmake: > > ------------ > > > > The build immediately started to complain about linker problems: > > > > /usr/bin/ld -lshout > > ld: cannot find -lshout > > This is also bad. The problem should be reported at configure-time. > It's a matter of passing the right variable at the right place -- easy > to say.. As said above, this should be permanent when added at configure time. > > /usr/bin/ld: cannot find -l-L/usr/local/lib > > gmake[3]: *** [dllbjack_stubs.so] Error 2 > > Yuk. Humm.. Strange issue.. I am currently unable to find the culprit for this.. If you can give more detailed informations, probably we could fix it.. > > gmake install: > > ----------------------- > > > > Almost all is fine, the only thing is that you have to manually create > > user liquidsoap and group liquidsoap before running gmake install. > > Also log file and pid file directory must be created manually. > > This is all normal. We leave the creation of users and directories to > the user, or the distro-specific packages. Humm.. from liquidsoap/Makefile: # User ${user} and group ${group} are expected to exist. # They are defined in Makefile.defs, written by configure. but then it will try even if they don't exist.. Probably we should issue a warning and not fail when user and group do not exist.. What is the most standard way to check if a user/group exist in both linux and BSD ? Romain |
From: Orama A. <ora...@gm...> - 2009-03-26 20:55:01
|
Good afternoon: 2009/3/26 Romain Beauxis <to...@ra...> > > Le Thursday 26 March 2009 02:34:23 David Baelde, vous avez écrit : > > Hi, > > Hi all ! > > Thanks for your nice feedback ! > > > Thanks for the feedback, it might indeed be useful. > > > > 2009/3/25 Orama Avis <ora...@gm...>: > > > setenv CPPFLAGS -I/usr/local/include > > > setenv LDFLAGS -L/usr/local/lib > > > > Okay. There might also be a way to pass them as parameters to configure. > > Indeed, calling configure like: > ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" > should make this permanent, including during build. > > > > Due to problem with gmake / make, the fastest (but obviously not the > > > proper) way was to edit Makefile and replace all occurences of "make" > > > with "gmake". Those were only few, and it worked fine. > > > > We should get rid of those. A quick check showed that many libraries > > call make in the doc target, instead of calling $(MAKE) which would > > implicitly be gmake. In liquidsoap, the situation might not be ideal: > > the MAKE variable is set in Makefile.defs, depending on what configure > > detects -- I'm wondering if this definition is ever needed. > > Ok, I just fixed this in trunk/ > thank you, I will have clean FreeBSD install and test it again from trunk and will let you know. > > > gmake: > > > ------------ > > > > > > The build immediately started to complain about linker problems: > > > > > > /usr/bin/ld -lshout > > > ld: cannot find -lshout > > > > This is also bad. The problem should be reported at configure-time. > > It's a matter of passing the right variable at the right place -- easy > > to say.. > > As said above, this should be permanent when added at configure time. > > > > /usr/bin/ld: cannot find -l-L/usr/local/lib > > > gmake[3]: *** [dllbjack_stubs.so] Error 2 > > > > Yuk. > > Humm.. Strange issue.. I am currently unable to find the culprit for this.. If > you can give more detailed informations, probably we could fix it.. I do not have those logs anymore, but I will do new build from trunk and send them to you. > > > > gmake install: > > > ----------------------- > > > > > > Almost all is fine, the only thing is that you have to manually create > > > user liquidsoap and group liquidsoap before running gmake install. > > > Also log file and pid file directory must be created manually. > > > > This is all normal. We leave the creation of users and directories to > > the user, or the distro-specific packages. > > Humm.. from liquidsoap/Makefile: > # User ${user} and group ${group} are expected to exist. > # They are defined in Makefile.defs, written by configure. > but then it will try even if they don't exist.. > > Probably we should issue a warning and not fail when user and group do not > exist.. What is the most standard way to check if a user/group exist in both > linux and BSD ? > I found this in pkg-install file for apache22 port in FreeBSD, maybe it can give some hint about how they do it (seems they use pw): if ! pw groupshow "${WWWGROUP}" 2>/dev/null 1>&2; then if pw groupadd ${WWWGROUP} -g ${WWWGID}; then echo "Added group \"${WWWGROUP}\"." else echo "Adding group \"${WWWGROUP}\" failed..." exit 1 fi fi if ! pw usershow "${WWWUSER}" 2>/dev/null 1>&2; then if pw useradd ${WWWUSER} -u ${WWWUID} -g ${WWWGROUP} -h - \ -s "/sbin/nologin" -d "/nonexistent" \ -c "World Wide Web Owner"; \ then echo "Added user \"${WWWUSER}\"." else echo "Adding user \"${WWWUSER}\" failed..." exit 1 fi fi > > Romain |
From: Orama A. <ora...@gm...> - 2009-04-08 22:42:08
|
Good afternoon, I am now retrying FreeBSD build, this time from trunk. My configure args are following: ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" however make still is unable find libs: gmake[3]: `libao_stubs.a' is up to date. ocamlmklib \ -o ao_stubs ao_stubs.o -lao \ /usr/bin/ld: cannot find -lao I have checked, libao.so is in /usr/local/lib Do I need to pass anything else to configure? thanks, 2009/3/26 Orama Avis <ora...@gm...>: > Good afternoon: > > 2009/3/26 Romain Beauxis <to...@ra...> >> >> Le Thursday 26 March 2009 02:34:23 David Baelde, vous avez écrit : >> > Hi, >> >> Hi all ! >> >> Thanks for your nice feedback ! >> >> > Thanks for the feedback, it might indeed be useful. >> > >> > 2009/3/25 Orama Avis <ora...@gm...>: >> > > setenv CPPFLAGS -I/usr/local/include >> > > setenv LDFLAGS -L/usr/local/lib >> > >> > Okay. There might also be a way to pass them as parameters to configure. >> >> Indeed, calling configure like: >> ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" >> should make this permanent, including during build. >> >> > > Due to problem with gmake / make, the fastest (but obviously not the >> > > proper) way was to edit Makefile and replace all occurences of "make" >> > > with "gmake". Those were only few, and it worked fine. >> > >> > We should get rid of those. A quick check showed that many libraries >> > call make in the doc target, instead of calling $(MAKE) which would >> > implicitly be gmake. In liquidsoap, the situation might not be ideal: >> > the MAKE variable is set in Makefile.defs, depending on what configure >> > detects -- I'm wondering if this definition is ever needed. >> >> Ok, I just fixed this in trunk/ >> > > thank you, I will have clean FreeBSD install and test it again from > trunk and will let you know. > >> > > gmake: >> > > ------------ >> > > >> > > The build immediately started to complain about linker problems: >> > > >> > > /usr/bin/ld -lshout >> > > ld: cannot find -lshout >> > >> > This is also bad. The problem should be reported at configure-time. >> > It's a matter of passing the right variable at the right place -- easy >> > to say.. >> >> As said above, this should be permanent when added at configure time. >> >> > > /usr/bin/ld: cannot find -l-L/usr/local/lib >> > > gmake[3]: *** [dllbjack_stubs.so] Error 2 >> > >> > Yuk. >> >> Humm.. Strange issue.. I am currently unable to find the culprit for this.. If >> you can give more detailed informations, probably we could fix it.. > > I do not have those logs anymore, but I will do new build from trunk > and send them to you. > >> >> > > gmake install: >> > > ----------------------- >> > > >> > > Almost all is fine, the only thing is that you have to manually create >> > > user liquidsoap and group liquidsoap before running gmake install. >> > > Also log file and pid file directory must be created manually. >> > >> > This is all normal. We leave the creation of users and directories to >> > the user, or the distro-specific packages. >> >> Humm.. from liquidsoap/Makefile: >> # User ${user} and group ${group} are expected to exist. >> # They are defined in Makefile.defs, written by configure. >> but then it will try even if they don't exist.. >> >> Probably we should issue a warning and not fail when user and group do not >> exist.. What is the most standard way to check if a user/group exist in both >> linux and BSD ? >> > > I found this in pkg-install file for apache22 port in FreeBSD, maybe > it can give some hint about how they do it (seems they use pw): > > if ! pw groupshow "${WWWGROUP}" 2>/dev/null 1>&2; then > if pw groupadd ${WWWGROUP} -g ${WWWGID}; then > echo "Added group \"${WWWGROUP}\"." > else > echo "Adding group \"${WWWGROUP}\" failed..." > exit 1 > fi > fi > > if ! pw usershow "${WWWUSER}" 2>/dev/null 1>&2; then > if pw useradd ${WWWUSER} -u ${WWWUID} -g ${WWWGROUP} -h - \ > -s "/sbin/nologin" -d "/nonexistent" \ > -c "World Wide Web Owner"; \ > then > echo "Added user \"${WWWUSER}\"." > else > echo "Adding user \"${WWWUSER}\" failed..." > exit 1 > fi > fi > > > > >> >> Romain > |
From: Romain B. <to...@ra...> - 2009-04-08 23:58:47
|
Le Thursday 09 April 2009 00:41:57 Orama Avis, vous avez écrit : > Good afternoon, Hi ! > I am now retrying FreeBSD build, this time from trunk. > > My configure args are following: > > ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" > > however make still is unable find libs: > > gmake[3]: `libao_stubs.a' is up to date. > ocamlmklib \ > -o ao_stubs ao_stubs.o -lao \ > > /usr/bin/ld: cannot find -lao > > I have checked, libao.so is in /usr/local/lib Indeed, I had not seen this. Apparently the -L option is not passed to ocamlmklib. I have found a variable which makes it work: Index: Makefile.in =================================================================== --- Makefile.in (révision 6515) +++ Makefile.in (copie de travail) @@ -30,6 +30,7 @@ ACLIBS = @LIBS@ @libao_LIBS@ LDFLAGS = @LDFLAGS@ @libao_LDFLAGS@ CLIBS = $(ACLIBS:-l%=%) +LIBDIRS = $(LDFLAGS:-L%=%) CC = @CC@ CFLAGS = @CFLAGS@ @libao_CFLAGS@ -Wall -DCAML_NAME_SPACE CPPFLAGS = @CPPFLAGS@ Using this patch, the compilation should hopefully be sucessful. I don't know however if this is the good place to add this and if the LDFLAGS will always contain value of the form -L%.. I have added our specialist for these questions, Julien, which may help in solving this issue.. Romain |