On Sun, Mar 16, 2008 at 09:16:01PM -0400, Jesse Becker wrote:
> On Sun, Mar 16, 2008 at 8:26 PM, Carlo Marcelo Arenas Belon
> <[EMAIL PROTECTED]> wrote:
> > On Sun, Mar 16, 2008 at 06:27:00PM -0400, Jesse Becker wrote:
> >  >
> >  > So then the build process for trunk is basically broken for non-Linux 
> > systems?
> >
> >  it always was; before it used to work reliably only in fedora or centos 
> > AFAIK
> >  which is what we had been using to do bootstraps and releases for all the 
> > 3.0
> >  series.
> 
> Until "recently" it worked fine on OpenBSD, and now it doesn't.

Wrong.  Just because it didn't error out, doesn't mean it worked fine; because
the bootstrap was using a pregenerated in 2004 ltmain.sh, from libtool version
1.5.8, with everything else coming from libtool 1.5.22.

"recently" has a version number (r1065); where this failure is (as
described before) a bug because autoreconf wasn't configured YET to work in
OpenBSD and the old bootstrap was missing the libtoolize call to create
ltmain.sh and the rest of the libtool generated files.

> If this needs some time to stablize, that's fine, but bootstrapping
> should work, IMO, on all operating systems if possible, but at *least*
> Linux, *BSD, Solaris, and AIX (as those seem to be the most common
> platforms).

since bootstrap doesn't work in cygwin (windows being the second most popular
OS where ganglia runs) I think this has a long way to become true.

doing a bootstrap in Centos 4.6 (which uses libtool 1.5.6) was very likely to
work fine, but not using any other linux (try it on Gentoo Linux that uses
1.5.22).

the changes started in r1044 enable more platforms to have a correct bootstrap
as you suggested.

> > >  I notice that two
> > > different ltmain.sh files were removed from SVN in r1066.  The one in
> >  > libmetrics/ is what is causing this build failure.
> >
> >  because libtoolize --copy --force is missing in bootstrap to regenerate
> >  them and in your system autoreconf is not in /usr/bin
> 
> Well that's an easy fix:

Haven't yet seen a patch, so
Committed revision 1069

> >  > I have that already, actually.  My full configure invocation is:
> >  >
> >  > ./configure \
> >  > CC='ccache gcc' CXX='ccache g++' \
> >  > CFLAGS='-O2 -I/usr/local/include -I/usr/X11R6/include' \
> >  > LDFLAGS='-L/usr/local/lib -L/usr/X11R6/lib -lintl -liconv'  \
> >  > --with-gmetad --enable-status         \
> >  > --with-libapr=/usr/local                     \

it is better if you let apr configure itself with apr-1-config here.  this is
an incorrect use of --with-libapr because apr from ports is not installed with
its headers in /usr/local/include

> >  > --with-libconfuse=/usr/local              \
> >  > --with-libexpat=/usr/local                  \
> >  > --with-librrd=/usr/local                      \
> >  > --prefix=/home/jbecker/Ganglia/install/
> >  >
> >  > I have to add "-lintl" and "-liconv" to LDFLAGS for configure to succeed.
> >
> >  you shouldn't need to, and therefore there is another bug somewhere there.
> >  the libtool library (libconfuse.la) should instruct libtool about the extra
> >  dependencies required for you.
> 
> Well, given the current libtool issues, it's reasonable to let this
> one slide for now.  I can't say that I really trust libtool to do its
> job at the moment.  ;-)

This is not a libtool problem, it is a libconfuse problem which has
been fixed with 2.6 (that is what is being packaged for OpenBSD 4.3), and the
configure failure is doing its job to tell you that you can't use your
libconfuse as installed (so you have to do a workaround by adding libraries)

Indeed the output of config.log is very clear on that :

configure:19707: checking for cfg_parse in -lconfuse
configure:19737: gcc -o conftest -g -O2 -I/usr/local/include
-L/usr/local/lib
conftest.c -lconfuse  -lapr-1 -lpthread  >&5
/usr/local/lib/libconfuse.so.0.0: warning: strcpy() is almost always misused,
pl
ease use strlcpy()
/usr/local/lib/libconfuse.so.0.0: warning: strcat() is almost always misused,
pl
ease use strlcat()
/usr/local/lib/libconfuse.so.0.0: undefined reference to
`libintl_bindtextdomain
'
/usr/local/lib/libconfuse.so.0.0: undefined reference to `libintl_dgettext'
collect2: ld returned 1 exit status
configure:19743: $? = 1

> >  libiconv and gettext are not ganglia's dependencies, you need
> 
> Correct, but libconfuse needs them at link-time, and the configure
> scripts aren't currently catching this (which they should).

Adding a configure time test for this libconfuse problem might be a good idea,
considering how confusing it seems to be, but it is not configure job to
fix a broken library dependency tracking on its own and unless instructed to do
so.

Feel free to commit a macro fix for that in configure.in

Carlo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to