undefined reference to `_Ux86_64_getcontext'

[johnsongash]

Hi @hombit ,
there is some issue building ceres-solver-rs,

after adding dependency in cargo.toml,
ceres-solver = { version = "0.2.1", features = ["source"] }

getting error building in my project
in function google::GetStackTrace(void**, int, int)': utilities.cc:(.text._ZN6google13GetStackTraceEPPvii+0x4f): undefined reference to _Ux86_64_getcontext'
/usr/bin/ld: utilities.cc:(.text._ZN6google13GetStackTraceEPPvii+0x5c): undefined reference to _ULx86_64_init_local' /usr/bin/ld: utilities.cc:(.text._ZN6google13GetStackTraceEPPvii+0xc3): undefined reference to _ULx86_64_step'
/usr/bin/ld: utilities.cc:(.text._ZN6google13GetStackTraceEPPvii+0xdc): undefined reference to _ULx86_64_get_reg' /usr/bin/ld: utilities.cc:(.text._ZN6google13GetStackTraceEPPvii+0xef): undefined reference to _ULx86_64_step'
collect2: error: ld returned 1 exit status

[hombit]

Hello @johnsongash,

It looks like linter cannot find libunwind, but I'm not sure why does it need it. I tried to reproduce your issue in a clean Docker setup, with the latest rust image, and everything worked fine to me. That image does not have libunwind.

Could you please give more details about your setup? I'm not sure what exactly we need to solve it, but maybe you could share OS version, c++ compiler, linter and Rust version? Do you have libunwind in your system?

[johnsongash]

Hi @hombit,
Thanks for the time,
after setup a clean environment everything works fine.
Maybe some dependency issue with ceres-solver build from source?

[hombit]

@johnsongash, thank you for the report!

I still cannot reproduce it. Feel free to reopen / open a new one when you catch the problem again

[HoKim98]

Same issue here. Building glog and ceres with BUILD_SHARED_LIBS=ON could resolve the issue.

Updated branch: https://github.com/ulagbulag/ceres-solver-rs/tree/fix/change-linking-method-to-dynamic

Feel free to check it and I'll push a PR.

[hombit]

@kerryeon thank you so much for investigating. Could you please tell me about your environment so I can reproduce the issue?

My problem with dynamic linking is that the final user of the library cannot make their binary portable: it would depend on the .so files we built in their target directory. I would be really nice to solve the issue keeping static linking.

[hombit]

@kerryeon @johnsongash could you please check it again with version 0.3.0? I hopefully dropped unwind dependency from vendored glog