Re: [Ganglia-developers] OpenBSD tweaks
On Thu, Nov 29, 2007 at 09:56:14AM -0500, Jesse Becker wrote: I've been trying to build the trunk version of Ganglia on an OpenBSD 4.1 box recently, and it isn't for the faint of heart. sadly true, building trunk isn't that easy if you are not using Fedora, indeed I didn't even though that doing a bootstrap in OpenBSD was possible. Background info: OpenBSD 4.1 (release) apr-1.2.7 libconfuse-2.5p0 automake (GNU automake) 1.9.6 autoconf (GNU Autoconf) 2.59 what about expat? 2.0.0? Everything is installed as a package, if possible, and from /usr/ports, if not. After running the bootstrap script, I call: ./configure --with-libapr=/usr/local --with-libconfuse=/usr/local if not using the python plugins then It would be probably easier to use the included libraries (specially considering that after OpenBSD 4.2 expat will be part of base) ./configure --enable-static-build Initially, the configure script was unable to find libconfuse, even though it is installed and usable. After much digging, I found that libconfuse has dependencies on libintl and libiconv. These two libraries are not included in LDFLAGS for that section of the configure script, and test compile would then fail. The error is a misleading since it *found* the library; it just couldn't compile something using it. (not blaming this on Ganglia, since it's an autoconf issue) I'm no expert on autoconf, but I think that this small patch fixes this problem on OpenBSD: --- configure.in.orig Wed Nov 28 16:34:39 2007 +++ configure.inWed Nov 28 16:53:16 2007 @@ -339,7 +339,7 @@ echo Checking for confuse if test x$libconfusepath != x test x$libconfusepath != xyes ; then CFLAGS=$CFLAGS -I$libconfusepath/include -LDFLAGS=$LDFLAGS -L$libconfusepath/lib +LDFLAGS=$LDFLAGS -L$libconfusepath/lib -lintl -liconv echo Added -I$libconfusepath/include to CFLAGS echo Added -L$libconfusepath/lib to LDLAGS fi we are going to have to probably put that conditionally for OpenBSD to avoid pulling extra dependencies for other platforms that might not need it. the problem being of course (and I didn't check that, so I might be wrong) that there might be some specific flavor for the libconfuse port which might not need that as well, and will fail to build. did you try autoconf-2.51p1? Unfortunately, the problems don't end there; there are issues with apr. For some reason, APR_CONFIG and APR_INCLUDES are not properly set in any of the resulting Makefiles, nor is set in config.log. The configure script does find apr-1-config though, as shown in the output from ./configure: Checking for apr Added -I/usr/local/include to CFLAGS Added -I/usr/local/lib to LDLAGS checking for apr_socket_send in -lapr-1... yes The ganglia utilities use the Apache Portable Runtime functions (http://www.apache.org/) Found a suitable libapr1 library The solution I found to fix this problem is much less elegant: find . -name Makefile | xargs perl -pi \ -e 's,APR_INCLUDES =.*,APR_INCLUDES = -I/usr/local/include/apr-1,;' \ -e 's,^(CFLAGS = .*),$1 -I/usr/local/include/apr-1,;' I think that if APR_CONFIG were properly set, then APR_INCLUDES (and CFLAGS!) would also be fixed as well. After doing all this, ganglia compiles, and appears to work fine. will take a look at this here and see if I can get autoconf to behave. Carlo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] OpenBSD tweaks
The configure script really needs a complete run through by somebody who is an autotools guru. There are some other library dependancies that aren't being picked up even on the linux platform. When I was building again yesterday on a clean install of SLED, after running the configure script successfully, the build still had problems with missing libfreetype, libpng and libart_lgpl. As stated by Jesse, I'm sure that there are several issues remaining with libapr1. Here is a call for all of those autotools gurus out there to give the configure script a good run through. Especially on platforms other than Linux. Brad Jesse Becker [EMAIL PROTECTED] 11/29/2007 7:56 AM I've been trying to build the trunk version of Ganglia on an OpenBSD 4.1 box recently, and it isn't for the faint of heart. Rather, I should say that debugging autoconf/automake foibles isn't for the faint of heart. Background info: OpenBSD 4.1 (release) apr-1.2.7 libconfuse-2.5p0 automake (GNU automake) 1.9.6 autoconf (GNU Autoconf) 2.59 Everything is installed as a package, if possible, and from /usr/ports, if not. After running the bootstrap script, I call: ./configure --with-libapr=/usr/local --with-libconfuse=/usr/local For some reason, libexpat is found automatically, and I don't need to indicate a location, even though it also resides in /usr/local. Initially, the configure script was unable to find libconfuse, even though it is installed and usable. After much digging, I found that libconfuse has dependencies on libintl and libiconv. These two libraries are not included in LDFLAGS for that section of the configure script, and test compile would then fail. The error is a misleading since it *found* the library; it just couldn't compile something using it. (not blaming this on Ganglia, since it's an autoconf issue) I'm no expert on autoconf, but I think that this small patch fixes this problem on OpenBSD: --- configure.in.orig Wed Nov 28 16:34:39 2007 +++ configure.inWed Nov 28 16:53:16 2007 @@ -339,7 +339,7 @@ echo Checking for confuse if test x$libconfusepath != x test x$libconfusepath != xyes ; then CFLAGS=$CFLAGS -I$libconfusepath/include -LDFLAGS=$LDFLAGS -L$libconfusepath/lib +LDFLAGS=$LDFLAGS -L$libconfusepath/lib -lintl -liconv echo Added -I$libconfusepath/include to CFLAGS echo Added -L$libconfusepath/lib to LDLAGS fi Unfortunately, the problems don't end there; there are issues with apr. For some reason, APR_CONFIG and APR_INCLUDES are not properly set in any of the resulting Makefiles, nor is set in config.log. The configure script does find apr-1-config though, as shown in the output from ./configure: Checking for apr Added -I/usr/local/include to CFLAGS Added -I/usr/local/lib to LDLAGS checking for apr_socket_send in -lapr-1... yes The ganglia utilities use the Apache Portable Runtime functions (http://www.apache.org/) Found a suitable libapr1 library The solution I found to fix this problem is much less elegant: find . -name Makefile | xargs perl -pi \ -e 's,APR_INCLUDES =.*,APR_INCLUDES = -I/usr/local/include/apr-1,;' \ -e 's,^(CFLAGS = .*),$1 -I/usr/local/include/apr-1,;' I think that if APR_CONFIG were properly set, then APR_INCLUDES (and CFLAGS!) would also be fixed as well. After doing all this, ganglia compiles, and appears to work fine. -- Jesse Becker NHGRI Linux support (Digicon Contractor) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] OpenBSD tweaks
Carlo Marcelo Arenas Belon wrote: On Thu, Nov 29, 2007 at 09:56:14AM -0500, Jesse Becker wrote: I've been trying to build the trunk version of Ganglia on an OpenBSD 4.1 box recently, and it isn't for the faint of heart. sadly true, building trunk isn't that easy if you are not using Fedora, indeed I didn't even though that doing a bootstrap in OpenBSD was possible. Surprises never cease. ;-) what about expat? 2.0.0? No problems with expat, but it's version expat-2.0.0. if not using the python plugins then It would be probably easier to use the included libraries (specially considering that after OpenBSD 4.2 expat will be part of base) ./configure --enable-static-build I've tried that, but with mixed success. --- configure.in.orig Wed Nov 28 16:34:39 2007 +++ configure.inWed Nov 28 16:53:16 2007 @@ -339,7 +339,7 @@ echo Checking for confuse if test x$libconfusepath != x test x$libconfusepath != xyes ; then CFLAGS=$CFLAGS -I$libconfusepath/include -LDFLAGS=$LDFLAGS -L$libconfusepath/lib +LDFLAGS=$LDFLAGS -L$libconfusepath/lib -lintl -liconv echo Added -I$libconfusepath/include to CFLAGS echo Added -L$libconfusepath/lib to LDLAGS fi we are going to have to probably put that conditionally for OpenBSD to avoid pulling extra dependencies for other platforms that might not need it. Sure. A quick check on a Centos4 system shows that it does *not* directly need libintl or libiconv. One clarification on this, the dependency tree is: libconfuse -- libintl -- libiconv Not: libconfuse -- libintl -- libiconv e.g. libconuse only requires libintl, not both. the problem being of course (and I didn't check that, so I might be wrong) that there might be some specific flavor for the libconfuse port which might not need that as well, and will fail to build.to did you try autoconf-2.51p1? I didn't. I can try to test that if there's a need. will take a look at this here and see if I can get autoconf to behave. Thanks. -- Jesse Becker NHGRI Linux support (Digicon Contractor) smime.p7s Description: S/MIME Cryptographic Signature - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] OpenBSD tweaks
Hi Brad: On 11/29/07, Brad Nicholes [EMAIL PROTECTED] wrote: BTW, building trunk static essentially negates everything that has been done in trunk and leaves you with basically Ganglia 3.0.5. The major enhancement to 3.1.x is the ability to load metric modules which requires libapr1 to be linked dynamically so that it can be used by the loadable modules. I am seriously considering removing the --enable-static-build and the entire srclib tree since it is basically dead code going forward with 3.1.x. The idea was to nuke the srclib tree and distribute the dependencies on platforms that do not contain them via tarballs (like for the subversion project). We just need to make a decision and move on. Cheers, Bernard - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] OpenBSD tweaks
Hi all, My vote would be to never include external dependencies in the main distribution, but that is not to say that a static build option should be eliminated. Do any of the 3rd party dependencies lack a build system to create both static and dynamic libraries? That's the only problem I can see with removing those dependencies from the ganglia build system. I suggest never removing the static build option, even if it does mean not having plugins. -Matt Carlo Marcelo Arenas Belon wrote: On Thu, Nov 29, 2007 at 09:52:14AM -0700, Brad Nicholes wrote: I am seriously considering removing the --enable-static-build and the entire srclib tree since it is basically dead code going forward with 3.1.x. Thoughts? don't you dare, --enable-static-build should be supported for anyone that feels they want that (which has been the state of affairs for gmond forever) and want a static build (even if that means they won't have plugins). of course, going forward using system dependencies instead of static ones will be all the rage and everyone will be happy using plugins and sharing plugins and we could reconsider deleting that, maybe for ganglia 4, if not 5. I agree with you though that if --enable-static-build does something else than just compile and link statically with the libraries in srclib, then it should be fixed, and IMHO fixed ASAP. Carlo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] OpenBSD tweaks
Hi Brad: On 11/29/07, Brad Nicholes [EMAIL PROTECTED] wrote: The reason why I am making that suggestion is because if somebody wants a static version then they should just continue using 3.0.5. They would be gaining nothing by building 3.1.x statically. Secondly, the static version is tied to an old version of APR 0.9.x which has never been officially released by the ASF. The only supported versions of APR outside of its use within the Apache httpd server itself are 1.x versions. Since there has been new work in APR 1.2 with regards to the multicast APIs and other bug fixes and enhancement, it gets increasingly risky to stick with an old pre-release version of APR. In addition, I would like to see Gmetad ported on top of APR as well so that it can take advantage of the portability advantages of APR. I'm not sure that work going forward would include a static build capability. Certainly not on APR 0.9.x anyway. I should have clarified my previous post a bit. When I say we will distribute the dependencies in a separate tarball, I implied _newer versions_ of the dependencies. So basically we will be updating whatever version of apr we currently have, to the latest 1.x release in this dependency tarball (we'll update the other packages too, if necessary). In this case, static builds (with the updated dependencies from the tarball) should be able to take advantage of the new features? Cheers, Bernard - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] OpenBSD tweaks
On 11/29/2007 at 11:05 AM, in message [EMAIL PROTECTED], Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote: On Thu, Nov 29, 2007 at 09:52:14AM -0700, Brad Nicholes wrote: I am seriously considering removing the --enable-static-build and the entire srclib tree since it is basically dead code going forward with 3.1.x. Thoughts? don't you dare, --enable-static-build should be supported for anyone that feels they want that (which has been the state of affairs for gmond forever) and want a static build (even if that means they won't have plugins). of course, going forward using system dependencies instead of static ones will be all the rage and everyone will be happy using plugins and sharing plugins and we could reconsider deleting that, maybe for ganglia 4, if not 5. I agree with you though that if --enable-static-build does something else than just compile and link statically with the libraries in srclib, then it should be fixed, and IMHO fixed ASAP. Carlo The reason why I am making that suggestion is because if somebody wants a static version then they should just continue using 3.0.5. They would be gaining nothing by building 3.1.x statically. Secondly, the static version is tied to an old version of APR 0.9.x which has never been officially released by the ASF. The only supported versions of APR outside of its use within the Apache httpd server itself are 1.x versions. Since there has been new work in APR 1.2 with regards to the multicast APIs and other bug fixes and enhancement, it gets increasingly risky to stick with an old pre-release version of APR. In addition, I would like to see Gmetad ported on top of APR as well so that it can take advantage of the portability advantages of APR. I'm not sure that work going forward would include a static build capability. Certainly not on APR 0.9.x anyway. Brad - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
