Btukfyl

Is it possible to publish/share secondary dylib inside framework (xxx.framework/Library/*.dylib) to external (visible when external app links)?

//

I am trying to encapsulate multiple libavXXX.dylib (from ffmpeg project) into single Framework (MElibrary.framework).
Currently I am stuck at "unable to make it visible - secondary dylib files inside Framework - to linker when link to Framework".
Is this feasible plan with Framework bundle?

Problem what I am stuck at for now

• When test app link with my framework, build is failed. Linker(ld) does not find my secondary dylib files inside framework/Libraries/ directory.

What I did till now

• Prepare MElibrary.framework/Versions/A/Libraries/ (and its symlink as MElibrary.framework/Libraries)


• Place every libavxxx.dylib (and its symlinks) into MElibrary.framework/Libraries/


• Update dylib id/lib paths using install_name_tool to @rpath/MElibrary.framework/Versions/A/Libraries/xxx.dylib


• Place libavxxx header files into xxx.framework/Headers/include/libavxxx/xxx.h


• Include major header files like #include "include/libavxxx/xxx.h" in MElibrary.h


• Make module.modulemap and define secondary dylib headers as submodules


• Link secondary dylib with MElibrary itself


• Confirms using otool -LX or otool -DX that MElibrary itself and every dylib files have @rpath/MElibrary.framework/Versions/A/... paths.


• Try to build test app with framework linked


• Confirmed compilation step is passed using libavxxx functions


• But build failed because link step failed every time


• I think this is because secondary dylib files are not visible by linker

Error messages

Undefined symbols for architecture x86_64:

  "_avcodec_register_all", referenced from:

      -[ViewController viewDidLoad] in ViewController.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

My Framework structure is following:

MElibrary.framework

 + Headers (symlink)

 + Libraries (symlink)

 + MElibrary (symlink)

 + Modules (symlink)

 + Resources (symlink)

 + Versions

   + Current (symlink)

   + A

     + Headers

       + MElibrary.h

       + include

         + libavcodec/....h

         + :

     + Libraries

       + libavcodec.xxx.dylib .... I want these dylib visible when framework is linked

       + :

     + MElibrary .... framework dylib itself (dummy - no code)

     + Modules

       + module.modulemap

     + Resources

       + Info.plist

Update

Siguza, Thank you for your comment. I have been working with "Xcode10.1/Build Settings/Re-Exported Library Names" to verify the functionality - but no success till now.

ld: file not found: @rpath/MElibrary.framework/Versions/A/Libraries/libavcodec.58.dylib for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

Referencing boonerhasit's comment "From here, it seems dyld doesn't resolve the @rpath for the LC_REEXPORT_DYLIB command, only LC_LOAD*_DYLIB commands.",

my framework with otool -l MElibrary.framework/MElibrary shows:

Load command 9

          cmd LC_REEXPORT_DYLIB

      cmdsize 96

         name @rpath/MElibrary.framework/Versions/A/Libraries/libavcodec.58.dylib (offset 24)

   time stamp 2 Thu Jan  1 09:00:02 1970

      current version 58.33.102

compatibility version 58.0.0

Conclusion (Failed)

After multiple test, I have concluded my original plan is not feasible.

Linker does not understand @rpath based, re-exported dylib. I am not sure though I guess it would be of security reason.

• Framework itself can have secondary dylib(s) inside Framework though, it is dedicated for internal use only. They are inside Framework so should have "@rpath" relative path. "@rpath" based dylib is not "re-export-able".


• If you have to export symbols of secondary dylib(s) you may use ld's option -reexport-l (-reexport-lavcodec for example), but it does not work as intended in this case.


• Exported library is defined in LC_REEXPORT_DYLIB command. You can confirm that otool -l shows exported secondary library paths. But linker ld itself does not understand "@rpath" word, and linker always fails to link your framework because of "ld: file not found: @rpath/......dylib for architecture x86_64".


• Every binary in Framework will be relative path "@rpath" and only external dylib with full path is re-export-able.