C/C++ External dynamic library linkage -- example project?

  1. ‹ Older
  2. 2 years ago

    Stephen G

    2 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington
    Edited 2 years ago

    @Norman P --

    I think I was a little premature in my testing --

    When I went to add all of the soft declares as External Methods in a separate Module, my actual runtime calls couldn't locate them generated a FunctionNotFound exception. This time I was careful to make sure I was only building a 64-bit dylib, and a 64-bit Xojo executable. The dylib IS being copied into the built app's Content/Frameworks folder.

    Perhaps there's an Xcode build pref that still needs to be set? ALTHOUGH -- worked perfect when done through soft declare and path was provided...

    Do External Method names need to be prefixed with the name of the Module, if that External Method is declared as "Global"?

  3. Stephen G

    2 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Norman P -- OH, you are going to be AMAZED by this...

    As a TEST -- I uncommented the FIRST of four soft declares I had made during my initial testing (I had commented them out when I was testing adding all four External Methods to a separate Module)

    When I did that, then there was NO PROBLEM calling the other three External Methods -- either when RUNNING or BUILDING/Double-Clicking the built app.

    It's like my first soft declare (with an EXPLICIT absolute path) caused the dylib to be found and loaded, so there was no longer any kind of dynamic binding issue during execution.

    If I commented out that soft declare, none of the External Methods could be found now -- although there was absolutely no link warning about an undefined symbol.

    Does that theory make sense?

  4. Andrew L

    2 Nov 2017 San Francisco, CA, USA

    Did you click the "soft" check box on the external method editor?

  5. Stephen G

    3 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Andrew Lambert -- Yes, definitely set the "soft" check box. I think this has to do with WHERE Xojo is expecting to find the dylib -- OR the crazy dylib settings like @rpath that need to be set when linking the dylib.

  6. Norman P

    3 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...

    if the dylib is in this location "@executable_path/../Frameworks/<your dylib name here>" as a result of the copy files step then things should just work
    however you may need a constant with different values for macOS, Windows, iOS and Linux since they will be in different spot (particularly the iOS one)
    So dont use the "default" value of a string constant and add several different values with their language set to ANY but each having a different OS (macOS Cocoa, iOS, Windows and Linux) so there are 4 different entries - and the right value for each
    At compile time the correct one will be selected& used to compile your app

  7. Stephen G

    3 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Norman P --

    I'm just trying to get macOS working first. And now I THINK I have:

    The name of the lib's name in the External Method definition UI needed to be set to:

    @executable_path/../Frameworks/libTestLibForXojo.dylib

    ...which is what you said:

    if the dylib is in this location "@executable_path/../Frameworks/<your dylib name here>" as a result of the copy files step then things should just work

    But I though you meant if the dylib was IN THAT LOCATION -- which it already was. But I hadn't set the Lib name in the UI to that EXACT syntax.

    So it look good now!

    Thank you! (and everyone else)!

    ..now on to IOS / Windows tests....

  8. Norman P

    3 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...
    Edited 2 years ago

    ah yeah - the external needs to have the location as it will be at runtime since these are dynamically linked
    the link loader will find them at runtime based on that path when your app runs
    at compile time it doesnt matter where the actual dylib is since they are just going to be copied into your built app by the copy file step into the location you specified

  9. Stephen G

    3 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Norman P -- OK -- so you are agreeing with what we posted above:

    1) Name of the lib's name in the External Method definition UI needs to be set to: @executable_path/../Frameworks/<myDylibName.dylib>

    2) Must add a Build Step > Copy Files to copy the above dylib to the Framework Folder (in the App package). This will work for BOTH "run with Debugger" or launching the built executable App.

    3) In Xcode, the Linking Setting "Dynamic Library Install Name" should be just the name of the built dynamic library <myDylibName.dylib>, which is also the Xcode default of $(EXECUTABLE_PATH).

    4) A CONSTANT may be created to handle different dylib paths for multiple platforms. For example, #App.kDylibLocation can be defined for platform "OS X Cocoa" for "English" as "@executable_path/../Frameworks/<myDylibName.dylib>", but for "IOS" "English", it would need to be a different path (do you know what that path might need to be?)

    How's that?

  10. Norman P

    3 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...
    Edited 2 years ago

    That seems about right

    the iOS path seems like it should be @executable_path/Frameworks/<myDylibName.dylib>
    note the missing ..

    and you probably dont need these to be set for "english"
    any language should be fine

  11. Stephen G

    3 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Norman P -- on the subject of dynamic libraries and IOS --

    I'm running into the "FunctionNotFoundException" during the iPhone simulator execution when trying to soft declare against a C-API function in the dylib I generated for IOS 9.2 (arm7, arm64).

    I DO the build_step to copy the dylib to the Frameworks folder.

    Do I need to build the dylib as a "Framework" for this to work on IOS?

  12. Norman P

    3 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...

    the sims are x86 or x86_64 :)

  13. Stephen G

    3 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington
    Edited 2 years ago

    @Norman P -- OHHHHH -- so for the IOS simulator, i.e. Xojo's "RUN and DEBUG" option, I should use the same old dylib as MacOS? Not code built for arm7/arm64? Is that true of BUILD, too?

    AND TO BE CLEAR: are you saying I should build a .dylib in Xcode against the IOS SDK but with the x86 / x86_64 architecture? Or simply USE the same Xcode-generated x86 / x86_64 dylib I build for MacOS? NOTE: in either case, these are pure C++ code libraries -- completely cross-platform -- no cocoa (or carbon) whatsoever.

    At what point do I build an arm64 dylib for deploying on real IOS hardware, and can Xojo do a build integrating that dylib in a way acceptable to the Mac App store (unlike posts on this forum from 16 months ago, which stated the Mac App store would NOT accept a dylib)?

    Your documentation states that the simulator only (presently) runs a 32-bit app. Has that changed? Obviously, 32-bit is now history on IOS.

  14. Norman P

    4 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...
    Edited 2 years ago

    @StephenGreenfield @Norman P -- OHHHHH -- so for the IOS simulator, i.e. Xojo's "RUN and DEBUG" option, I should use the same old dylib as MacOS? Not code built for arm7/arm64? Is that true of BUILD, too?

    I'd used one built for iOS if there are sdk dependencies. if not the macOS x86 should be OK
    The simulators run x86 code so they are only simulating what you will experience on da real device
    They do not run arm or arm7 code
    For deployment you should use arm / armv7 code

    @StephenGreenfield AND TO BE CLEAR: are you saying I should build a .dylib in Xcode against the IOS SDK but with the x86 / x86_64 architecture? Or simply USE the same Xcode-generated x86 / x86_64 dylib I build for MacOS? NOTE: in either case, these are pure C++ code libraries -- completely cross-platform -- no cocoa (or carbon) whatsoever.

    I'd expect that you could use the same dylib as macOS as I expect, but honestly dont know for sure, that they both support the same C++ runtimes

    @StephenGreenfield At what point do I build an arm64 dylib for deploying on real IOS hardware, and can Xojo do a build integrating that dylib in a way acceptable to the Mac App store (unlike posts on this forum from 16 months ago, which stated the Mac App store would NOT accept a dylib)?

    You cannot statically link in a dylib - in Xojo or any other tool
    As for submission to the app store I am not 100% sure if they will or will not accept apps with dylibs in the Frameworks dir of the app package

    @StephenGreenfield Your documentation states that the simulator only (presently) runs a 32-bit app. Has that changed? Obviously, 32-bit is now history on IOS.

    You can actually debug in 32 bit (set break points etc and step through code)
    You can RUN in 64 bit but debugging is not possible as it is for 32 bit

    When you build we always, currently, build a universal app which as 32 and 64 bit code

  15. Christian S

    4 Nov 2017 Pre-Release Testers, Xojo Pro, XDC Speakers, Third Party Store Germany

    when you build for simulator, Xcode will automatically build x86/x64 for you.

  16. Stephen G

    4 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Norman P --

    I think the problem(s) I'm running into with IOS MAY be due to using Xcode 7.2.1. Xcode 8.x is the minimum required for proper IOS & Xojo?

  17. Stephen G

    4 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    I'm also seeing an issue with normal macOS where a Xojo External Method with a parameter of Int32 is not finding the corresponding C-API dylib function with that parameter defined as int32_t. That should absolutely work, right?

  18. Norman P

    4 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...

    @StephenGreenfield @Norman P --

    I think the problem(s) I'm running into with IOS MAY be due to using Xcode 7.2.1. Xcode 8.x is the minimum required for proper IOS & Xojo?

    For what you're doing Xcode 7 or 8 should be OK as really Xojo just needs to be able to start the simulator & those two versions behave similarly in this regard

  19. Norman P

    4 Nov 2017 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...

    @StephenGreenfield I'm also seeing an issue with normal macOS where a Xojo External Method with a parameter of Int32 is not finding the corresponding C-API dylib function with that parameter defined as int32_t. That should absolutely work, right?

    I'd expect so yes

  20. Stephen G

    4 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    @Norman P --

    Got Xojo's invocation of the IOS SIMULATOR to access and correctly call dylib, but ONLY if I use soft declare and provide a full path to the dylib.

    But trying to use the External Method approach didn't work for IOS as it had for macOS -- it results in a compile-time error, "this item does not exist", for each of the External Methods I call.

    HOW I SET UP THE EXTERNAL METHODS:

    • Build Copy step copies dylib to Frameworks
    • Lib field in External Method definition uses @executable_path/Frameworks/libIOSTestLibForXojo_simulator.dylib
    • Soft checkbox selected; Objective-C checkbox NOT selected. Scope = "Global"

    Even explicitly setting each External Method's Lib field to the same exact path as I provided for soft declare results in the compile-time error "this item does not exist" for each call.

    In both cases (soft declare and External Method) the dylib was compiled for i386 architecture. That worked perfectly with soft declare and IOS Simulator.

    Is there any documentation, FAQ, tutorial, etc. that discusses the library path for calling one's own dylib / framework for an IOS project?

  21. Stephen G

    4 Nov 2017 Pre-Release Testers, Xojo Pro Ellensburg, Washington

    As for submission to the app store I am not 100% sure if they will or will not accept apps with dylibs in the Frameworks dir of the app package

    @Norman Palardy --

    I'm happy to package my library for IOS by any method (dylib, Framework, or Xcode-linked .a file) that allows it to become part of the Xojo-generated app but it MUST get into the app store. There MUST be an absolute sure-fire route to do so, Right? Otherwise the thousands of IOS MonkeyBread functions offered by @Christian Schmitz wouldn't function on IOS?

    I have a large, deep, and battle-tested library of non-UI cross-platform C++ code with a C-API that is essential to work with the Xojo front end on ALL platforms.

  22. Newer ›

or Sign Up to reply!