CMakeLists.txt: add inter-library links for cmake

etuttle commented

2020-01-20 02:12:32 +01:00

(Migrated from github.com)

With these changes I'm able to check out and build, without having any
the babelouest libraries installed ahead of time.

Cmake might have a better way to pick up transitive dependencies
between external projects and order the targets based on that, but I
couldn't figure it out.

With these changes I'm able to check out and build, without having any the babelouest libraries installed ahead of time. Cmake might have a better way to pick up transitive dependencies between external projects and order the targets based on that, but I couldn't figure it out.

babelouest commented

2020-01-20 02:50:37 +01:00

(Migrated from github.com)

The CI scripts say there's something wrong with this patch:

Attempt to add link library "orcania" to target "yder" which is not built in this directory.
[...]
Attempt to add link library "orcania" to target "ulfius" which is not built in this directory.
[...]
Attempt to add link library "orcania" to target "hoel" which is not built in this directory.
[...]

The cmake script goes like this:
https://github.com/babelouest/glewlwyd/blob/master/CMakeLists.txt#L135
Look for Orcania library minimum version ORCANIA_VERSION_REQUIRED ("2.1.0" at the moment). If not found, download it on github, build and install.
And so on with the other libraries.

The CI scripts say there's something wrong with this patch: ``` Attempt to add link library "orcania" to target "yder" which is not built in this directory. [...] Attempt to add link library "orcania" to target "ulfius" which is not built in this directory. [...] Attempt to add link library "orcania" to target "hoel" which is not built in this directory. [...] ``` The cmake script goes like this: https://github.com/babelouest/glewlwyd/blob/master/CMakeLists.txt#L135 Look for Orcania library minimum version `ORCANIA_VERSION_REQUIRED` ("2.1.0" at the moment). If not found, download it on github, build and install. And so on with the other libraries.

etuttle commented

2020-01-20 03:18:37 +01:00

(Migrated from github.com)

IIRC, the dependency ordering (and perhaps the link deps) between the libraries is unknown to cmake when it's running the download codepath for many of these libraries. I'll have to look closer at why it works with travis but not on my Mac, stand by...

babelouest commented

2020-01-20 04:28:57 +01:00

(Migrated from github.com)

I can come with another solution like a new option for each libraries, if this option is set to off, don't download and install the library, just exit with error message

"Error, library [orcania|yder|ulfius|hoel] not found"

I can come with another solution like a new option for each libraries, if this option is set to off, don't download and install the library, just exit with error message ``` "Error, library [orcania|yder|ulfius|hoel] not found" ```

etuttle commented

2020-01-21 00:33:52 +01:00

(Migrated from github.com)

I still haven't gotten to the bottom of 1) why the linking works for travis (and everyone else for that matter) when the cmake download_project paths are running and 2) what those error messages from cmake in travis mean. I suspect some combination of my clang/osx/cmake setup makes these target_link_libraries important. I'll narrow it down this afternoon.

I still haven't gotten to the bottom of 1) why the linking works for travis (and everyone else for that matter) when the cmake `download_project` paths are running and 2) what those error messages from cmake in travis mean. I suspect some combination of my clang/osx/cmake setup makes these `target_link_libraries` important. I'll narrow it down this afternoon.

babelouest commented

2020-01-21 06:09:20 +01:00

(Migrated from github.com)

I've added the cmake option DOWNLOAD_DEPENDENCIES, if you set it to off, it won't download the libraries if missing, just stopping with an error: github.com/babelouest/glewlwyd@d42816d4f2

I've added the cmake option `DOWNLOAD_DEPENDENCIES`, if you set it to `off`, it won't download the libraries if missing, just stopping with an error: https://github.com/babelouest/glewlwyd/commit/d42816d4f215b003ddfa58753932fcc2cd752ce8

etuttle commented

2020-01-21 09:38:39 +01:00

(Migrated from github.com)

I finally got somewhere with this.

When linking a plugin .so on OSX, cmake/clang was spewing Undefined symbols errors and exiting. Eg from libprotocol_register.so, the first plugin cmake builds:

Undefined symbols for architecture x86_64:
  "_gnutls_fingerprint", referenced from:
      _generate_digest in misc.c.o
      _generate_digest_raw in misc.c.o
[ ... and dozens more including from the babelouest ilbs ]

This is why I added those target_link_libraries so everything was built in the right order and no undefined symbols. (As to why those work fine on my cmake and crap out on Linux, still a mystery).

I got a travis-like build container and watched it link libprotocol_register.so. It was a-ok with missing symbols. Different linker behavior, could there be an option to change it?

Googling around I found LDFLAGS="-Wl,-undefined -Wl,dynamic_lookup" which allows bundle links with undefined symbols on my clang. Now I can do a complete compile without this PR, phew.

It's not totally satisfying because there are 2x the undefined symbols when linking under darwin vs linux. Eg, gnutls is available at the time libprotocol_register.so is linked, but cmake doesn't figure that out.

I finally got somewhere with this. When linking a plugin .so on OSX, cmake/clang was spewing `Undefined symbols` errors and exiting. Eg from libprotocol_register.so, the first plugin cmake builds: ``` Undefined symbols for architecture x86_64: "_gnutls_fingerprint", referenced from: _generate_digest in misc.c.o _generate_digest_raw in misc.c.o [ ... and dozens more including from the babelouest ilbs ] ``` This is why I added those `target_link_libraries` so everything was built in the right order and no undefined symbols. (As to why those work fine on my cmake and crap out on Linux, still a mystery). I got a travis-like build container and watched it link libprotocol_register.so. It was a-ok with missing symbols. Different linker behavior, could there be an option to change it? Googling around I found `LDFLAGS="-Wl,-undefined -Wl,dynamic_lookup"` which allows bundle links with undefined symbols on my clang. Now I can do a complete compile without this PR, phew. It's not totally satisfying because there are 2x the undefined symbols when linking under darwin vs linux. Eg, gnutls is available at the time libprotocol_register.so is linked, but cmake doesn't figure that out.

babelouest commented

2020-01-21 14:17:20 +01:00

(Migrated from github.com)

I'd rather get rid of your Undefined symbols errors once and for all, other OSX users may encounter the same problems.

Can you open an issue and post the full output of your cmake log?

I'd rather get rid of your `Undefined symbols` errors once and for all, other OSX users may encounter the same problems. Can you [open an issue](https://github.com/babelouest/glewlwyd/issues) and post the full output of your cmake log?

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Rows
Columns

CMakeLists.txt: add inter-library links for cmake #94

Pull request closed