Updates for Rivet - Yoda, Fastjet, Cgal env var by cholmcc · Pull Request #5245 · alisw/alidist

cholmcc · 2023-11-21T10:21:31Z

FastJet and YODA export FASTJET_ROOT and YODA_ROOT, respectively
Rivet build-requires cgal so that CGAL_ROOT values in rivet-config and rivet-build gets properly substituted at build-time with references to environment variable CGAL_ROOT at run-time

See also comment at

- FastJet and YODA export `FASTJET_ROOT` and `YODA_ROOT`, respectively - Rivet build-requires `cgal` so that `CGAL_ROOT` _values_ in `rivet-config` and `rivet-build` gets properly substituted at build-time with references to environment variable `CGAL_ROOT` at run-time See also comment at alisw#5221

jackal1-66 · 2023-11-21T14:23:40Z

The failed test on build/O2/alidist-ubuntu2204 seems not related to your modifications.

cholmcc · 2023-11-22T07:01:14Z

The failed test on build/O2/alidist-ubuntu2204 seems not related to your modifications.

Nor is the failure of build/O2/fullCI/alidist related - it is a formatting issue in O2 which has been fixed.

cholmcc · 2023-11-28T15:17:42Z

Hi all,

Any news on this? Thanks.

Yours,
Christian

jackal1-66 · 2023-11-28T15:19:38Z

@ktf could you please approve this? All checks have passed succesfully

ktf · 2023-11-29T07:45:10Z

Why do you need the extra _ROOT variables as part of the environment? In general if that is the case it means something else is wrong. Could you elaborate?

cholmcc · 2023-11-29T12:34:14Z

Hi Guilio,

Why do you need the extra _ROOT variables as part of the environment?

OK, I'll try.

When the Rivet module is build two shell-scripts are generated

rivet-config which a user can use to get compiler, linker, etc. flags and information
rivet-build which a user can use to compile one or more analyses into a shared library

Both of these scripts need to know where to find 3rd party software, such as fastjet, HepMC3, and CGAL, so that they may report the appropriate flags.

The Rivet build system (Autotools) automatically adds the appropriate values set at build-time to the scripts. F.ex., if HepMC3 is found in /some/directory/with/hepmc3, then the scripts will have values like

hepmc3_cppflags="-I/some/directory/with/hepmc3/include" 
hepmc3_ldflags="-L/some/directory/with/hepmc3/lib"

(not exactly, but you get the point).

However, we would like to make the scripts "relocatable" in the sense that they should depend on the environment used at run-time (as opposed to build-time). To do that. the Rivet recipe does a sed substitution on the two scripts. so that, continuing the above example,

/some/directory/with/hepmc3 -> ${HEPMC3_ROOT}

that is, the scripts will contain

hepmc3_cppflags="-I${HEPMC3_ROOT}/include" 
hepmc3_ldflags="-L${HEPMC3_ROOT}/lib"

In that way, when the user calls these script, his or her current environment is taken into account.

I believe a similar approach is taken in other recipes. It was certainly in the Rivet recipe before.

Yours,
Christian

ktf · 2023-11-29T13:04:51Z

You should not use the _ROOT variables, those are not guaranteed to be there, e.g. in the case you want aliBuild pick up cgal / fastjet / hepmc from the system or in case you want to provide a script which does not need to be built using aliBuild.

The safest way to do that at runtime would be to modify rivet-config to do use:

fastjet-config --prefix for FastJET.
HepMC3-config --prefix for HepMC3
CGAL is admittedly more complicated. You probably need something like:dirname "$(dirname $(PATH=~/src/sw/osx_arm64/cgal/latest/bin:$PATH which cgal_create_CMakeLists))"

this is the only way one can guarantee that the correct externals are picked up, regardless of how they are built. Unless there is some major problem with this approach, I would prefer we do not pollute the runtime environment with _ROOT variables (yes, I know there is a few already, but those are mostly for our own software which you cannot install otherwise).

See alisw#5245

cholmcc · 2023-11-29T14:01:35Z

Hi Guilio,

Changing rivet-config and rivet-build to use fastjet-config, HepMC3-config, yoda-config is a rather big change, as one would have to hack the two Rivet scripts quite a bit. Also, the scripts also use GMP_ROOT (the Rivet module should depend on gmp, btw.). Essentially the scripts have to be hacked when build so that they contain

HEPMC3_ROOT=`HepMC3-config --prefix` 
YODA_ROOT=`yoda-config --prefix` 
FASTJET_ROOT=`fastjet-config --prefix` 
CGAL_ROOT=$(dirname $(dirname `which cgal_create_CMakeLists`))
GMP_ROOT=$(dirname `echo $LD_LIBRARY_PATH| tr ':' '\n' | grep cgal`)

Perhaps the best way to do this is to dump a shell-script fragment with the above code into etc and then source that from the scripts. I did a pull request. If that works, then this can be closed without merging.

Yours,
Christian

ktf · 2023-11-30T07:58:41Z

I appreciate it's more complicated. All I am saying is that there is no guarantee that the _ROOT variables will be there, neither at runtime nor a build time, because packages might be built outside of aliBuild or picked up from the system and we do support that.

cholmcc · 2023-11-30T10:13:10Z

Hi all,

The pull request succeeded, and I believe it will fix the original run-time issue. Please let me know when it is deployed on LXPLUS so I can test it. Thanks.

Yours,
Christian

) * Update rivet.sh - set 3rd party paths via script, not `_ROOT` env See #5245 * Update rivet.sh - fixed wrong name Whoops, `grep`'ed for `cgal` where I wanted to grep for `GMP`. * Update rivet.sh - deduce variables at build-time as well as at run-time Following discussion on this MR, I made some changes so that at build-time, we deduce variables in same way as done at run-time (uses the same script snippet). The script snippet has been made more robust, and will exit out (build, rivet-config, rivet-build) in case of problems. If variables are set before hand (e.g., `HEPMC3_ROOT` is already set), then that value is used as-is. * Update rivet.sh - try to fix error in rivet_3rdparty.sh See 'env_err' test variables with 'ret=true', likely needed to make the 'source rivet_3rdparty.sh' command fly.

jackal1-66 · 2023-12-05T10:21:06Z

Ciao @cholmcc I believe there's still something not right with CGAL, i tried to run Rivet on the GRID and the CGAL library was still nowhere to be found. I kinda got a bit lost of all the modifications. I saw that this pull request has been succesfully merged, is this one required to make things work properly. I fear something else is missing other than the require building (I'm simply loading AliGenerators on the GRID).

/cvmfs/alice.cern.ch/el7-x86_64/Packages/GCC-Toolchain/v12.2.0-alice1-3/bin/../lib/gcc/x86_64-unknown-linux-gnu/12.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: cannot find -lCGAL: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Rivet_ALICE_2022_I1868463.so] Error 1

cholmcc · 2023-12-20T16:00:22Z

Hi Marco,

Your last message, was that before this message? If it was after, then there's still stuff to be done. Please let me know - perhaps cross-post to #5245

Otherwise, I think we should close this PR.

Thanks.

Yours,
Christian

jackal1-66 · 2023-12-27T10:13:29Z

Ciao @ktf the problem unfortunately is still valid.
I get cannot find -lCGAL: No such file or directory while running on the GRID.
Pinging @cholmcc to check on this, the #5264 does not fix the AliGenerators issues it seems.
@ktf do you have instructions on how to test everything using docker (referencing the message
by @cholmcc, on the already linked PR).
Cheers,

Marco

jackal1-66 · 2024-01-15T10:42:53Z

I'm working on the issue and trying to fix stuff locally (at first). Adding -L/cvmfs/alice.cern.ch/el7-x86_64/Packages/cgal/4.6.3-129/lib when running rivet-build fixes the program, so I believe the best solution would be simply to be able to get the cvmfs PATHs of both GMP and CGAL. The PATHs provided right now at configuration time are related to the daily-tags generation, which makes the program not run properly. Debugging...

jackal1-66 · 2024-01-15T13:24:10Z

I tried multiple solution @cholmcc but I wasn't able to get out of the rabbit hole using your script. Do you have any suggestion on how to get the proper PATH? @ktf maybe you can help on this as well, the easiest solution would be to get the LD_LIBRARY_PATH containing the cgal library and feeding it to the ./configure of the rivet build.
As I was saying, as a workaround, I've been feeding my script the output of this echo $LD_LIBRARY_PATH | tr ':' '\n' | grep cgal, not to make rivet-build fail. This behaviour can be seen both on the GRID and on LXPLUS

cholmcc · 2024-01-17T19:06:55Z

Hi Marco,

Just recapping, since it's been a while.

The problem is, that the wrong path for CGAL and GMP are set on the scripts

> alienv enter Rivet
[Rivet] ~ > rivet-config --ldflags | sed 's/-\([lL]\)/\n    -\1/g' 

    -L/cvmfs/alice.cern.ch/el7-x86_64/Packages/Rivet/rivet-3.1.8-9/lib 
    -L/cvmfs/alice.cern.ch/el7-x86_64/Packages/HepMC3/3.2.5-107/lib 
    -lHepMC3 
    -lHepMC3search 
    -L/cvmfs/alice.cern.ch/el7-x86_64/Packages/YODA/yoda-1.9.7-6/lib 
    -lYODA 
    -L/cvmfs/alice.cern.ch/el7-x86_64/Packages/fastjet/v3.4.1_1.052-alice2-4/lib 
    -lfastjettools 
    -lfastjet 
    -lCGAL 
    -lgmp 
    -L/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/cgal/4.6.3-129/lib 
    -L/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43/lib -Wl,-rpath,/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43/lib 
    -lm 
    -lfastjetplugins 
    -lsiscone_spherical 
    -lsiscone 
    -lfastjetcontribfragile 
    -lfastjettools

Now, in the rivet.sh build script we have

# Dependencies relocation: rely on runtime environment.  That is,
# specific paths in the generated script are replaced by expansions of
# the relevant environment variables.
SED_EXPR="s!x!x!"  # noop
for P in $REQUIRES $BUILD_REQUIRES; do
  UPPER=$(echo $P | tr '[:lower:]' '[:upper:]' | tr '-' '_')
  EXPAND=$(eval echo \$${UPPER}_ROOT)
  [[ $EXPAND ]] || continue
  SED_EXPR="$SED_EXPR; s!$EXPAND!\$${UPPER}_ROOT!g"
done

after the full build. Here, REQUIRES and BUILD_REQUIRES should contain

HepMC3
YODA
fastjet
GMP
cgal

which are

Turned upper case, -> UPPER
Expand UPPER_ROOT to get e.g., $GMP_ROOT into EXPAND,
Set sed expression to contain s!$EXPAND!\$UPPER_ROOT!g - e.g,, replace all occurrences of value $GMP_ROOT with an evaluation of the run-time environment variable GMP_ROOT. This works flawlessly for YODA, HepMC3 and fastjet

[Rivet] ~ >  cat `command -v rivet-config` | grep "\(YODA\|FASTJET\|HEPMC3\)_ROOT" 
    ihepmc="$HEPMC3_ROOT/include"
    iyoda="$YODA_ROOT/include"
    ifastjet="$FASTJET_ROOT/include"
    lhepmc="$HEPMC3_ROOT/lib"
    lyoda="$YODA_ROOT/lib"
    lfastjet="-L$FASTJET_ROOT/lib -lfastjettools -lfastjet -lCGAL -lgmp -L/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/cgal/4.6.3-129/lib -L/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43/lib -Wl,-rpath,/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43/lib -lm -lfastjetplugins -lsiscone_spherical -lsiscone -lfastjetcontribfragile -lfastjettools"

but not for GMP and CGAL

[Rivet] ~ > cat `command -v rivet-config` | grep "\(GMP\|CGAL\)" 
    lfastjet="-L$FASTJET_ROOT/lib -lfastjettools -lfastjet -lCGAL -lgmp -L/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/cgal/4.6.3-129/lib -L/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43/lib -Wl,-rpath,/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43/lib -lm -lfastjetplugins -lsiscone_spherical -lsiscone -lfastjetcontribfragile -lfastjettools"

The million-$ question is then: Why?

From the above, it looks like

CGAL_ROOT=/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/cgal/4.6.3-129
GMP_ROOT=/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43

on the builder host. So I can do

[Rivet] ~ > cat `command -v rivet-config` | \
  sed -e
  -e 's!/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/cgal/4.6.3-129!\$CGAL_ROOT!g'  \
  -e 's!/local/workspace/DailyBuilds/DailyAliGenerators/daily-tags.jh7bRB3Qc7/slc7_x86-64/GMP/v6.2.1-43!\$GMP_ROOT!g' | \
  grep "\(CGAL\|GMP\)"
    lfastjet="-L$FASTJET_ROOT/lib -lfastjettools -lfastjet -lCGAL -lgmp -L$CGAL_ROOT/lib -L$GMP_ROOT/lib -Wl,-rpath,$GMP_ROOT/lib -lm -lfastjetplugins -lsiscone_spherical -lsiscone -lfastjetcontribfragile -lfastjettools

to get the proper thing. That is, if I do what rivet.sh I think does, by hand, then it all works out great. The question is therefore: What can prevent it from going right? And here, I can see basically one perhaps two reasons

GMP_ROOT and CGAL_ROOT are not set at build time. I don't know how that would happen - they really should be according to the docs, as far as I remember.
GMP_ROOT and CGAL_ROOT does not contain the right path at build time. This does seem like a more likely situation, in that fastjet-config will report the build-time paths:

[Rivet] ~ > - /cvmfs/alice.cern.ch/el7-x86_64/Packages/fastjet/v3.4.1_1.052-alice2-6/bin/fastjet-config --libs
-Wl,-rpath,/cvmfs/alice.cern.ch/el7-x86_64/Packages/fastjet/v3.4.1_1.052-alice2-6/lib -L/cvmfs/alice.cern.ch/el7-x86_64/Packages/fastjet/v3.4.1_1.052-alice2-6/lib -lfastjettools -lfastjet -lCGAL -lgmp -L/local/workspace/DailyBuilds/AdHocO2Physics/daily-tags.p5rAZwxWOL/slc7_x86-64/cgal/4.12.2-117/lib -Wl,-rpath,/local/workspace/DailyBuilds/AdHocO2Physics/daily-tags.p5rAZwxWOL/slc7_x86-64/cgal/4.12.2-117/lib -L/local/workspace/DailyBuilds/AdHocO2Physics/daily-tags.p5rAZwxWOL/slc7_x86-64/GMP/v6.2.1-42/lib -Wl,-rpath,/local/workspace/DailyBuilds/AdHocO2Physics/daily-tags.p5rAZwxWOL/slc7_x86-64/GMP/v6.2.1-42/lib -lm

which doesn't seem right (i.e., fastjet.sh should do something similar as what rivet.sh does.).

So how to fix it. Well, I think I need a bit more to go on before I can figure it out. What I would do is to add a bit of output from the rivet.sh script to better understand what is going on. Then the build system should run on that as usual. Then I would like to see the full build logs from the build so I can figure out what is going on.

My suspicion is that

CGal and GMP environments are loaded, and CGAL_ROOT and GMP_ROOT are set according to these loads
configure uses the output of fastjet-config ... to get FastJet flags, including the CGal and GMP flags
fastjet-config does not report the environment locations, but rather the locations of the build-time environment
However, the loaded CGal and GMP environments are not the same as the ones reported by fastjet-config (even if it is the same exact version - since the build-time environment depends on the time and date executed - e.g., daily-tags.p5rAZwxWOL and other such things)
So while sed will try to find the the current values of GMP_ROOT and CGAL_ROOT in the scripts rivet-config and rivet-build it will never find them because fastjet-config reported some other values.

If this is correct, then the proper solution is to fix fastjet.sh so that fastjet-config will report the run-time environment - not the build-time same. A hack could be to parse out the CGAL and GMP paths reported by fastjet-config at build-time and use those for substitution with sed.

My question for you: If I make some changes to rivet.sh can you then run the builder and provide the full logs for me to study? Thanks.

Yours,
Christian

…rivet-config`, `rivet-build`, and - I suspect - `fastjet-config`. See also alisw#5245 for a discussion. Note, the `rivet.sh` script is set up to explicitly fail - thus hopefully allowing me to see the log output. This is work-in-progress.

jackal1-66 · 2024-01-18T15:00:10Z

@cholmcc I approved the review in the PR #5245 , you covered all the missing points in your last message. I had seen the same behaviour related to the /local/workspace path set for GMP and CGAL, I believe this might caused by the fact that both programs do not have a configuring script by default, such as yoda-config to be clear. My two cents...

…isw#5264) * Update rivet.sh - set 3rd party paths via script, not `_ROOT` env See alisw#5245 * Update rivet.sh - fixed wrong name Whoops, `grep`'ed for `cgal` where I wanted to grep for `GMP`. * Update rivet.sh - deduce variables at build-time as well as at run-time Following discussion on this MR, I made some changes so that at build-time, we deduce variables in same way as done at run-time (uses the same script snippet). The script snippet has been made more robust, and will exit out (build, rivet-config, rivet-build) in case of problems. If variables are set before hand (e.g., `HEPMC3_ROOT` is already set), then that value is used as-is. * Update rivet.sh - try to fix error in rivet_3rdparty.sh See 'env_err' test variables with 'ret=true', likely needed to make the 'source rivet_3rdparty.sh' command fly.

cholmcc requested review from a team as code owners November 21, 2023 10:21

cholmcc mentioned this pull request Nov 21, 2023

Update yoda.sh #5221

Merged

jackal1-66 approved these changes Nov 21, 2023

View reviewed changes

jackal1-66 enabled auto-merge (squash) November 21, 2023 14:23

cholmcc pushed a commit to cholmcc/alidist that referenced this pull request Nov 29, 2023

Update rivet.sh - set 3rd party paths via script, not _ROOT env

25f4a15

See alisw#5245

cholmcc mentioned this pull request Nov 29, 2023

Update rivet.sh - set 3rd party paths via script, not _ROOT env #5264

Merged

maireiphc changed the title ~~Updates for Rivet~~ Updates for Rivet - Yoda, Fastjet, Cgal env var Nov 29, 2023

Merge branch 'master' into cholmcc-for-rivet-updates

23090ad

cholmcc closed this Jan 18, 2024

auto-merge was automatically disabled January 18, 2024 00:49
Pull request was closed

cholmcc deleted the cholmcc-for-rivet-updates branch January 18, 2024 00:49

cholmcc mentioned this pull request Jan 18, 2024

Fix for problems in rivet-config, rivet-build and fastjet-config #5320

Merged

Conversation

cholmcc commented Nov 21, 2023

Uh oh!

jackal1-66 commented Nov 21, 2023

Uh oh!

cholmcc commented Nov 22, 2023

Uh oh!

cholmcc commented Nov 28, 2023

Uh oh!

jackal1-66 commented Nov 28, 2023

Uh oh!

ktf commented Nov 29, 2023

Uh oh!

cholmcc commented Nov 29, 2023

Uh oh!

ktf commented Nov 29, 2023

Uh oh!

cholmcc commented Nov 29, 2023

Uh oh!

ktf commented Nov 30, 2023

Uh oh!

cholmcc commented Nov 30, 2023

Uh oh!

jackal1-66 commented Dec 5, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cholmcc commented Dec 20, 2023

Uh oh!

jackal1-66 commented Dec 27, 2023

Uh oh!

jackal1-66 commented Jan 15, 2024

Uh oh!

jackal1-66 commented Jan 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cholmcc commented Jan 17, 2024

Uh oh!

jackal1-66 commented Jan 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jackal1-66 commented Dec 5, 2023 •

edited

Loading

jackal1-66 commented Jan 15, 2024 •

edited

Loading