I also just tried --target 4.4 when building with craft and it built just fine with correct links and install names. So maybe this must be some issue specific to the latest ffmpeg version.
> On May 14, 2022, at 4:36 PM, Robert Lancaster <rlanca...@gmail.com> wrote: > > I dug a little deeper, I can confirm that this issue occurs when ffmpeg is > being installed and it occurs whether or not the cache is used. It is > already incorrectly linked in the image directory in the craft build > directory for ffmpeg. It seems that the cause is that the install name is > incorrect for two of the ffmpeg packages. Here is a piece of the build log > for ffmpeg during the building of these libraries showing the two similar > issues which then cause the aforementioned linking problem: > > /usr/bin/clang -dynamiclib -Wl,-single_module > -Wl,-install_name,/Users/rlancaste/AstroRoot/craft-root/build/libs/ffmpeg/image-RelWithDebInfo-5.0.1/Users/rlancaste/AstroRoot/craft-root/lib/libavdevice.59.dylib,-current_version,59.4.100, > > /usr/bin/clang -dynamiclib -Wl,-single_module > -Wl,-install_name,/Users/rlancaste/AstroRoot/craft-root/build/libs/ffmpeg/image-RelWithDebInfo-5.0.1/Users/rlancaste/AstroRoot/craft-root/lib/libavfilter.8.dylib,-current_version,8.24.100, > > Here is one where the install name is correct, which means that it will then > be fine when linked: > > /usr/bin/clang -dynamiclib -Wl,-single_module > -Wl,-install_name,/Users/rlancaste/AstroRoot/craft-root/lib/libavutil.57.dylib,-current_version,57.17.100, > > > So, somehow either something in the code in the new version of ffmpeg for > these two libraries is incorrectly giving them the wrong install name, or > something is wrong with the recipe causing the same problem. > > Thanks, > > Rob > >> On May 14, 2022, at 4:07 PM, Robert Lancaster <rlanca...@gmail.com >> <mailto:rlanca...@gmail.com>> wrote: >> >> I believe there was a commit that you made around that time that changed >> ffmpeg, but I can’t guarantee that this must be the cause. >> >> https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/fe148aaee6d777e9e808a4613f942ec734516b7e >> >> <https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/fe148aaee6d777e9e808a4613f942ec734516b7e> >> >>> On May 14, 2022, at 4:05 PM, Robert Lancaster <rlanca...@gmail.com >>> <mailto:rlanca...@gmail.com>> wrote: >>> >>> Hi Hannah, >>> >>> Something changed in the craft build of FFMPEG between May 2nd and May 4th. >>> We are now getting this error when packaging KStars on Binary Factory. >>> https://binary-factory.kde.org/view/MacOS/job/KStars_Nightly_macos/ >>> <https://binary-factory.kde.org/view/MacOS/job/KStars_Nightly_macos/> >>> >>> The last successful build was May 2nd. >>> >>> [2022-05-05T17:22:22.892Z] >>> /Users/packaging/Craft/BinaryFactory/macos-64-clang/build/kde/applications/kstars/archive/Applications/KDE/kstars.app/Contents/Frameworks/libavdevice.59.4.100.dylib: >>> don't know how to handle otool -L output: >>> '/Users/packaging/Craft/BinaryFactory/macos-64-clang/build/libs/ffmpeg/image-RelWithDebInfo-5.0.1/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib/libavfilter.8.dylib' >>> >>> It looks to me like there is a linking issue. For some reason, the >>> (nonexistent) path for libavfilter stored in libavdevice is: >>> >>> '/Users/packaging/Craft/BinaryFactory/macos-64-clang/build/libs/ffmpeg/image-RelWithDebInfo-5.0.1/Users/packaging/Craft/BinaryFactory/macos-64-clang/lib/libavfilter.8.dylib' >>> When it should be either >>> /Users/packaging/Craft/BinaryFactory/macos-64-clang/lib/libavfilter.8.dylib >>> Or >>> @rpath/libavfilter.8.dylib >>> In fact all the other ffmpeg dylibs are linked like this: >>> >>> /Users/packaging/Craft/BinaryFactory/macos-64-clang/lib/libavfilter.8.dylib >>> >>> It is just that one that is wrong. >>> >>> Was there some sort of craft change which would break this? >>> >>> Thanks, >>> >>> Rob >> >
smime.p7s
Description: S/MIME cryptographic signature
