 |
 |
Hi Derek, it didn't find asn1.h but anyway I didn't have any of those headers installed. Now (after installing also the perl header files) it seems ok. For the autotools, I included also the output of aclocal --version But those warnings are not scarying me. Fabrizio On Wed, 2005-10-12 at 16:00 +0200, Derek Feichtinger wrote: > Hi, Fabrizio > > Some distributions have a wrapper for the autotools (initially from Mandrake, > I think) that is trying to divine what version of autotools to use, since > usually there are a number of versions installed and you can specify the > version to use in the configuration files. > > The output you show seems to derive from a mismatch (output shows that > automake-1.8 generated it. If you do "aclocal --version" you may get a > different one). > You can try once with giving explicit versions on the command line. > > aclocal-1.9 > automake-1.9 > autoconf-2.59 > ... > > The openssl header worries me more, because I actually included some tests, > one is > AC_CHECK_HEADER([openssl/ssl.h], > [],[ssltests=failed] > ) > > Can you give me more info on how it failed? What header file was missing? Then > I will improve the tests. > > Thanks, > > Derek > > On Wednesday 12 October 2005 15.39, Fabrizio Furano wrote: > > Hi, > > I am testing and using the stuff at home in my Mandriva 10.2 system. > > > > The autoconf phase works quite OK, I get only some stupid warnings, but > > I believe that they are not xrootd related. I am using automake 1.9. See > > the output below. > > > > The only problem I found is that configure does not check for the > > presence of the openssl header files in the system. Now I installed them > > and the build is working fine so far. > > > > Fabrizio > > > > ------------ > > fabrizio@oasi 15:07:46 ~/Park/xrootddev/xrootd>aclocal > > /usr/share/aclocal/gtk.m4:7: warning: underquoted definition of > > AM_PATH_GTK > > run info '(automake1.8)Extending aclocal' > > or see > > http://sources.redhat.com/automake/automake.html#Extending-aclocal > > /usr/share/aclocal/g-wrap.m4:7: warning: underquoted definition of > > AC_GWRAP_CHECK_GUILE > > /usr/share/aclocal/g-wrap.m4:23: warning: underquoted definition of > > AM_PATH_GWRAP > > /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of > > AM_PATH_AUDIOFILE > > > > > > > > fabrizio@oasi 15:07:51 ~/Park/xrootddev/xrootd>aclocal --version > > aclocal (GNU automake) 1.9.4 > > Written by Tom Tromey <[log in to unmask]> > > > > Copyright (C) 2004 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is > > NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > fabrizio@oasi 15:08:01 ~/Park/xrootddev/xrootd> > > --------------- > > > > Fabrizio > > > > On Wed, 2005-10-12 at 09:42 +0200, Derek Feichtinger wrote: > > > Hi, Peter > > > > > > > Do you have any objection to simply maintaining an updated version > > > > of ./configure in CVS? > > > > > > My experience shows, that this does not work well. It would mean > > > committing all the autotools generated files to CVS (aclocal.m4, all > > > Makefile.in, etc.). Since autotools uses timestamps to trigger rebuilding > > > of its own meta files (e.g. when you edit a Makefile.am, when you change > > > configure.ac,...), the freshly checked out CVS distribution tends to want > > > to rebuild parts because of confused timestamps. This forces you to have > > > a matching version of autotools on your system anyways. > > > > > > I propose that I install a little bootstrap script that runs the > > > libtoolize, aclocal,automake,autoconf commands for convenience. You just > > > loose a few seconds for the bootstrap procedure (but sure. You need to > > > have the autotools installed). > > > > > > Building for a non developer should always be done from a generated > > > tarball (and this is the portable way to do it). > > > > > > There is a maintainer mode option in autotools which prevents rebuilding > > > of the automake generated files, but it makes work more complicated. > > > > > > Cheers, > > > Derek > > > > > > On Tuesday 11 October 2005 19.13, Peter Elmer wrote: > > > > Hi Derek, > > > > > > > > Do you have any objection to simply maintaining an updated version > > > > of ./configure in CVS? Although it is not quite as "from source" > > > > as using the autotools to build it from scratch each time one checks > > > > out from CVS, it would simplify things for most developers most of the > > > > time. We just need to make sure it is updated when somebody makes > > > > changes which require it to be updated. > > > > > > > > Pete > > > > > > > > On Tue, Oct 11, 2005 at 11:47:16AM +0200, Derek Feichtinger wrote: > > > > > Ciao, Fabrizio > > > > > > > > > > This is what I mentioned in my first migration mail to the list. You > > > > > need reasonably new versions of the autotools (libtool should be very > > > > > new to correctly produce files which work on Macs). > > > > > > > > > > ------------------------------ > > > > > > > > > > > To use the new autotools build: > > > > > > You should install automake > 1.6, autoconf-2.59 and libtool 1.5.18 > > > > > > on your system. > > > > > > > > > > ------------------------------- > > > > > > > > > > Best you get them as tarballs from the GNU site. They build very fast > > > > > (first get Autoconf, then Automake and then libtool). The Solaris > > > > > machines at SLAC seem to have really ancient versions which have been > > > > > out of use for several years (early versions of Autoconf required a > > > > > configure.in file. Now this has been renamed configure.ac to prevent > > > > > confusion with the files on which configure acts, which are all named > > > > > *.in) > > > > > > > > > > Cheers, > > > > > Derek > > > > > > > > > > On Tuesday 11 October 2005 11.34, you wrote: > > > > > > Hi, thank you. > > > > > > > > > > > > One more question. Is there anything special I have to do to work > > > > > > under Solaris? > > > > > > For instance, aclocal fails on shire02 at slac from a fresh > > > > > > checkout, it says that it needs a configure.in file. From a Linux > > > > > > machine (noric02) instead it works fine. > > > > > > > > > > > > Any hint? > > > > > > > > > > > > > > > > > > Fabrizio > > > > > > > > > > > > Derek Feichtinger wrote: > > > > > > > Hi, Fabrizio > > > > > > > > > > > > > > Take a look at the Makefile.am in the XrdClient directory: > > > > > > > > > > > > > > If you want to recourse into subdirectories, you just add a > > > > > > > > > > > > > > SUBDIRS = dir1 dir2 dir3 > > > > > > > > > > > > > > statement. > > > > > > > > > > > > > > Build targets in automake are specified via directives like > > > > > > > > > > > > > > bin_PROGRAMS = myprogram1 myprogram2 > > > > > > > > > > > > > > The prefix (bin) defines where the file will be installed, the > > > > > > > type (PROGRAM) defines what kind of targets should be built. > > > > > > > > > > > > > > There is a special prefix "check". This specifies targets that > > > > > > > will never be installed and that get only built when a "make > > > > > > > check" is given. This is specially designed for tests that are > > > > > > > run after the initial build to check the package's sanity. > > > > > > > The variable TESTS hold the name of the tests to be run. > > > > > > > > > > > > > > "Info Automake" should provide you with quite some information as > > > > > > > well as the autobook (chapter 7.7): > > > > > > > http://sources.redhat.com/autobook/autobook/autobook_toc.html > > > > > > > > > > > > > > I can gladly help you to get started if you have specific > > > > > > > questions. > > > > > > > > > > > > > > Cheers, > > > > > > > Derek > > > > > > > > > > > > > > On Tuesday 11 October 2005 10.35, Fabrizio Furano wrote: > > > > > > >>Hi, > > > > > > >> > > > > > > >> just for the records, is there anything special I have to do if > > > > > > >> I want to add new files/dirs to XrdClient with the new building > > > > > > >> scheme? > > > > > > >> > > > > > > >> If everything goes well, in the next period I'd like to add > > > > > > >> some modules and a directory containing test programs. How do I > > > > > > >> do that? > > > > > > >> > > > > > > >>Fabrizio > > > > > > >> > > > > > > >>Derek Feichtinger wrote: > > > > > > >>>I forgot: > > > > > > >>> > > > > > > >>>to reduce the current compilation output, type > > > > > > >>> > > > > > > >>>make silent > > > > > > >>> > > > > > > >>>(just filters the compilation lines with sed, stderr still > > > > > > >>> visible). At some point one could introduce a config.h file, > > > > > > >>> which is used to pass all the compile switches determined by > > > > > > >>> configure to the preprocessor, so the awfully long compile > > > > > > >>> lines would get shorter. But this requires adding a include > > > > > > >>> directive to all source files, so I did not want to do it now. > > > > > > >>> > > > > > > >>>To build the test files (e.g. for crypto and mon stuff) > > > > > > >>> > > > > > > >>>make check > > > > > > >>> > > > > > > >>>They will never be installed by make install (the check target > > > > > > >>> is just for compiling and running a package's tests. At some > > > > > > >>> point one could add some active tests to this target). > > > > > > >>> > > > > > > >>> > > > > > > >>>make distcheck > > > > > > >>> > > > > > > >>>this will ensure, that a generated tarball can indeed compile. > > > > > > >>> > > > > > > >>>Cheers, > > > > > > >>>Derek > > > > > > > > > > -- > > > > > Dr. Derek Feichtinger Tel: +41 22 767 10 07 > > > > > LCG/ARDA Group email: > > > > > [log in to unmask] CERN > > > > > http://people.web.psi.ch/feichtinger CH-1211 Genève 23 > > > > > > > > ----------------------------------------------------------------------- > > > >-- Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) > > > > 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, > > > > Switzerland > > > > ----------------------------------------------------------------------- > > > >-- >