Closed kinetiknz closed 5 years ago
That is caused by a missing pthread
linker flag, fixed in https://github.com/kinetiknz/cubeb/commit/0d1d9d84fb3e827615903a79d2411a49789f0de3
Now it fails while building cubeb-sys with:
error: could not find native static library `cubeb`, perhaps an -L flag is missing?
Which is caused by the built libcubeb.a being installed to lib64
rather than lib
, which cubeb-sys's build.rs doesn't account for.
There's also some scary sounding warnings:
warning: `extern` block uses type `()` which is not FFI-safe: tuples have unspecified layout
--> cubeb-sys/src/log.rs:21:23
|
21 | log_callback: cubeb_log_callback,
| ^^^^^^^^^^^^^^^^^^
|
= note: #[warn(improper_ctypes)] on by default
= help: consider using a struct instead
Which is caused by the built libcubeb.a being installed to
lib64
rather thanlib
, which cubeb-sys's build.rs doesn't account for.
https://github.com/alexcrichton/cmake-rs/issues/56 is related, but it's not clear what the correct fix is supposed to be. I don't think we can check for 32 vs 64-bit builds in build.rs, since some 64-bit builds still use lib
- what we really need to know is the value of CMAKE_INSTALL_LIBDIR.
A simple fix seems to be adding both lib
and lib64
to the search list, so I'll do that for now.
CI build fixed. It's not clear how to address the FFI warnings, but they're unrelated to the CI issues.
It's not clear how to address the FFI warnings
The Docker image is using a nightly from 2019-03-03. These warnings don't seem to appear in recent nightlies (maybe ever since Rust PR 57760 landed - edit: yes, a nightly from the 27th March no longer warns).
Do you still have the instructions on how to spin up a new docker image? Maybe the docker image could be modified to install the latest nightly compiler at the cost of increased CI turn around?
On Tue, 2 Jul 2019 at 1:19 pm, Matthew Gregan notifications@github.com wrote:
It's not clear how to address the FFI warnings
The Docker image is using a nightly from 2019-03-03. These warnings don't seem to appear in recent nightlies (maybe ever since Rust PR 57760 landed?).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/djg/cubeb-rs/issues/43?email_source=notifications&email_token=AABGDLOZ2PJCUKNZG37LS5LP5LCLZA5CNFSM4H4XJX6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY753HA#issuecomment-507501980, or mute the thread https://github.com/notifications/unsubscribe-auth/AABGDLJOKL2R3S5C3BJUIT3P5LCLZANCNFSM4H4XJX6A .
-- Dan Glastonbury, Dan dot Glastonbury at gmail dot com `Pour encourjay lays ortras'
That's doable. Is there a reason to use CircleCI + Docker over Travis? It seems like it'd be easier to use a simple Travis setup and not have to mess with Docker at all.
I don't think there is a reason to use CircleCI over Travis. Not sure if I thought that docker would give us more control of OS + dependencies vs Travis at the time of setup.
On Tue, 2 Jul 2019 at 14:53, Matthew Gregan notifications@github.com wrote:
That's doable. Is there a reason to use CircleCI + Docker over Travis? It seems like it'd be easier to use a simple Travis setup and not have to mess with Docker at all.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/djg/cubeb-rs/issues/43?email_source=notifications&email_token=AABGDLIZHVUHDB2SACYAEE3P5LNOLA5CNFSM4H4XJX6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZABVMI#issuecomment-507517617, or mute the thread https://github.com/notifications/unsubscribe-auth/AABGDLLLTKFOKEIYFFCGY23P5LNOLANCNFSM4H4XJX6A .
-- Dan Glastonbury, Dan dot Glastonbury at gmail dot com `Pour encourjay lays ortras'
Builds are failing while building libcubeb via cubeb-sys with: