Adding GSI Online Offline Object Oriented (Go4) analysis framework

[HLinde]

Hi!
I would like to put forward this recipe for the Go4 analysis library, which is developed at GSI Go4 and builds upon CERNs ROOT.

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

Some explanation on the recipe:

• The activate.sh/deactivate.sh scripts are derived from the ROOT recipe and the "go4login"
• build.sh does
  • compile go4
  • install go4 in conda prefix
  • place activate.sh/deactivate.sh
• clean_up.sh exchanges remaining references to temporary paths with the proper conda placeholder prefix path
• the packaging test "run_go4_examples.sh" checks, that 2 of the Go4 examples analyis projects can be compiled and run without error.
• "variants.yaml" chooses the gcc/gxx compilers with fixed version 13.3 (for now)
• osx and windows builds are skipped (for now)

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/go4/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/go4/recipe.yaml:

• ❌ Selectors in comment form no longer work in v1 recipes. Instead, if / then / else maps must be used. See lines [35, 41, 47].

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/15585517498. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/go4/recipe.yaml) and found it was in an excellent condition.

[HLinde]

I am willing to be listed as maintainer in this recipe.

[HLinde]

@conda-forge-admin, please ping conda-forge/help-c-cpp, ready for review!

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/help-c-cpp, and so here I am doing that.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/go4/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/go4/recipe.yaml:

• ❌ If python is a host requirement, it should be a run requirement.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/17494214077. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/go4/recipe.yaml) and found it was in an excellent condition.

[danielnachun]

If you can fix the one issue above with the dynamic_linking: section, then we can get this merged!

[HLinde]

Thank you @danielnachun ! It would be great, if it can be merged! :)
However with the issue about ${CMAKE_ARGS} and the missing library /usr/lib64/libpthread_nonshared.a I'm still puzzled. Do you know about similar issues?

[danielnachun]

Can you leave in ${CMAKE_ARGS} unquoted so I can see the error? I suspect there is some other tweak needed here so that ${CMAKE_ARGS} can work which can be determined from the logs.

[HLinde]

I unqouted it, here is the linking error in the linux build:
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1418085&view=logs&j=4cabe686-70ae-553a-7fd0-310379f2cbac&t=6a4fc7c9-c31a-5115-eff9-6479d72b69ff&l=2064

[HLinde]

On osx the package is built, but now the test run using make fails here:
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1418085&view=logs&j=dff6ff7b-316b-540a-5923-739df25f7012&t=2582809e-c3dc-5a5f-d883-fd3c8f9139aa&l=5032

[HLinde]

Hi @danielnachun,
it turns out to be two separate issues that came up after actually using the CMAKE_ARGS.

1. sysroot_linux-64 2.17 has wrong links in x86_64-conda-linux-gnu/sysroot/usr/lib64/libpthread.so:

--- x86_64-conda-linux-gnu/sysroot/usr/lib64/libpthread.so
+++ x86_64-conda-linux-gnu/sysroot/usr/lib64/libpthread.so
@@ -2,4 +2,4 @@
    Use the shared library, but some functions are only in
    the static library, so try that secondarily.  */
 OUTPUT_FORMAT(elf64-x86-64)
-GROUP ( ../../lib64/libpthread.so.0 ../../lib64/libpthread_nonshared.a )
+GROUP ( ./libpthread.so.0 ./libpthread_nonshared.a )

And also in x86_64-conda-linux-gnu/sysroot/usr/lib/libc.so:

--- x86_64-conda-linux-gnu/sysroot/usr/lib/libc.so
+++ x86_64-conda-linux-gnu/sysroot/usr/lib/libc.so
@@ -2,4 +2,4 @@
    Use the shared library, but some functions are only in
    the static library, so try that secondarily.  */
 OUTPUT_FORMAT(elf64-x86-64)
-GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )
+GROUP ( ../lib64/libc.so.6 ../lib64/libc_nonshared.a  AS_NEEDED ( ../lib64/ld-linux-x86-64.so.2 ) )

I tested to apply the patch in the build script, but that seems not a good idea to do in the end. The only other way I see, would be to use a more recent version of sysroot_linux-64. However, that would require root or conda-forge-pinning to change. The issue was also discussed here and here.
2. The -DCMAKE_INSTALL_LIBDIR=lib in CMAKE_ARGS somehow seems to prevent that the shared libraries are installed to the $PREFIX.
Do you have any ideas? I pushed what I tried so far, but the "patching" of libpthread/libc now only works in the Linux Docker image.

[HLinde]

Hi again @danielnachun
I found that the linking issues to libpthread only happen with the optional hdf5 dependency. I would for now leave that hdf5 feature out of the package and see later if a later sysroot_linux-64 fixes the issue. All current versions have this problem with libpthread.

What happens with -DCMAKE_INSTALL_LIBDIR=lib in CMAKE_ARGS is that somehow cmake converts it into
$SRC_DIR/lib (Thats what I see in build/CMakeCache.txt at CMAKE_INSTALL_LIBDIR:PATH=).
When I take -DCMAKE_INSTALL_LIBDIR=lib out of CMAKE_ARGS, it uses just lib as I guess it is the intended directory?
Unless you have another idea on this, I would keep the recipe such that it takes out the argument.

[danielnachun]

Great work getting to the bottom of the issues here. There are definitely some issues with the upstream CMake that they need to fix but as far as we are concerned this looks good now.