[ATfL] OMPT support should not be built at that stage

[pawosm-arm]

It turned out that libomp.a that we are shipping is useless.

It should not support OMPT as it tries to dlopen() libarcher.so

We are already building libomp.so with OMPT support enabled along with libarcher.so in the previous stage.

Fully operational libomp.a is needed by Allinea Smoke Tests.

With OMPT disabled, -ldl is not needed for OpenMP tests to pass, so the config file hack could be removed from build.sh.

[kiranchandramohan]

It should not support OMPT as it tries to dlopen() libarcher.so

Is there no libarcher.a?

[pawosm-arm]

It should not support OMPT as it tries to dlopen() libarcher.so

Is there no libarcher.a?

There is an equivalent, it's called libarcher-static.a, but it doesn't solve the problem. Linking against it does not stop OMPT from looking for libarcher.so. I suppose the use case scenario for libarcher-static.a is different (hence the name preventing straight substitution between .so and .a). Setting archer-specific environment variables (e.g. the one which disable its operation) isn't helping with the problem, and it makes sense as libarcher.so wasn't open, so it can't read its own environment variables. I couldn't find any environment variable similar to OMP_TOOL_VERBOSE_INIT=disable - this one disables verbose init, what would help was a piece of logic that could disable the OMPT init altogether. Much easier solution (attempted by this patch) is to disable OMPT in libomp.a - it solves the notorious problem of doing those discouraged calls to libdl functions from a static binary. If someone really needs to use OpenMP in a static program, they need to take consequences into account. Disabling OMPT at this stage have no other impact on the product, as the proper OpenMP runtime (the libomp.so library), and clang/flang which emits OpenMP code have been provided by the previous stage.

[kiranchandramohan]

LG.

Might be worth raising an upstream issue.