An executable/library can have an application and a system version info. Both are stored together in the same attribute and/or resource (BEOS:APP_VERSION). Thus, if present at all both have to be present. The BAppFileInfo API (and using it the setversion program), however, allows to set them individually. When the attribute and resource are not yet present, BAppFileInfo is supposed to clear the respectively other version info if only one version info is set.
This happens a lot when building a Haiku image, since the build system uses setversion to set the system version info for each generated executable/library, and most of them don't have resource file defining an application version info. In fact most of them don't have a resource file at all. What makes the mentioned files special is that they *do* have a resource file, but this resource file uncommonly doesn't define an application version info. My guess is, that this constellation (existing resources, but no version info) triggers a BAppFileInfo bug that causes garbage in the application version info.
For the R5 build the setversion build tool uses R5's libbe, while under Linux, a stripped down Haiku libbe is used. R5's setversion suffers from the same problem, BTW.
I suppose, we could modify our setversion to check whether a version info was present and if not also write a zero'd out other version info, if only one version info is given.
... or we ignore the problem and build under Linux. :-P
