Select Git revision
configure.ac
Forked from
Nettle / nettle
Source project has a limited visibility.
-
When a user invokes pkg-config to get the necessary linker flags for linking to libhogweed, the user can add --static to get the private dependencies included, which are necessary for static linking. If the hogweed build contains both static and shared libraries, this works as intended - if the user explicitly passes -static to the linker to have it favor static libs over shared ones, the same user also needs to tell pkg-config about this intention. If the hogweed build happens to be static-only, the user of the library might not be aware of this, and might not realize needing to pass --static to pkg-config. (This is even more an issue in setups with a large number of libraries, where only a few of them are built static-only.) For these cases, where a library is built as only a static library, one fairly common convention (not used everywhere, but at least in some libraries I regularly use) is to include the private dependencies in the non-private section. This makes sure a user of the library doesn't need to be concerned about which way this library was built (unless the user intentionally overrides defaults by passing flags such as -static to the linker).
When a user invokes pkg-config to get the necessary linker flags for linking to libhogweed, the user can add --static to get the private dependencies included, which are necessary for static linking. If the hogweed build contains both static and shared libraries, this works as intended - if the user explicitly passes -static to the linker to have it favor static libs over shared ones, the same user also needs to tell pkg-config about this intention. If the hogweed build happens to be static-only, the user of the library might not be aware of this, and might not realize needing to pass --static to pkg-config. (This is even more an issue in setups with a large number of libraries, where only a few of them are built static-only.) For these cases, where a library is built as only a static library, one fairly common convention (not used everywhere, but at least in some libraries I regularly use) is to include the private dependencies in the non-private section. This makes sure a user of the library doesn't need to be concerned about which way this library was built (unless the user intentionally overrides defaults by passing flags such as -static to the linker).