Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make_compile.py not working properly when adding additional option in configuration #2

Open
pasin-k opened this issue Nov 25, 2022 · 9 comments

Comments

@pasin-k
Copy link

pasin-k commented Nov 25, 2022

First of all, thank you for your help. It really helps the project I have been working on. Running it as is, works wonderfully.

However, when I add --enable-libvpx option in make_compile.py the overall programs failed.

Apparently, one of the problem is during arm64 building (my Mac is x86_64).

----------arm64----------
Clean project.
Execute: cd /Users/pasin/Documents/project/ffmpeg-universal-xp/ffmpeg && make clean && make distclean.
Configure project.
Execute: cd /Users/pasin/Documents/project/ffmpeg-universal-xp/ffmpeg && ./configure --enable-cross-compile --prefix=/Users/pasin/Documents/project/ffmpeg-universal-xp/ffmpeg/install_arm64 --disable-shared --enable-static --enable-libvpx --arch=arm64 --cc='clang -arch arm64'.
libvpx enabled but no supported decoders found

So I guess there is a library required that does not supports 'arm64'.

However, the strange thing is that install_x86_64 folder which build successfully does not have vpx files at all, which makes me suspect that even the x86_64 version also somehow not building completely finish.

Do you have any idea what went wrong here?

@ColorsWind
Copy link
Owner

ColorsWind commented Nov 25, 2022

I tested in my machine (Apple M1). I found that, as expected. ARM64 successed but x86_64 fails. Message shows:
libvpx enabled but no supported decoders found.
According to FFmpeg document:
https://trac.ffmpeg.org/wiki/Encode/VP9
https://trac.ffmpeg.org/wiki/CompilationGuide
libvpx should be installed if you want to enable vpx encoder.
In your x86_64 mac, you can simplily use homebrew to install libvpx. However, if you want ARM64 libvpx, it will be a little difficult.
You need to compile it by yourself (libvpx does offer cross development guide, use --target option) and make make find the ARM64 version libvpx in some way.
Looking forward to your feedback.

@pasin-k
Copy link
Author

pasin-k commented Nov 28, 2022

I see. Thank you for your information. I don't have much experience compiling these libraries (especially cross-platform), so I am looking for some alternative approach if possible.

I wonder if I build x86_64 FFmpeg on my mac and receive a compiled arm64 FFmpeg on another M1 mac, is it possible to combine using make_universal.py?

@ColorsWind
Copy link
Owner

ColorsWind commented Nov 28, 2022

I think works, but you need to make some modifications to the script.
You know, macos binary library contains referenced library path, so to prevented library not found error, I need to do some additional work. For simplicity, I just I assumed that ARM64 version of FFmpeg is in the dir install_arm64 while x86 version in install_x86_64 (If it was compiled by my script, it is correct). The way I fix this problem is use install_name_tool -id to query those path and use install_name_tool -change to change them. You need to pay attention to this part.
If you encountered any problem, feel free to reply.

@pasin-k
Copy link
Author

pasin-k commented Nov 28, 2022

So I tried doing the approach I mentioned, asking my colleague to build one and copy the folder install_arm64 inside my ffmpeg folder (which already has built install_x86_64 folder). The combining process success, but during runtime of the actual library usage, it raises this error:

more than one platform supports this executable (host, remote-macosx), specify an architecture to disambiguate

I assume there is something wrong when trying to combine two files built by two different Mac..?

@ColorsWind
Copy link
Owner

Did you build those two version in the same place? The reference library path may contains absolute path. So if you and your colleague built in home dir, it may cause proble. By the way, you can use otool -L libavutil.a to see the referenced library path.

@pasin-k
Copy link
Author

pasin-k commented Nov 28, 2022

I forgot to mention that my colleague did change code a little bit so it is not absolute path dependent.

Here is the result using otool -L libavutil.dylib

ffmpeg_final1 % otool -L ./lib/libavcodec.58.35.100.dylib 
./lib/libavcodec.58.35.100.dylib:
	@rpath/libavcodec.58.dylib (compatibility version 58.0.0, current version 58.35.100)
	@rpath/libswresample.3.dylib (compatibility version 3.0.0, current version 3.3.100)
	@rpath/libavutil.56.dylib (compatibility version 56.0.0, current version 56.22.100)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	/usr/local/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.7.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
	/System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
	/System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1141.1.0)

It should now only redirect to relative path and should not be the problem (Unless I miss something)

@ColorsWind
Copy link
Owner

ColorsWind commented Nov 28, 2022

Could you launch the program without debug? Maybe it's releated to the following issue:
swiftlang/llvm-project#4294
microsoft/vscode-cpptools#9067

@pasin-k
Copy link
Author

pasin-k commented Nov 28, 2022

Ah, I see now that this error only occurs in Debug mode (usually I run my code in debug mode by default). At the very least, I can run it on release mode (or debug mode but I need to set the architecture to just x86_64.

So, I guess using two built file kind of works, but we still don't have a way to compile it on one device then.

@ColorsWind
Copy link
Owner

I seems like the previous problem is related to apple LLDB.

You cannot debug the arm64 slice of your binary on an Intel-based Mac computer. It’s possible to debug both slices of a universal binary on Apple silicon (under Rosetta translation).
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

You can also test ARM64 version on Apple Silicon machine.

As I mentioned, compiling it on a device requires extra work (Maybe I will try in the further). But lucky if you don't upgrade ffmepg, you don't need to compile again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants