Hi Flemming and Christian, Before posting my earlier message I did look through the archive and came across the note indicating how to explicitly link to the cern library. This didn't work. In any case, the configure script gives me a LAPLAS and BLAS ... yes. My installation locates cernlib in /usr/local/cern/2000, with a logical link /usr/local/cern/pro. I have looked through the /lib directory and I definitely do not have LAPLAS and BLAS (as expected for the 2000 instillation). My own local fix that worked, but obviously is not optimal, was to edit the cern.m4 file to remove the reference to these two libraries. I left the program continue to think I was running 2001, since it was not obvious to me what to change to get the flag corrected. I'll update my libraries once I have a little more time. Unfortunately, my past experience getting cernlib running on PPC has been fairly painful... ....steve > From: Christian Holm Christensen <cholm@hehi03.nbi.dk> > Reply-To: brahms-dev-l@bnl.gov > Date: Sun, 14 Oct 2001 18:15:13 +0200 > To: brahms-dev-l@bnl.gov, videbaek@sgs1.hirg.bnl.gov > Subject: Re: How do I get brag configure to work with pre 2001 cernlib > > Hi Steve, Flemming and others, > > On Sat, 13 Oct 2001 15:00:58 -0400 > "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote > concerning "Re: How do I get brag configure to work with pre 2001 cernlib": >> Dear Steve, >> >> go back on the list server a couple of weeks. I had similar problems since >> brag does not work with the RCF 2001 >> cernlib. Peter+Christian gave the right settings to the >> ./configure=... -cern-lib-dir== .. >> or something like this.Too if you have the cernlib as /cern/pro or .cern it >> goes there by default. >> I am at hoem with my phone-connection so this is as good as my answer/help >> gets > > This sounds odd to me. When I did the CERN_PRE_2001, I remember > explicitly that I tested it agains both CERNLIB 2000 and 2001. > > I should probably tell you the reason for CERN_PRE_2001. With the > release of CERNLIB 2001, the fella that maintains CERNLIB (and there's > only one these days) decided to seperate out BLAS and LAPACK, since > loads of (at least) Linux distros comes bundled with these libraries, > often later versions then the ones from CERN. Hence the fella > (rightly) believed it be a Good Thing for people to have the choice of > which version of these libs she'd like to use. Now, that means that > you have to link things slightly different with CERNLIB 2001 then > 2000-. Hence the macro to figure out how to link. > > A question for Steve: Did you see the message > > Checking wether CERNLIB libmathlib needs LAPACK and BLAS ...no > > at configure time? If so, the problem is in src/prog/Makefile.am. If > you saw > > Checking wether CERNLIB libmathlib needs LAPACK and BLAS ...yes > > then the problem is either in config/cern.m4 or in your CERNLIB > installation. > > Try to make link the following small program and see if it works: > > PROGRAM FOO > > CALL LSAME > > END > > Compile and link it with > > g77 foo.F -o foo -L/cern/pro/lib -lkernlib -lmathlib -lpacklib > > If that gives you > > /bin/ld: > Can't locate file for: -llapack > collect2: ld returned 1 exit status > > /cern/pro points to a CERNLIB 2001 installation. As a check do > > g77 foo.F -o foo -L/cern/pro/lib -lkernlib -lmathlib -lpacklib -lblas > -llapack3 > > which should work. > > Finally, I'd like to direct your attention to the CERNLIB RPMs > avaliable from CERN at > > /afs/cern.ch/asis/RPMS/i386_redhat61/ > > Grab the packages > > CERN.LIB_baselibs_sys-2001-0_asis_1.i386.rpm > CERN.LIB_geant_sys-2001-0_asis_1.i386.rpm > CERN.LIB_paw_sys-2001-0_asis_1.i386.rpm > CERN.LIB_utils_sys-2001-0_asis_1.i386.rpm > > and from > > /afs/cern.ch/asis/RPMS/share > > grab > > CERN.LIB_includes_shr-2001-0_asis_1.noarch.rpm > > [The rest of the mail is not directly related to the issue, so read it > at you leisure] > > Note that CERNLIB is GPL'ed, which means that we can not redistribute > BRAG under any license we may choose. In fact, we have a limited > choice of licenses [1]. I'd suggest LGPL. > > The funny thing is, that ROOTs license [2] is incompatible with GPL, > which means that ROOT can not redistribute h2root and g2root in the > way they do it now. They must redistribute it seperatly from ROOT and > under a license compatible with GPL. Similar things may hold for the > various add-on/plugin libraries of ROOT, like libGX11TTF, libMySQL, > libRGL and so on. > > In fact, we can not redistribute BRAT, CRASH, and other software that > builds on ROOT with out obtaining an explicit permission from Rene and > Fons! That's the GPL incompatiblity. I don't think that was the > intention of the license, but it's certainly the letter of it. Some > heavy-duty lobbying is in order, since this means that other > experiments (like say NIMROD) can not use our software or software > derived from ours, with out the consent of Rene and Fons. Ridiculus > isn't it? > > If you think lisencing issues is something we should not care too much > about, well, you're dead wrong (especially with the DMCA in the US), > and I refer you to the various articles avaliable out there discussing > things like lisencing, copyright, intellectual property, and so on > [3,4]. During my research for the previous links, I stumpled over > this [5] intresting article. > > Yours, > > Christian Holm Christensen ------------------------------------------- > Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 > DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 > Denmark Office: (+45) 353 25 305 > Email: cholm@nbi.dk Web: www.nbi.dk/~cholm > > [1] http://www.gnu.org/licenses/license-list.html > [2] http://root.cern.ch/root/License.html > [3] http://www.oreilly.com/catalog/opensources/book/perens.html > [4] http://www.opensource.org/advocacy/secrets.html > [5] http://www.nature.com/nature/debates/e-access/Articles/stallman.html >
This archive was generated by hypermail 2b30 : Sun Oct 14 2001 - 13:23:32 EDT