A lot of emails today: Best to just collect them.
SR:
I'm trying to run the ProductionExe executable which I built on SL3 (fcdflnx9) under 6.1.6.migrate on SL4 (fcdflnx1) after setting up 6.1.6.migrate. I get an immediate error: /cdf/spool/cdfprd_val/rolli_work/migrationValidation/aug20_6.1.6.migrate.lnx9 > bin/Linux2.4-GCC_3_4/ProductionExe -i /cdf/spool/cdfprd_val/rolli_work/migrationValidation/samples/bhel0d_sample.pad -o /cdf/spool/cdfprd_val/rolli_work/migrationValidation/samples/bhel0d_sample.6.1.6.migrate.SL3BuiltSL4Run.pad -c $CDFSOFT2_DIR/Production/ProductionExe.tcl bin/Linux2.4-GCC_3_4/ProductionExe: error while loading shared libraries: libCore.so: cannot open shared object file: No such file or directory any idea why this happens? Is this expected? If yes, then anything built on SL3 and shipped to a CAF SL4 will fail... please advise...
LG:
You've got a mixed environment. If you setup the SLF3 version of 6.1.6.migrate explicitly, it will work: setup cdfsoft2 6.1.6.migrate -f Linux+2.4
SL:
the cdfsoft2 6.1.6.migrate installation on /cdf/code is corrupt, that is the reason of the error message. Lynn, could you please take a look at the cdfsoft2 6.1.6.migrate Linux+2.6 flavour configuration on /cdf/code. It sets up root v4_00_08gGCC_3_4_3 Linux+2.6 which does not exists: fcdflnx2 % echo $ROOT_DIR /cdf/code/cdfsoft/products/root/v4_00_08gGCC_3_4_3/Linux+2.6 fcdflnx2 % ls -aFl /cdf/code/cdfsoft/products/root/v4_00_08gGCC_3_4_3 total 24 drwxr-sr-x 4 cdfsoft cdfsoft 4096 Sep 16 16:10 ./ drwxr-sr-x 10 cdfsoft cdfsoft 4096 Sep 16 16:13 ../ drwxr-sr-x 93 cdfsoft cdfsoft 8192 Feb 6 2009 Linux+2.4-2.3.2/ drwxr-sr-x 93 cdfsoft cdfsoft 8192 Feb 6 2009 Linux+2.4.to.be.removed/ Is there a way to find out how this happened?
LG:
K - I will have a look. Stephan, the situation is more complex than you imply. There is a great deal of confusion with ups products that needs sorting. Simona, Linux+2.4 is the SL3 option. It makes sense to explicitly setup the SL3 flavor of cdfsoft2 when you are using an executable built on SL3. (We keep saying we don't officially support the mixed environment.)
LG:
I have reconfigured cdfsoft2 on /cdf/code. That has solved the root problem. OK, your original setup is working again after I reconfigured 6.1.6.migrate.
SR:
Do you mean that if I run an SL3 exe on SL4 I still have to setup 6.1.6.migrate with -f option?
LG:
I'll let Rick answer this one. It's a point we hadn't discussed, and involves which shared libraries are being used. "setup cdfsoft2 6.1.6.migrate" will get the SL4 shared libraries In many cases, these are the same shared libraries as for SL3, so this may actually be moot. "setup cdfsoft2 6.1.6.migrate -f Linux+2.4" will get the SL3 shared libraries
SL:
So, now the question to Simona and Jim: How could you build a SL 4 6.1.6.migrate job without the root libraries being available?
JB:
I don't know--the root libraries were available to me. I am running at Wisconsin, of course. I fetched the 6.1.6.migrate ordinary and maxopt libraries and associated utilities, and ran with them--no tinkering. which root /afs/hep.wisc.edu/cdfsoft/products/root/v4_00_08gGCC_3_4_3/Linux+2.4-2.3.2/bin/root
SL:
thanks for your reply. So, .../Linux+2.4-2.3.2/... would be an SL 3 build root package.
SR:
I also built on SL4! and run... On August 17th with 6.1.6.migrate that was available since that day.... On Thu, 24 Sep 2009, LG wrote: > Simona built on SL3, where the root libraries existed. > I've been cleaning up product confusion, and simply > forgot to check 6.1.6.migrate. Apologies for that.
RS:
I have always assumed that if one builds on SLx, then one needs to do a setup cdfsoft2 -f xxx on the run-time platform, where xxx specifies the build flavor. This is what I've always presented as one of the (unfortunate) implications to users of migrating to the new build infrastructure. If the shared libraries on SL3 and SL4 are all the same (which would be a little hard to believe), then that would be great. The explicit flavor might still be needed when running on SL5, however, so just making it the standard prescription might turn out to be the better policy. We'll need to advertise this point loudly and broadly when we migrate.
RC:
Your shared object problem is the following. When you built the libs on SL3, BFARCH=Linux2.4-GCC_3_4 when you run on SL4, BFARCH=Linux2.6-GCC_3_4 The rootlogon.C file refers to the library as ./shlib/$BFARCH/libStntuple_base.so so it can't be found on SL4 It seems BFARCH does not follw "-f" rlc@fcdflnx1 > setup cdfsoft2 6.1.6.migrate -f Linux+2.4 rlc@fcdflnx1 > echo $BFARCH Linux2.6-GCC_3_4 So the rootlogon has to be redesigned, or you could create a soft link, or maybe there is a "right" way do it..
LG:
Interesting. BFARCH is defined by SRT, independently of anything else. Where is rootlogon.C? If that is in CDF code, then it needs to change as part of the migration.
RC:
I believe there are several rootlogon.C's in cvs (but can't search at the moment) and 1000's scattered in user's areas. I don't think there is anything we can do to fix these, except to warn/advise users when the new SRT is released. If BFARCH does not always determine the shlib directory name, what should go here? I guess building on SL3 and running on SL4 is a fundamental problem (w.r.t this issue) in the new SRT since the whole point is to keep the builds separate. I'm sure that are very many uses of BFARCH similar to this example, and if many of them will break, we should plan for that.
Modified 24-September-2009 at 14:01
http://hep.physics.wisc.edu/~jnb/cdfcode/24Sep2009
| Previous notes | Next notes | Main slide directory |