Hello, On Thu, Oct 19, 2017 at 5:14 PM, al davis <[email protected]> wrote:
> "cmake-2" is a rebase of cmake-1. > > Quick test .. I see one problem, and don't know cmake enough to fix .. > I see a few other problems. Parts of main/config.h.in are new. CMake does not know yet how to configure it. I am looking into it. > The default plugins are installed as "libgnucap-default-plugins.so", > which isn't found by gnucap. Apparently, cmake prepends "lib" even if > we don't ask for it. The convention used here is that plugins do not > have the lib prefix because of the intent to load with dlopen, not at > link time. > This should work: set_target_properties(gnucap-default-plugins PROPERTIES OUTPUT_NAME "gnucap-default-plugin") or: set_target_properties(gnucap-default-plugins PROPERTIES PREFIX "") > Sometimes I wonder if that is a good decision. With a "lib" prefix, it > could be linked at startup or at link time (static link), which would > enable gnucap to run on systems with messed up support for dynamic > libraries. The design of plugins is such that they can be loaded > either way. > Whatever works. I've seen at least another project Linux-PAM which drops the lib prefix for loadable modules. > So (especially addressed to Guilherme and Kevin, who know cmake) .. > can you fix this? > I looking for the fixes. In the mean time, I patched the autotools branch to fix the compilation on OSX, see last commit in [1]. I have access to Savannah. How should I proceed? In the above case I guess the patch should go first into develop and them merged into autotools? Shall I branch from develop add my patches and push new branches to the remote for you to merge? Please advise. Best regards, Guilherme [1] https://github.com/guitorri/gnucap/commits/autotools-fix-osx _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
