Hi Jonas,
How do you intend to support OMPT on Windows?
The code currently committed to the project can be compiled only on unix-like systems due to the attribute ‘weak’ specified for the initialization function (in ompt-general.c):
_OMP_EXTERN attribute (( weak ))
int ompt_initialize(ompt_function_lookup_t ompt_fn_lookup, const char *version,
unsigned int ompt_version)
{
return no_tool_present;
}
Thank you.
Regards,
Olga
Hi Olga,
To be honest: I am not really aware of Windows. As far as I know weak symbols are not supported on Windows, so that we need a different strategy. The OMPT specification [1] says
“Compiler and linker don’t support weak symbols. On systems that don’t support weak symbols, different implementation strategies are needed for static and dynamic linking. For a static library implementation of an OpenMP runtime library, the library can provide a stub version of ompt_initialize in a separate object file. In this case, the linker will include the OpenMP library’s stub implementation of ompt_initialize only if no tool supplied version is already present when the OpenMP runtime library is used to resolve undefined symbols. An OpenMP implementation used as a dynamic library can define ompt_initialize as a global symbol. The version in the OpenMP library would be invoked only if no tool-supplied implementation of ompt_initialize is statically linked in the executable or a tool library that appears before the OpenMP runtime library in the dynamic library search path during execution.”
I will discuss with Jonas how / if we can fix this. At least we should ensure that compiling is possible on Windows, at least with deactivating OMPT.
Regards,
Tim
Olga,
I don’t work with Windows, so I would appreciate suggestions from those at Intel who do about how to have the OpenMP runtime interact with the tool in a dynamically linked scenario on Windows. Is the text that Tim included below from the OMPT draft specification enough for you to craft a solution for Windows? If not, how should the OpenMP runtime identify that a tool is present and call a function to set up the tool?
We wanted to avoid creating a security flaw by having the OMP runtime read the name of a dynamically linked library for the tool shared library an environment variable and then load that. This strategy would certainly work, though I would expect to hear that this would create security problems.
Hi all,
as we are currently not planning to support OMPT on Windows, find attached a patch to let CMake fail if someone tries to enable it.
Could you please test before committing? We don't have a Windows machine with the required build infrastructure, but tried to be consistent with the other checks already implemented...
If someone (from Intel) wants to implement support for Windows, this can be easily reverted.
Greetings,
Jonas
I tested this on Windows, Mac, and Linux and it works as expected on all three (error on Windows, fine on the others).
Committed r239912.
-- Johnny