[osg] [osgearth] Plugins are not installed correctly on Linux

[cbrl]

Using dynamic linkage on Linux, the osg and osgEarth plugins are not installed properly. The osgPlugins folder will end up in lib/osgPlugins-<version>/, when it should be installed to plugins/osgPlugins-<version>. I believe this is because the portfiles look for the plugins within the bin/ directory, whereas on non-Windows systems they will be located in lib/ instead.

Here is the behavior I see for each of these ports:

• osg:x64-linux-dynamic will install without error, but the plugins won't be in the correct location.
• Attempting to install osgearth:x64-linux-dynamic will result in the following error post-build: Could not determine osg plugins directory.

A quick and dirty test appears to confirm that replacing bin with lib in the section of the portfiles referencing the plugins will fix the problem for osg. For osgearth, it will now install successfully, but the osgearth plugins seemingly disappear. They don't end up in the plugins/osgPlugins-<version>/ folder.

Additional context

Here is the location in the portfiles where they first attempt to locate the plugins:

vcpkg/ports/osg/portfile.cmake

Line 123 in b2a22ff

if(EXISTS "${CURRENT_PACKAGES_DIR}/bin/${osg_plugins_subdir}")

vcpkg/ports/osgearth/portfile.cmake

Line 84 in b2a22ff

file(GLOB osgearth_plugins "${CURRENT_PACKAGES_DIR}/bin/${osg_plugins_subdir}/${osg_plugin_pattern}")

They will both exclusively search ${CURRENT_PACKAGES_DIR}/bin/, but the osg and osgEarth builds will use bin/ for the library install path on Windows only. On other systems, the path is under lib/.

osg

INSTALL(TARGETS ${TARGET_TARGETNAME}
            RUNTIME DESTINATION bin COMPONENT ${PACKAGE_COMPONENT}
            ARCHIVE DESTINATION ${OSG_INSTALL_LIBDIR}/${OSG_PLUGINS} COMPONENT libopenscenegraph-dev
            LIBRARY DESTINATION ${OSG_INSTALL_LIBDIR}/${OSG_PLUGINS} COMPONENT ${PACKAGE_COMPONENT})

osgEarth

INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION bin ARCHIVE DESTINATION lib${LIB_POSTFIX}/${OSG_PLUGINS} LIBRARY DESTINATION lib${LIB_POSTFIX}/${OSG_PLUGINS} )

[cbrl]

Taking another look at this, I'm a bit confused as to why the plugins folder is moved from bin/ to plugins/. It doesn't seem like there would be an issue with leaving them in bin/ or lib/, though I could easily be missing something. As-is, however, I don't believe it's handled completely correctly, even on Windows.

With osg:x64-windows, the targets in the CMake files generated by the changes made in unnoficial-export.patch will still refer to bin/osgPlugins-<version>/<plugin>.dll, despite the file now existing at plugins/osgPlugins-<version>/<plugin>.dll.

I haven't done any tests that consume the libraries yet, but disabling the bit about moving the plugins appears to result in a successful osg and osgearth installation on x64-linux-dynamic, with the exported targets referring to the correct location as well.

[dg0yt]

The plugins are moved to get a fairly consistent installation layout for such items in vcpkg.

• Note that filesystem layout in vcpkg is windowsish, not posixish.
  The bin dir is for regular DLLs on Windows, not for executable programs and not for linux shared objects.
  (Unfortunately, some related aspects are underspecified, regardless of community questions for clarification.)
• The binary artifacts are meant to be relocatable. In most cases, you need to explicitly tell software where to actually find plugins, by some specific interface.
• x64-linux-dynamic didn't exist until a few days ago, so it couldn't be tested.
• The exported location should be fixed indeed. (Usually the only use case for the location property of a plugin is custom deployment script.)

[cbrl]

That makes sense, thanks for the clarification.

x64-linux-dynamic didn't exist until a few days ago, so it couldn't be tested.

On this note, I don't think this problem isn't necessarily specific to x64-linux-dynamic, though that is where I observed the issue. I believe it will occur on any system where WIN32 is false in CMake, and the triplet in use specifies dynamic linkage. It looks like all instances of this are currently within community triplets, however.

[cbrl]

@dg0yt Is the intention that the plugins be relocated on any platform (e.g. the .so files will be moved to plugins/ on Linux, just like the .dll files on Windows)? I believe I have a solution that will fix this, and another minor issue I've found with osgearth, but want to ensure I'm assuming the correct behavior before submitting anything.

[dg0yt]

There was a tendency to promote plugins/<group>. I would prefer such a consistent layout on all platforms. Neither bin nor lib is consistently used across platforms, in vcpkg.
Unfortunately, I wasn't able to get answers for filesystem layout questions with regard to tools (#17607), so maybe there is no authorative answer with regard to plugins.

[cbrl]

Closing this issue. This is fixed with #26214 and #27156.