search

ralfbiedert / openh264-rs

Idiomatic Rust wrappers around OpenH264.
69 stars 35 forks source link

Updating to 0.3.0: error: linking with `cc` failed: exit status: 1 #24

Closed mikbry closed 1 year ago

mikbry commented 1 year ago

I got error: linking withccfailed: exit status: 1 And a list of undefined symbols:

= note: Undefined symbols for architecture x86_64:
            "_AnalysisVaaInfoIntra_sse2", referenced from:
                WelsEnc::InitIntraAnalysisVaaInfo(WelsEnc::TagWelsFuncPointerList*, unsigned int) in libopenh264_sys2-62705b02f590407b.rlib(md.o)
            "_AnalysisVaaInfoIntra_ssse3", referenced from:
                WelsEnc::InitIntraAnalysisVaaInfo(WelsEnc::TagWelsFuncPointerList*, unsigned int) in libopenh264_sys2-62705b02f590407b.rlib(md.o)
            "_BilateralLumaFilter8_sse2", referenced from:
                WelsVP::CDenoiser::InitDenoiseFunc(WelsVP::TagDenoiseFuncs&, int) in libopenh264_sys2-62705b02f590407b.rlib(denoise.o)
            "_CavlcParamCal_sse42", referenced from:
                WelsEnc::InitCoeffFunc(WelsEnc::TagWelsFuncPointerList*, unsigned int, int) in libopenh264_sys2-62705b02f590407b.rlib(set_mb_syn_cavlc.o)
            "_DeblockChromaEq4H_ssse3", referenced from:
                WelsEnc::DeblockingInit(WelsEnc::tagDeblockingFunc*, int) in libopenh264_sys2-62705b02f590407b.rlib(deblocking.o)
            "_DeblockChromaEq4V_ssse3", referenced from:
                WelsEnc::DeblockingInit(WelsEnc::tagDeblockingFunc*, int) in libopenh264_sys2-62705b02f590407b.rlib(deblocking.o)
            "_DeblockChromaLt4H_ssse3", referenced from:
                WelsEnc::DeblockingInit(WelsEnc::tagDeblockingFunc*, int) in libopenh264_sys2-62705b02f590407b.rlib(deblocking.o)
            "_DeblockChromaLt4V_ssse3", referenced from:
                WelsEnc::DeblockingInit(WelsEnc::tagDeblockingFunc*, int) in libopenh264_sys2-62705b02f590407b.rlib(deblocking.o)
            "_DeblockLumaEq4V_ssse3", referenced from:
                WelsEnc::DeblockingInit(WelsEnc::tagDeblockingFunc*, int) in libopenh264_sys2-62705b02f590407b.rlib(deblocking.o)
                _DeblockLumaEq4H_ssse3 in libopenh264_sys2-62705b02f590407b.rlib(deblocking_common.o)
            "_DeblockLumaLt4V_ssse3", referenced from:
                WelsEnc::DeblockingInit(WelsEnc::tagDeblockingFunc*, int) in libopenh264_sys2-62705b02f590407b.rlib(deblocking.o)
                _DeblockLumaLt4H_ssse3 in libopenh264_sys2-62705b02f590407b.rlib(deblocking_common.o)

If I use 0.2.18 and revert back YUV changes, all is building and running fine.

I am on Macos Ventura x64

ralfbiedert commented 1 year ago

Thanks for the report. My guess is this is related to the openh264-sys2/build.rs changes I made to clean things up, which must have caused some issues (likely around try_compile_nasm()).

I don't have a Mac anymore and would greatly appreciate if you or someone could help debugging this.

gil0mendes commented 1 year ago

It seems like it was working before because nasm was not being used at all.

Before there was a flag #[cfg(feature = "asm")], if the asm was not defined nasm would not be used. In the other hand, now, the code inside try_compile_nasm is always executed.

This can be proved by removing the contents of the try_compile_nasm function.

fn try_compile_nasm(cc_build: &mut Build, root: &str) {}

Now, when we run the cargo command, it will be linked with no problem.

ralfbiedert commented 1 year ago

Thanks! Do you have nasm installed on MacOS? Like, is only the detection broken, or is this related to some bad flags?

gil0mendes commented 1 year ago

In reality there is something really wild going on because I was able to compile it just fine yesterday, the problem only started today; that is the reason why I found this GitHub issue 😅

I don't recall change anything since yesterday on my environment. I have nasm version 2.15.05 installed, and seems like the build.rs is detecting it correctly.

Another thing that I did, was to copy the function code from a previous state, without the #[cfg(feature = "asm")] condition and the result is the same.

Any hint on you better debug what is happening, I'm running out of ideas 😬

ralfbiedert commented 1 year ago

What OS / Rust version do you use?

gil0mendes commented 1 year ago

OS: macOS 12.6.1 Rust: 1.67.0-nightly, but already tested with stable 1.61.0

gil0mendes commented 1 year ago

Also, if I look for the supposed missing symbols on the library they are there 🤔

nm /Users/gil0mendes/projects/ghost-screen/openh264/target/debug/deps/libopenh264_sys2-ba9a72295344cf6d.rlib | grep DeblockChromaEq4H_ssse3
/Users/gil0mendes/projects/ghost-screen/openh264/target/debug/deps/libopenh264_sys2-ba9a72295344cf6d.rlib:lib.rmeta: no symbols
00000000000009d0 T DeblockChromaEq4H_ssse3
                 U _DeblockChromaEq4H_ssse3
                 U _DeblockChromaEq4H_ssse3
gil0mendes commented 1 year ago

I just opened a PR with a possible fix to this issue. Happy to apply any change or suggestion to enhance it 😊

ralfbiedert commented 1 year ago

0.3.1 is out which hopefully fixes this, thanks @gil0mendes. Please comment or reopen if it doesn't.

gil0mendes commented 1 year ago

No problem, was a pleasure to contribute 😊

@mikbry if you have the time just to confirm if this fixes it for you too would be wonderful, tks 🤗

mikbry commented 1 year ago

Thanks @gil0mendes @ralfbiedert , 0.3.1 fixes the prb !