On Fri, Jul 04, 2008 at 02:30:37PM +0100, [EMAIL PROTECTED] wrote: > > make failed running rpcgen. I installed gmake and the problem went away
that is why the INSTALL document asks for GNU Make and warns about using any other make. > gawk wasn't present, and make failed again - maybe configure should > check for gmake, gawk and GNU ld? you just need a POSIX awk AFAIK, SUN's provided awk in /usr/xpg4/bin/awk should be enough if you have it on your path. it shouldn't need GNU's binutils though, specially if the compiler is instructed instead to use SUN's in /usr/ccs. adding checks for them in configure is problematic, because BSD make also works AFAIK, and the fact that we require GNU make or GNU gcc is IMHO a portability bug which I'd rather fix than patch around. > Finally, make failed again with an error about EM_386. I re-ran > configure: > > ./configure --prefix=/usr/local --build=sparc > > and that problem was eliminated. this is strange, will try to reproduce it, but I don't have any Solaris 8 SPARC available. I suspect it is a problem with using GNU's binutils though but a configure/build log will be needed to pinpoint the problem (maybe transitory as --build=sparc isn't doing anything AFAIK, as it should be instead sparc-sun-solaris or even better left for configure to guess) I suspect there might be a problem with your bootstrapping (until recently that only worked reliably in RedHat/CentOS/Fedora Linux hosts) so use instead a snapshot. fresh snapshots for 3.1 are available from : http://tapir.sajinet.com.pe/ganglia/ > Next problem, errors about SIOCGIFADDR, I had to add > > #include <sys/sockio.h> > > to this file: > > lib/inetaddr.c SIOCGIFADDR is not needed there, what error you had? > In lib/apr_net.c, the #ifdef SOLARIS doesn't work, causing a similar > error - I removed the line #ifdef SOLARIS and it compiles properly. that is odd, SOLARIS is defined in config.h at configure time and was there specially to fix that problem as the comments explain > Then I got this error: > > /usr/ccs/bin/ld -assert pure-text -Bstatic -o > .libs/libganglia-3.1.0.999.so.0.0 .libs/gm_protocol_xdr.o > .libs/become_a_nobody.o .libs/debug_msg.o .libs/daemon_init.o > .libs/file.o .libs/dotconf.o .libs/error_msg.o .libs/ganglia.o > .libs/hash.o .libs/inetaddr.o .libs/llist.o .libs/my_inet_ntop.o > .libs/rdwr.o .libs/readdir.o .libs/tcp.o .libs/scoreboard.o > .libs/apr_net.o .libs/libgmond.o > ld: fatal: file pure-text: open failed: No such file or directory > > That was resolved by installing GNU binutils (including ld) into > /usr/local > > Using > > LD=/usr/local/bin/ld ./configure --prefix=/usr/local --build=sparc > > gave me more progress, but then I got more errors about /usr/ccs/bin/ld, > so I remove /usr/ccs/bin/ld from the path > > Now I have a gmond, but no modules, so I tried configure again: > > ./configure --prefix=/usr/local --build=sparc --with-gnu-ld > --enable-shared > > But still no modules - any suggestions? I did see this message during > make, is this an OS limitation or a configuration issue? I don't recall, the way we do modules is very Linux specific and so some other platforms won't be able to have a working build with modules (Windows or AIX for example). I think the last tests I did with OpenSolaris x86 were using modules so there might be hope there, and I had some successful builds with Solaris 7 or 8 x86, but those were most likely using --enable-static-build. Adding instructions to the INSTALL, README or the wiki should hopefully prevent future users to go through so much pain to have a working build. > *** Warning: inter-library dependencies are not known to be supported. > *** All declared inter-library dependencies are being dropped. > > *** Warning: libtool could not satisfy all declared inter-library > *** dependencies of module modsys. Therefore, libtool will create > *** a static module, that should work as long as the dlopening > *** application is linked with the -dlopen flag. > > I then tried another approach: > > ./configure --prefix=/usr/local --build=sparc --enable-static-build && > make > > and I now have a working gmond, but I would prefer to use modules. > > One final issue: my custom module failed to link, because it involves > multiple object files, I had to make some manual modifications to > gmond/Makefile to get around this problem when doing a static build. On > Linux, the same module is successfully linked into a .so without any > Makefile changes. this is most likely because the convenience library that is being built has unresolved external dependencies that the linker resolves at link time in Linux pulling the missing extra object files. it is broken in both environments but you will only see it in Solaris (or any other UNIX where that lazy binding is not enabled), since it seems you are using our build system to add your module to the source, you will need to build your own snapshots with your added files (use a modern RedHat like Linux box to do that) and be sure that all your files are added to the corresponding *_SOURCES variable in Makefile.am before bootstrapping. Carlo ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
