In my qmake .pro file I add my desired dynamic library to LIB which allows for compilation but doesn't link to the library in the compiled application (i.e. I get a library not found error at run time).
The problem is that I have the library in my build directory, not in the system directory (i.e. /usr/lib). But, I want to generate a OSX app that doesn't touch the system outside of the .app folder.
Also, I'd link to know how to do this on a linux system - is it possible?
My question is related to the Qmake generating a proper .app question but differs in that the link that answers that question doesn't answer my question.
Put a wrapper script round your program so the current working directory is in the dynamic library search path:
#!/bin/bash
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
./program
Related
I must have read over a dozen posts on possible techniques to link a local library into my Swift Package. Specifically, my package depends on libturbojpeg.a, which most users won't have installed anywhere. Even if they did install it (there is a DMG), I'd have to go through hoops to make sure I was linking in the correct version. I finally found a post in the Swift Forums that basically says you can't do it now.
It appears that the only way to link it now is using .linkerSettings(LinkerSetting.unsafeFlags(..., but if you use that your package can't be managed by Xcode (see above link, and I even tried it and verified it cannot be used).
Is there some kind of workaround that allows me to distribute my Swift Package with the library?
In my Package, I created a directory "Libraries" and added my library there.
I discovered that Xcode 11 places included Swift Packages in a specific location in the Derived Folders directory. This means that it is possible to tell Xcode where to find it during the link phase.
My Package has these instructions in it for users:
1) Add the Package using Xcode->File->Packages with the URL of https://github.com/dhoerl/
2) Open the app's Project Build Phases, and from the Package shown in the left file pane, drag the Libraries/.a file into the link phase. It will appear just above the that should already be there
3) In Application Build settings, under library search paths, add:
"$(BUILD_DIR)/../../SourcePackages/checkouts//Libraries"
Build and run! Voíla - works like a charm!
Note: obviously this is somewhat fragile, Xcode 12 could change how packages are managed, but its possible by then that the Swift Package Manager will support linking of local libraries (its mentioned in the above link.)
I'm trying to load a custom .dylib library via the dlopen() function (in a Swift iOS app). It requires a path to the library.
Where to put the library in the project structure?
What will be the library's path on the iOS device?
Also, a tangential question, it seems more usual to include the library's sources directly into the project and let Xcode build it. Is that a preferable approach for some reason?
1 )
If you include the .dylib library in with your list of files and resources in your project, you can use the "Copy Files" build phase to copy the dylib into your shipping app.
A tutorial can be seen here.
2 )
For dlopen, try using just the .dylib name before you try to use relative paths including the "#executable_path" or "#rpath" run time variables. An example can be seen here in this related question.
As for why some developers prefer to include the library source code in a project, I believe it's mostly just a preference by folks who aren't comfortable with the "Copy Files" build phase or in using dlopen.
I just followed a tutorial https://medium.com/#PyBaig/build-your-own-cocoa-touch-frameworks-in-swift-d4ea3d1f9ca3 for creating your own cocoa touch framework. There is one step where you need to right click a framework and it shows in finder, but it is not working for me. I can right click any other file and show in finder just fine. Any suggestions on how to find the framework file for dragging into another project?
well according to some apple doc I found:
Note: The standard locations for frameworks are the
/System/Library/Frameworks directory and the /Library/Frameworks
directory on the local system.
If it isn't in those directories, it is probably some custom path that would be specified on the CC line in the build output, and if you were really hard up, you could click the diff editor on the Xcode project and search for something.Framework, where something is the framework you are looking for.
... it is also possible that it is a framework that is build by a sub-project, and for whatever reason, it haven't been built yet.
we want to create a MobFox-Plugin for our hybrid apps. It is already running well in CLI-Cordova Apps, but it does not work in our hybrid apps, because it seems that the directory structure of the framework (the symbolic links between headers and version directory) is destroyed by Windows, where the framework is inside the plugin in the mda project. If I start a build, the header directory of is not recognized as a symbolic link, but as an ordinary executable textfile on the Mac.
This is how I include the framework in the plugin xml:
<framework src="libs/ios/MobFox.framework" custom="true"/>
I also tried to copy the MobFox.framework to the SDK Frameworks Folder and reference it like the standard system libraries (which work well):
<framework src="MobFox.framework" />
But this also fails, though the Framework is now included correctly in Xcode. But the compiler now says that it cannot find the MobFox.h-class, this is how it's included:
#import <MobFox/MobFox.h>
So I really think that the problem is that Windows cannot handle the symbolic links inside the .framework File. Does anybody has a workaround or solution for this problem? Or an idea why my Workaround with placing the file in the Standard-Frameworks Folder does not work?
Any help would be highly appreciated.
Thanks
Same problem here - it appears that when the plugin is published to the cordova registry it loses the symbolic links inside the .Framework package that tell XCode where everything is.
They are maintained on git, so it is something in the plugman export/publish that is going wrong.
So for example
cordova plugin add https://github.com/uxcam/cordova-uxcam
will work for the plugin I am writing, but not
cordova plugin add com.uxcam.cordova.plugin
which is the published version.
If you delve down into the 'plugins' folder of the project you added it too and 'show package contents' on the com.uxcam.cordova.plugin file you can then get into 'src/ios'UXCam.framework' and see how it has messed up the symbolic links in the framework folder that should point at the Headers folder and a link the the library binary as well.
Reference: Cordova bug report here: https://issues.apache.org/jira/browse/CB-6092
Update: I've worked around the problem by manually putting files in the framework into the places they need to be. So now on the github project I reference above you can see that the framework library is directly in the UXCam.framework folder, and there is an explicit Headers folder that has the UXCam.h file in it. This works for a published plugin now.
Not an ideal solution and every time I update the framework I'll have to fix the layout again, but works for now until I can find the proper place to report the problem.
My application is not seeing source code for a library:
If I "Jump to definition" on a library method, XCode takes me to the .h file but says there is no .cpp counterpart
When debugging, I see no source code and most of the call-stack is missing for the library:
I have made sure "Show disassembly when debugging" is UNchecked
I built the library as DEBUG and then packaged up the headers+.a file into a SDK dir. So I guess I need to either copy the debug files into that SDK dir as well, or tell my application where to look. I'm not sure how to do either.
To clarify, my application project doesn't maintain a reference to the library project, only to the .a files and the header dirs. This is because the library project is created by CMake and I don't want to modify it.
First of all, you should check the .debug_str section of your static library to verify it contains the appropriate debug information.
Try running this command on the terminal:
xcrun dwarfdump /path/to/library.a | grep "\.m"
You should see a bunch of your source (.m) file paths printed out. Theoretically, this is where Xcode is going to look when you stop in the debugger, so make sure the paths here are correct. If you don't see any paths, you will need to pass an appropriate debug flag (e.g. -g to the compiler when building your library.
If the paths are somehow incorrect, or you want to point them to some other location, you may be able to modify them as part of the build process in CMake, for example to make them relative to your project directory. Try looking at "Make gcc put relative filenames in debug information", which uses CMake to adjust these debug paths.