Re: CMake

On 2/17/15 4:42 PM, Felix Salfelder wrote:
> On Tue, Feb 17, 2015 at 03:49:47PM +0100, Guilherme Brondani Torri wrote:
>> I see. I was getting undefined symbols. I used the above to resolve
>> the symbols.
>> I guess the only alternatively is to tell explicitly that we are
>> resolving symbols at runtime.
> actually libgnucap_default_plugins.so should be
> gnucap_default_plugins.so. it's not a library.
> i have now fixed the naming in the autotools
> branch (i withheld that fix for after the merge *sigh*). CMake should
> adopt this fix, please consider 86831caa191857.

Done.

>> See 26f3ecb in  (https://github.com/guitorri/gnucap/tree/fix-osx).
>> There might be other solutions.
> this (-rdynamic) looks good. i wonder why this needs to be done
> manually. your commit seems to involve a typo.
> """
> [..]/apps/CMakeLists.txt:85:
> Parse error.  Expected "(", got newline with text "
> ".
> """

Sorry, should be fixed now.

>> Perhaps we need to set -rdynamic for Linux (if not set already).
> probably. linux is just one platform. autotools/libtool figures out
> flags automatically. i'm wondering if somebody might have implemented
> this for CMake...

Most projects define the flags by themselves. There might be a module 
somewhere.
See: http://www.cmake.org/Wiki/CMake_RPATH_handling

> thank you.
> felix

I cleaned up and rebuilt. Now the make and make install seem to be working.
No more the "gnucap-default-plugins.dylib: cannot open shared object 
file: No such file or directory"

Cheers,
Guilherme