Some more CMake questions

OpenKIM
1

Hi Ryan,

I think I have a working package for Arch Linux, but there
are some minor issues I would like to resolve before submitting
it to the official repo.

1. Disabling models and model drivers

So far I did not plan to split the package into different parts, like
lib, headers and models. That's why I would like to remove all
default models and model drivers. This was possible
with the -DKIM_API_BUILD_MODELS_AND_DRIVERS switch.
Apparently this has been removed and is no longer supported.
Is there any replacement or should I just manually remove the files
from the respective directories before creating the package?

2. Enabling PIE flags

Arch requires libraries to be built with the PIE flags.
The common way of adding the default CMake flags does not work:
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -pie")
Do you have some recommendations how I could enable this
for all binaries and libraries created by CMake?

3. Changing libexec path

Arch Linux does not allow the libexec path and requires everthing
to be installed in /usr/lib/$pkgname. So far that is no problem,
I just adjusted the paths in kim-api-v2-config.cmake, libkim-api-v2.pc
and kim-api-v2-collections-management. Do you think this will be a problem?
Did I maybe miss something?

4. $srcdir in binaries

The build process issues some warnings that the binaries contain references
to the source path. Basically this is due to the log statements containing the
full path of the source file. Probably there is nothing we can do about this.
However, there are some other places which look pretty strange to me.
E.g. here:
$ strings /usr/lib/kim-api-v2/kim-api-v2-simulator-model | grep workspace
/usr/lib/kim-api-v2/model-driver~/.kim-api-v2/mo/home/daniel/workspace/libkim-
api/src/kim-api/cpp/src/old_KIM_APsilent

Can you see where this is coming from or which string this might be?

Here is another one:
$ strings /usr/lib/kim-api-v2/kim-api-v2-collections-info | grep workspace
/home/daniel/workspace/libkim-api/src/kim-api/cpp/src/KIM_LogImpLog object
destrUnable to make directory '

Best regards,
Daniel

2

Hi Daniel,

Answers below...

Hi Ryan,

I think I have a working package for Arch Linux, but there
are some minor issues I would like to resolve before submitting
it to the official repo.

1. Disabling models and model drivers

So far I did not plan to split the package into different parts, like
lib, headers and models. That's why I would like to remove all
default models and model drivers. This was possible
with the -DKIM_API_BUILD_MODELS_AND_DRIVERS switch.
Apparently this has been removed and is no longer supported.
Is there any replacement or should I just manually remove the files
from the respective directories before creating the package?

At the moment, yes, that is correct. I was thinking that the example models/drivers would be included in the kim-api binary packages, so that having this option would not be necessary. But maybe I *should* have an option for it, but make the default ON instead of OFF.... I'll think about it some more. (Comments from the community on this are welcome.)

2. Enabling PIE flags

Arch requires libraries to be built with the PIE flags.
The common way of adding the default CMake flags does not work:
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -pie")
Do you have some recommendations how I could enable this
for all binaries and libraries created by CMake?

I've added code to the build that should make this all work all the time with the PIE settings. Try the latest and let me know if you have any problems.

3. Changing libexec path

Arch Linux does not allow the libexec path and requires everything
to be installed in /usr/lib/$pkgname. So far that is no problem,
I just adjusted the paths in kim-api-v2-config.cmake, libkim-api-v2.pc
and kim-api-v2-collections-management. Do you think this will be a problem?
Did I maybe miss something?

The way to do this is to set the CMAKE_INSTALL_LIBEXECDIR variable:

$ cmake ../ -DCMAKE_INSTALL_LIBEXECDIR=/usr/lib/kim-api-v2/libexec

You might need to play a bit to select the directory value you want....

4. $srcdir in binaries

The build process issues some warnings that the binaries contain references
to the source path. Basically this is due to the log statements containing the
full path of the source file. Probably there is nothing we can do about this.
However, there are some other places which look pretty strange to me.
E.g. here:
$ strings /usr/lib/kim-api-v2/kim-api-v2-simulator-model | grep workspace
/usr/lib/kim-api-v2/model-driver~/.kim-api-v2/mo/home/daniel/workspace/libkim-
api/src/kim-api/cpp/src/old_KIM_APsilent

Can you see where this is coming from or which string this might be?

Here is another one:
$ strings /usr/lib/kim-api-v2/kim-api-v2-collections-info | grep workspace
/home/daniel/workspace/libkim-api/src/kim-api/cpp/src/KIM_LogImpLog object
destrUnable to make directory '

These do indeed look odd. I can't seem to produce something similar. I see absolute source file names in the strings output, but not the seemingly mangled/truncated values you list above.

The file names that are there seem to be the files that are included as part of the compilation. I'm not completely sure why they are being added to the final binary, but I think it is innocuous.

If you can send the specific warnings/errors you are seeing, I might be able to find a workaround for avoiding them....

Ryan

3

1. Disabling models and model drivers

So far I did not plan to split the package into different parts, like
lib, headers and models. That's why I would like to remove all
default models and model drivers. This was possible
with the -DKIM_API_BUILD_MODELS_AND_DRIVERS switch.
Apparently this has been removed and is no longer supported.
Is there any replacement or should I just manually remove the files
from the respective directories before creating the package?

At the moment, yes, that is correct. I was thinking that the example models/drivers would be included in the kim-api binary packages, so that having this option would not be necessary. But maybe I *should* have an option for it, but make the default ON instead of OFF.... I'll think about it some more. (Comments from the community on this are welcome.)

Hi Daniel,

OK. For the moment (until I manage to write a full KIM API manual and move the example models, drivers and simulators into it---so it will be some time) I've created a KIM_API_BUILD_EXAMPLES cmake option which defaults to ON.

So, to disable the examples, just use:

cmake .. -DKIM_API_BUILD_EXAMPLES=OFF ...

Cheers,

Ryan

4

Hi Ryan,

thanks a lot for the efforts. So far I have been able to confirm
that the PIE flag is not correctly being set when building the
latest trunk version. Setting the libexec path using the cmake
variable also works as expected.
So I am now able to create a libkim-api package for Arch Linux.
Once I have resolved some dependency settings I will submit it upstream.

Related to package management I have another question.
Let's assume I have installed a git version and compiled some
models locally specifically for that version. After upgrading to a more
recent version which has some ABI changes these models may no longer work.
But at least "kim-api-v2-collections-management list" still does show them.
Is there any versioning check performed or will loading the model simply fail
due to the OS loader? Or this is even a real issue because you freeze the ABI
after v2 is stable?

So far I have not yet found time to investigate where the strange strings are
coming from, I hope to do this sometime next week.

Best regards,
Daniel

5

Hi Ryan,

I did some digging but did not come up with a clean explanation
for these strings. After preprocessing the log macros look like this:

    this->LogEntry(KIM::LOG_VERBOSITY::error, "Unknown LanguageName. SHOULD
NEVER GET HERE.", 945, "/home/daniel/workspace/libkim-api/src/kim-api/cpp/src/
KIM_ComputeArgumentsImplementation.cpp");

So there is clearly the full path in the source file. This is also visible
somehow in the object file:

$ strings KIM_ComputeArgumentsImplementation.cpp.o | grep workspace
/home/daniel/workspace/libkim-api/src/kim-api/cpp/src/
KIM_ComputeArgumentsImplemUnknown LanguageName. SHOULD NESimulator supplied
ProcessDEDrTerm() routine reted ProcessD2EDr2Term() routine rInvalid
ComputeArgumentName encoInvalid argumentInvalid ComputeCallbackName
encoInvalid LanguageName encounteredInvalid SupportStatus encountereed
GetNeighborList() routine ret

But here it already seems truncated for no apparent reason.

In the final library there are only two instances of the "workspace" string
visible:

/home/daniel/workspace/libkim-api/src/kim-api/cpp/src/
KIM_ComputeArgumentsImplemUnknown LanguageName. SHOULD NESimulator supplied
ProcessDEDrTerm() routine reted ProcessD2EDr2Term() routine rInvalid
ComputeArgumentName encoInvalid argumentInvalid ComputeCallbackName
encoInvalid LanguageName encounteredInvalid SupportStatus encountereed
GetNeighborList() routine ret%Y-%m-%d:%H:%M:%S%Z
p/src/KIM_LogImpLog object destr/home/daniel/workspace/libkim-api/src/kim-api/
cpp/src/KIM_ModelImplementation.cpp

The strange thing is that only for two files these strings end up in there:
* cpp/src/KIM_ModelImplementation.cpp
* cpp/src/KIM_ComputeArgumentsImplem
For all the other files there is no entry.

For now I will just ignore this warning.

Best regards,
Daniel

6

Hi Dan,

Sorry for the long delay...

Related to package management I have another question.
Let's assume I have installed a git version and compiled some
models locally specifically for that version. After upgrading to a more
recent version which has some ABI changes these models may no longer work.
But at least "kim-api-v2-collections-management list" still does show them.
Is there any versioning check performed or will loading the model simply fail
due to the OS loader? Or this is even a real issue because you freeze the ABI
after v2 is stable?

Yes, once v2 is stable the ABI should be frozen, except for compatible additions. (That is the goal, but it is always possible that we'll miss something...)

You can use the command:

kim-api-v2-collections-management list --with-version

to get a listing of all the models/drivers and the version of the KIM API that they were compiled with. This should be helpful in the case that you need to debug any issues associated with this sort of thing...

One thing I do hope to do before an official final v2 release is to reimplement the private API/ABI that the KIM API uses to interact with the shared libraries for models/drivers. Currently, this is quite ad-hoc. I plan to make it more formal and introduce an (internal) versioning of the API/ABI so that the KIM API can better manage this issue in the future....

Cheers,

Ryan