Hi Steve, Jens Ivar, and others, Since your mails are related, I'll answer both now. On Thu, 19 Jul 2001 09:21:52 -0500 "Stephen J. Sanders" <ssanders@ku.edu> wrote concerning ": Re: problem with make install (for brat)": > Hi Christian, > > Thanks for fixing the Makefile stuff. You're welcome. > RPM packages for ROOT? Didn't know they existed. I would probably need a > SRPM in any case--unfortunately, the PPC build always seems to be left > behind. There are no "official" RPMs of ROOT, only unofficiual non-distributable RPMs. In all modesty I'm the one that made some stuff for ROOT so that you can build Debian GNU/Linux and RPM packages of ROOT. Take a look in README/INSTALL - yes RTFM. Ok, it's really simple, at least on Debian where you just do make debian Please note, that it may not succed at the moment, since ROOT has added a lot of new stuff, and I haven't had time to follow up on that. Notice that I've made some RPMs and Debian GNU/Linux packages of Pythia, avaliable from http://cholm.home.cern.ch/cholm It shouldn't be too hard to also make RPMs and Debian GNU/Linux packages of BRAT, BREG, BROP, BRAG, CRASH and so on, since we're now using a sensible build system :-) > However, I did build ROOT (and BRAT) into /usr/local -- This seems > to be a pretty clean way of making all the packages readily > available. Exactly. That's why I liked the default prefix /usr/local! > Sorry about the lock...I didn't think things had gotten that far. While > updating my systems to the latest brat, brag, ..., I decided to also > configure an intel box here with the latest redhat. I thought going > mainstream would be easier--Wrong! Well, that's Redhat for you. Use Debian GNU/Linux instead. A bit more hands-on approach, but the stabilty you get far outweights the trouble [Please note this is a Debian guy talking :-), but with loads of experience in installing Redhat]. > Got ARLA installed all right, after discovering this bit about > RedHat shipping a compiler that won't compile the kernel...(guess > one really should read the README files...), What can I say, Redhat sucks big time! Also, never EVER trust a package you didn't get from the upstream editor, from the CDROMS, or you haven't made yourself [Incidently you should ofcourse trust my packages :-)] > but it looks like cvs won't run correctly with this configuration. > My guess is that I have a buggy kernel, or there is a problem with > the latest ARLA (0.35.5). Did you recompile the arla kernel module? You probably need to do that (and yes, read the README file!) If you made a custom kernel, even though it's the same version as the default one, you'll probably need to recompile extra modules, like ARLA, ALSA, and so on, since some options affect all modules (for example module loading!, kernel loader, and so on). > In any case, when doing a cvs checkout brat, I get > > getcvs [checkout aborted]: cannot seek to end of history file: > /afs/rhic/brahms/BRAHMS_CVS/CVSROOT/history: Invalid argument "getcvs"? Is that your alias for cvs -d /afs/rhic/brahms/BRAHMS_CVS? I prefer to call it brahms-cvs, but what the heck. > Any suggestions other than to update the kernel, or downgrade ARLA? > I checked that I do have the latest cvs rpms. I also installed an > earlier cvs release and had the same problem... I've got two guess' why this may be going wrong: * You need to recompile the ARLA module with your custom kernel setup. * RCF is picky about which kinds of AFS clients is allowed to connect to AFS. I had some problems connecting with the OpenAFS client, even though it's bloody close to Transarc AFS. Suggestions: * Try to recompile the kernel module * Try another AFS client (OpenAFS - rpms exist, Transarc AFS - avaliable for free for all users of RCF) * Open a trouble ticket. On Thu, 19 Jul 2001 15:53:18 -0100 (GMT+1) Jens Ivar Jordre <jens@fi.uib.no> wrote concerning ": Bug or feature (Was: problem with make install (for brat))": > On Thu, 19 Jul 2001, Christian Holm Christensen wrote: > > > Glad to see someone like to install in /usr/local! > > Put it where it belongs!! :) Yeah! > When I did this on my system the other day, I first built ROOT-3.01.05. > Configuring ROOT I of course added --prefix=/usr/local. The first time I > ran configure I omitted the --libdir=/usr/local/lib flag. The ROOT library > files were therefore put into /usr/local/lib/root. If you use the RPMs, this is alright. See below. > Running bratroot after building BRAT-2.0.X I ran into problems with the > run-time linker as it does not search /usr/local/lib/root. The reason I > believe is that when linking bratroot, there is no information about the > location of the root libraries: If ROOT was build using Autotools (I've tried to convince Fons, and he didn't really object, except one has to work out something for Windoze and M$VC), then it'd work automatically! Alas, ROOT uses it's own build system. > I therefore built ROOT again, this time configuring with > --libdir=/usr/local/lib. Building BRAT and running bratroot everything > went fine. That's why I wrote what I wrote in that email some time ago. > I think one should be able to place the ROOT libraries in a subdirectory > <ROOT prefix>/lib/root to ease the library bookkeeping. Having my own > system I can of course modify my /etc/ld.so.conf, but some people do not > have this possibility. And I guess that by including the -Wl linker > options the idea is that one should not have to set the LD_LIBRARY_PATH > environment variable. Yeps, but if you use the RPMs of Debian GNU/Linux packages then this is done for you, since it's done by the system operator! Also, it would be nice if ROOT's libraries was named like libRoot... so that stupid name clashes like libMatrix could be avoided! > Any thoughts anyone? Anytime! I did do some extension to the root.m4 script to get the library path from the root-config --libs output. However, the problem is, that not all architectures support the -rpath option to the linker, or it may be another option (like on Solaris I believe). Libtool can take care of some of this, if you link incremental the BRAT libraries to the ROOT libraries, but I didn't really look too hard into it. The best solution, recommended by all serious GNU/Linux distributions (read Debian) is to _not_ use -rpath, but add paths in /etc/ld.so.conf. Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b30 : Thu Jul 19 2001 - 12:12:22 EDT