How do I use a dynamically load library in a command line utility? [duplicate] - objective-c

This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
using frameworks in a command line tool
Hey,
I've written a command line 'foundation tool' that uses the RegexKit.framework extensively. Everything works when run in Xcode but if I compile the release build and try to run it in Terminal I get the following error:
dyld: Library not loaded: #executable_path/../Frameworks/RegexKit.framework/Versions/A/RegexKit
Closer inspection reveals that the RegexKit.framework bundle is sat in the same directory as my executable file... I've done some research and I'm thinking that as command line tools don't use application bundles there's no where for Xcode to copy the framework to. So I'm guessing that I need to compile the framework as a static library and include it in my code... am I right? If so, how do I go about doing this? Is there anything I can do in Terminal to point to the framework externally?
Any help would be very greatly received, I've been banging my head against this for a few days now!
Thanks in advance,
Tom

So... What I did in the end was to recompile the framework with a different Installation Directory (in the Deployment section, under the Build tab in the Target's Info) - I set it to just #executable_path.
I then compiled the framework and replaced the one in my Utilitie's project, I also changed the Copy Files build phase to copy the framework to "Executables" rather than Frameworks.
The good news is that this fixes my original problem - but obviously the framework has to be in the same directory as the executable.
So this got me unstuck but I'd still love to know how to compile RegexKit.framework statically!

You shouldn't be installing the framework in the Executable folder of your bundle. It should be in the Frameworks folder. You need a Copy Files phase in your project that copies the framework and you need to set the Destination to "Frameworks". "Copy only when installing" should be unchecked.
When testing this, you should make sure you perform a clean build. I typically delete the build folder rather than using Xcode's Clean menu option since it's quicker and more comprehensive.
Also: you cannot statically link to a framework. If you want to statically link to something, it needs to be a static library so in this case, you'd need to hack about with RegexKit. Bear in mind that static libraries cannot contain resources, whereas Frameworks, being bundles, can.

Related

How to use ZeroBrane Studio IDE debugger when lua is compiled as c++

I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.

Google Protocol Buffers on iOS/Objective-C

I need help to configure/use protobuf in Objective-C for a iOS app.
I've tried all but I keep getting errors on xcode. Did anyone manage to make protobuf work well in Objective-C/iOS?
I have used it to some extent on iOS, and with metasyntactic's extension, it works really well. I even managed to get the code generation as a custom build step in Xcode. We switched to Thrift for our project (for other reasons), so my apologies if some details below are wrong, but in general this is how to do it.
In Xcode 4.2, open the target properties, go to the "Build Rules" tab and create a new build rule for "*.proto" files
In "Using:", choose "custom script" and use a script like this:
protoc --plugin=/usr/local/bin/protoc-gen-objc $INPUT_FILE_PATH --objc_out=$DERIVED_FILES_DIR
In Output files, add the generated files (there should be two files, $(INPUT_FILE_BASE).pb.m and $(INPUT_FILE_BASE).pb.h.
Add the .proto files to your project.

How to embed app with log4cocoa?

I'm having some trouble to embed my application with the log4cocoa framework.I've embed frameworks in my application before with no trouble, but I cannot fix this one.
First of all, this is my system out:
dyld: Library not loaded: #loader_path/Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa
Referenced from: /Users/leandro/Documents/Projects/MLoggerApplication/build/Debug/MLoggerApplication.app/Contents/MacOS/MLoggerApplication
Reason: image not found
Well, I think done all necessary steps to get a framework working fine including the copy files phase and changed the installation directory over the build options to #executable_path/../Frameworks .
I hope problem clear enough to receive your help.
Thanks in advance.
Looks like your framework isn't being copied into your target. If a framework isn't part of the system (ie, you have to distribute it with your app), you need to not only link your executable against the framework but to copy it into your app's ./Frameworks folder.
To do this, add a Copy Files build phase, select "Frameworks" as the build phase's destination, then drag the framework (from your Frameworks folder in your Xcode project) under that Copy Files build phase you just created. If you already have a Copy Files build phase for Frameworks, then just use it instead of creating a new one.
Firstly, i mean, Joshua Nozzi is completely right about how is to embed an app with a framework!
But log4cocoa as a little different and could only realize that because it is an opensource code able for download at http://sourceforge.net/projects/log4cocoa/.
The framework could be used with this configuration by adding a "Copy Files build phase, but instead "Frameworks", select "Products Directory" as the build phase's destination, then drag the framework to that "Copy Files build phase.
The difference among this, and the other frameworks relies in this build variable: installation directory.It has as default value: "/Frameworks .
This variable can be accessed by right clicking on the log4cocoa(first item in the targets list), then select "Get Info" and finally "build".
To use it as "normal" framework rebuild it after you have edited the "installation directory" value to "#executable_path/../Frameworks" or if you are going to embed a framework with it, you would prefer "#loader_path/../Frameworks"

Using a framework in a PreferencePane

i am currently trying to implement a "third party framework" (FeedbackReporter.Framework) into my preferencepane.
Unfortunately I am getting the following error all the time when trying to launch my preference pane:
16.05.10 23:13:30 System Preferences[32645] dlopen_preflight
failed with
dlopen_preflight(/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane):
Library not loaded:
#executable_path/../Frameworks/FeedbackReporter.framework/Versions/A/FeedbackReporter
Referenced from:
/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane
Reason: image not found for
/Users/me/Library/PreferencePanes/myPane.prefPane
As far as I read so far, this problem is probably caused because my prefPane is no actual app, but a "plugin" of "System Settings.app" and thus #executable_path resolves to a path within the bundle of this app, instead of the bundle of my prefpane.
But I don't really picked up howto fix this problem. I guess it must be fairly easy since it should be a usual case that people use non-apple-frameworks in PreferencePanes.
Thanks for your hints!
--
Short Update:
As far as I understood tons of docs I read so far, there might be a setting which has to be done in the third-party framework. Obviously the "install path" has to be set to "loader_path" instead to "executable_path" in order to work in a preferencepane.
But since I am using a precompiled framework (FeedbackReporter.framework) this is probably a setting which the author has to change?! and even if i could compile the framework myself, i had no idea where to change this install_path in Xcode.
If you cannot wait for the next release just download the source, change it in
FeedbackReporter.xcodeproj/project.pbxproj
and then open and compile the framework yourself.
Actually, you can change it yourself without recompiling the third party framework. You can use install_name_tool to change where a MachO binary will look for shared object libraries. First use otool -L <binary file for your plugin> to get the paths of where it expects its libraries to be, then use install_name_tool -change ... to change the paths in that file. Repeat for any bundled frameworks.

MSBuild overwriting dependencies

Ok, so I've got a somewhat complicated problem with my build environment that I'm trying to deal with.
I have a solution file that contains multiple C# projects which is built by a NAnt script calling MSBuild - passing MSBuild the name of the solution file and a path to copy the binaries to. This is because I want my automated build environment (CruiseControl.Net) to create a folder named after the revision of each build - this way I can easily go back to previous binaries for any reason.
So idealy I have a folder layout like this
c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.
The problem that's arisen is I recently added the latest version of the Unity IoC container to my project, checking it directly out of MS's online SVN repository. What's happening is I have a Silverlight 3 project that references the Silverlight version of Unity but I also have other projects (namely my Unit testing project) that reference the standard (non-Silverlight) version of Unity.
So what happens is since MSBuild is dumping everything into one single folder the Silverlight version of the Unity assembly is overwriting the non-Silverlight version because they have the exact same assembly file name.
Then when CruistControl runs my unit tests they fail because they don't have the proper dependencies available anymore (they try to load the Silverlight specific Unity assembly which obviously doesn't work).
So what I want to do is:
keep my desired output directory
structure (folder\revision)
I don't want to have to manually edit
every single proj file I have as this
is error prone when adding new
projects to the solution
Idealy I would like MSBuild to put everything into a folder structure similar to this:
nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc
I can't modify the Unity project to give it a different file name because it comes from another SVN repository I cannot commit changes to. I found a similar question posted here and the suggested solution was to use a "master" MSBuild file that used a custom task to extract all the project file names out of the solution then loop over each one building them. I tried that but it doesn't build them in the order of their dependencies, so it fails for my project.
Help?
Firstly I would always have the build server delete the old working copy and check out a fresh copy to avoid any problems with stale artifacts from the previous build.
Next I would have nant or msbuild build the solutions as before with the artifacts from each build going to their local working output folders.
After that I'd move the artifacts from their working paths to their output paths, this shouldn't require digging through the project files since you can just tell msbuild/nant to copy working\project1\bin\release\**\*.* to artifacts\project1\.
The script that does this should ideally be stored along with the source with the main file, e.g. build.nant or build.proj in top level of the trunk.
For third party libraries I would simple include the DLLs directory in your repository. Nothing worse than writing some code and having a third party dependency break your build because of changes on their end.
Simply document the versions of the libraries you are using, and if you must update them, you'll have a better sense of what breaks the build before you even check it in.
Also, doesn't CC.Net automatically handle the providing of releases based on revision? I'm using TeamCity and it keeps a copy of the artifacts of every build.
I highly recommend reading JP Boodhoo's Automating Builds with NAnt blog series. That's been my starting point and have made lots of changes for my own taste. I also highly recommend checking out the builds of many open sources projects for examples. I've learned a lot from the builds of the Castle/Nhibernate/Rhino-Tools stack.