I have a file ~/.lldbinit with a single alias:
command alias pi print (int)
But when I run my app from Xcode, the alias does not work. However, if I manually enter the alias, then the alias does work:
(lldb) pi 6
error: 'pi' is not a valid command.
(lldb) command alias pi print (int)
(lldb) pi 6
(int) $3 = 6
(lldb)
This leads me to suspect that my .lldbinit file is not getting read. Or is there a different problem that I am missing? Can anyone help?
I had a similar problem. It turned out, that I had a syntax error in my .lldbinit file which leads to lldb silently ignoring the file. You can try manually loading the file with
command source ~/.lldbinit
which will show syntax errors.
Make the file executable:
chmod +x ~/.lldbinit
I created a .llbdbinit file just like you and reproduced your problem in my copy of Xcode 4.1. I can't get aliases to work either.
Since ~/.lldbinit is documented by Apple as supposedly being read when started up, I suspect that lldbinit file reading is currently busted in shipping versions of Xcode 4. Not sure what pre-release versions are doing, but I'd recommend filing a bug at bugreporter.apple.com.
p.s.
One thing I noticed on one blog (here; look in the "differences between OSX & iOS" section) is that lldb only works for MacOS and NOT for iOS, at least as of a bunch of months ago.
Note that ~/.lldbinit does work in Xcode 4.3.2, iOS.
if you created the lldbinit file with some editor then it might have screwed it.
try openning the lldbinit file with vi and check if it just plain text
I had the same problem when trying to get this plugin to work.
command script import ~/Documents/002.ME/001.BITBUCKET_REPO/xcode_plugin_lldb_quicklook/GITHUB-LLDB-QuickLook/LLDB-QuickLook/lldb_quick_look.py
command alias ql quicklook
The path to the py file was wrong so kept reporting the error:
error: 'ql' is not a valid command.
Once I fixed it. I had to restart Xcode 5 and it worked.
I didn't have to restart Mac.
I didn't have to make the file executable.
Related
I used swift package init --type executable.
I have already tried setting xcode command line tools on path.
Following error occurs:
dyld: Library not loaded: #rpath/llbuild.framework/Versions/A/llbuild
Referenced from:
/Library/Developer/CommandLineTools/usr/bin/swift-package Reason:
image not found
I had to go into the preference for xcode and under Locations, set Command Line Tools to the correct version. It was blank when I first opened it.
I have faced the similar issue.
Basically the framework or library is not properly linked in the project.
If you are doing drag and drop of framework in xcode project then you will have to link it in embed frameworks as well.
(Basically you will have to drag and drop the framework in embed frameworks section)
See the below image.
There was this bad config in bash_profile /Library/Developer/CommandLineTools/usr/bin for path. Just removed it. Fixed the problem. which swift should result in /usr/bin/swift.
I had the same problem. I wanted to do some simple command line coding but didn't want to install the full Xcode bloat. I installed only the Command Line Tools on Mojave 10.14.6.
I could call swiftc to compile a file from the command line which actually did everything I needed it to. (I can't remember where I found a reference to being able to do this but basically you just call 'swiftc filename.swift' and you're good.)
But it irritated me that coding the "proper" way (i.e. the way most of the tutorials on the Internet want you to) failed. The "swift package init..." stuff kept barfing with the error posted in the question above here. So I got obsessed with fixing it.
So the error says that swift-package can't find a tool called llbuild.
I found that the llbuild executable did actually exist on my machine at:
/Library/Developer/CommandLineTools/usr/lib/swift/pm/llbuild/llbuild.framework/
The error, then, is because swift-package isn't looking for the tool in that directory.
(As a side note, earlier in my quest to fix this error, I tried adding some paths to my .bash_profile. None of those attempts worked. I can't recall now if I ever tried adding that full path and I'm too lazy to try now.)
I did some more digging. Someone somewhere on the Internet pointed out that the #rpath (referenced in the error message) variable set in apps can be discovered with otools. I used otools on swift-package and found its #rpath seemed to be pointing to /usr/lib. I noticed there was a .../usr/lib/... structure in the location of llbuild mentioned above. I imagined that swift-package was looking in /usr/lib instead of the directory where the file actually was. So I linked the directory where llbuild really is into the /usr/lib directory and voila! It worked.
Most people who need to do this will likely know how to do a symlink of a directory, but just to be thorough, this is what solved the problem for me all as root or use sudo if you want:
cd /usr/lib
ln -s /Library/Developer/CommandLineTools/usr/lib/swift/pm/llbuild/llbuild.framework/ .
Note that trailing period there. That's necessary.
As a side note, I had System Integrity Protection turned on, which forbids making symlinks in /usr/lib, so I had to reboot and turn SIP off from the recovery login(reboot and hold down Command-R) before I could do this.
Also, note that none of this necessarily cured the underlying problem I had of being able to actually build swift packages from the command line--I could now use "swift package init" but I couldn't use "swift run" or do anything else useful. I posted this only to give others some clues when they go digging since I looked a lot of places and didn't have much luck.
After updating to Xcode 6 beta 3 the compiler keeps crashing with the following error:
/[Long-path-goes-here]/all-product-headers.yaml:4:13: error: Could not find closing ]!
'roots': [
^
fatal error: invalid virtual filesystem overlay file '/[Long-path-goes-here]/all-product-headers.yaml'
1 error generated.
Solved by doing the following:
Find the /[Long-path-goes-here]/all-product-headers.yaml (Go to Folder... in Finder)
Replace the contents with the code below.
Save and lock the file. (Get info for file, check locked.)
{
'version': 0,
'case-sensitive': 'false',
'roots': []
}
After this Xcode will complain about not being able to write the file with this error this is expected and doesn't seem to affect the build. Edit: For most people. If it prevents you from running try disabling Defines Module in Build Settings of your Target:
Unable to write to file /Users/user/Library/Developer/Xcode/DerivedData/.. (You don’t have permission to save the file “all-product-headers.yaml” in the folder “Pods.build”.)
Hat off to the discussion on Apple Developer forums. Also, this is the relevant issue in CocoaPods issue tracker.
Try setting "Defines Module = YES" in your app target. Works for my project.
Clean (command-shift-K), and clean-build-folder (command-alt-shift-K) and build again worked for me.
I had this problem because I deleted some old archives and files from my mac to make more space. However running pod install for this project solved it.
Perhaps your path to .yaml file contains ' character. It makes the parser confused. Using TextWrangler, you can see your path has different colors (red & black).
That's my case, and moving project to another path (which doesn't contain ') solved my problem.
I solved it by delete the current project's DerivedData folder by (Xcode 8):
Xcode > Preferences > Locations tab > Click on the right arrow under
DerivedData > inside the folder DerivedData delete the project folder.
Better to do hard clean also by Shift+Cmd+Alt+K.
And build.
Can fix with one shell command:
echo "{\n\t'version': 0,\n\t'case-sensitive': 'false',\n\t'roots': []\n}" > /[Long-path-goes-here]/all-product-headers.yaml
Where the path is copied out of the Xcode error.
See Daniel Schlaug's answer for background info
I tried all the answers above/below. None worked.
However, Restarting Xcode did it.
Try that before going into the madness of trying to fix the actual situation of the missing file. All the rest is madness. Heck, If that doesn't fix it. I would even try restarting every time you do one of the strategies listed here. Maybe one of those fix it but Xcode gets stuck until you restart it.
Nothing else to do, Xcode is just too buggy at times.
I get this error too frequently, so I've made a simple bash script based on Daniel Schlaug's answer. I've never needed to lock the file. Just copy the file referenced in your error log and use it as the only parameter. Don't forget to chmod +ux before running.
#!/bin/bash
if [ "$#" -eq "0" ]
then
echo "No arguments supplied"
exit
fi
rm -rf $1
echo "
{
'version': 0,
'case-sensitive': 'false',
'roots': []
}" > $1
I know other similar questions have been posted, but none of those solutions worked for me. Updated to Xcode 4.5.1 from 4.3.3 today. Got this error:
Build/Products/Debug-iphoneos/MobileApp.app/MobileApp malformed object (unknown load command 19)
/Users/garyt/Library/Developer/Xcode/DerivedData/MobileApp-cgojnkplmjncbaaigyvelwclibwr/Build/Products/Debug-iphoneos/MobileApp.app/: object file format unrecognized, invalid, or unsuitable
Command /bin/sh failed with exit code 1
So followed instructions here. Downloaded latest command line tools, tried the sudo codesign_allocate fix suggested, and checked to make sure my name and values were matching on both target and product, but still having the "object file format invalid or unsuitable error pop up". New to cocoa/iOS dev and this wasn't a headache I was expecting. Any help would be appreciated. I guess I should also note everything worked fine when I was running Xcode 4.3.3, which is what I updated from.
Best way is to just delete the XCode and install a new one from Appstore.
https://itunes.apple.com/in/app/xcode/id497799835?mt=12
I am running iOS 4 on a jailbroken iPhone 3GS. Before I upgraded to iOS 4, I had installed Python on the iPhone and had found the following snippet of Python code to copy a variable (key in this case) to the pasteboard. I then was able to open another application and paste the value into a text field.
out = os.popen('\usr\bin\pbcopy', 'w')
out.write(key)
out.close()
Since upgrading to iOS 4, this code no longer works. I receive the following error message:
sh: pbcopy: command not found
I looked in the \usr\bin\ directory, and there is no pbcopy (or pbpaste) command listed.
Does anyone know of another way that I can use Python to copy the value of a variable into the pasteboard?
I'd greatly appreciate any help that anyone can provide.
You need to install the package "Erica Utilities" available in the modmyi repository (enabled by default) in Cydia.
Just upgraded to Snow Leopard, installed Xcode 3.2, then installed iPhone SDK 3 for SL.
In a project, I now get the following error on build:
ld: library not found for -lcrt1.10.6.o
I've searched around the net, but nothing helpful can be found.
Edit Project Settings -> In the build tab -> For Mac OS X Deployment Target, change it to 10.5 for XCode 3 (not 10.6 even if on 10.6) and see if that helps.
For XCode 4, you'll need to set it to 10.6
P.S. Make sure you set that for all targets, not just release or debug. (if you didn't, one would fail, the other wouldn't)
Add the following to ~/.profile (for Mac OS X 10.5):
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
I was able to fix this problem by adding the following to my Makefile:
CFLAGS="$(OTHER_CFLAGS) -mmacosx-version-min=10.5"
LDFLAGS="$(OTHER_LDFLAGS) -mmacosx-version-min=10.5"
Ostensibly, this is only required when building outside of Xcode. This problem frustrated me long enough that I figured it would be useful to share my experience here.
It looks like you're picking up libraries from /usr/lib, which is wholly inappropriate for the iPhone SDK. I would assume you've changed your build settings to add /usr/lib to the library search paths. This should be completely unnecessary in the first place, as /usr/lib is in the compiler's standard search paths, but if you need to have a modified search path like this, make sure to use $(SDKROOT)/usr/lib instead.
Setting deployment target to compiler defaults solved the problem. Don't change anything else.
The compiler normally uses crt1.o combined with crt[i/n].o and crt[begin/end].o to support the constructors and destructors (functions called before and after main and exit).
This error could be caused by this missing library file for the specific deployment target.
First, do some investigation, like:
List all your deployment targets:
ls -la /Developer/SDKs
Find which crt1 libraries do you have for which environment
find /Developer/SDKs -name crt1\*
You could see something like:
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.5.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.o
As you can see in above example, crt1.10.6.o is missing for MacOSX10.5.
Solution 1
You can solve that by creating the link to the missing file pointed to the other environment, or you could change your deployment target.
E.g.
ln -s /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o /Developer/SDKs/MacOSX10.5.sdk/usr/lib/
Other reason why it's missing, is that you could have different gcc installed in your system. E.g.:
which gcc
xcrun -find gcc
brew list | grep gcc; brew list gcc47
Solution 2
So when you're compiling using make, you can actually specify the right compiler by CC variable. E.g.
CC=/path/to/gcc-3.4 make
Solution 3
What you can also try is specifying the right target deployment environment variable for gcc, e.g.:
export MACOSX_DEPLOYMENT_TARGET=10.5
If this works, then you can add this library path to your shell profile (~/.profile).
E.g.
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
Or by temporary exporting them.
How to test
Create the example conftest.c file with the following code:
#ifdef __GNUC__
yes;
#endif
And try to compile it via:
gcc conftest.c
cc conftest.c
cc conftest.cc conftest.c
Wasted few hours on this one...
Interestingly, for me the problem was only for Simulator-Debug.
It wasnt complaining for Simulator-Release or Device Debug/Release!
anyway, Changing Deployment Target to 10.5 solved this for me!!
This problem solved by setting Mac OS X Deployment Target to 10.5 and after this set back to Compiler Default :)
I had this problem when I was using Xcode 4 on one machine and Xcode 3.2.6 on another. The two versions are supposed to be able to swap .xcodeproj files between them but I found that in the project.pbxproj file (inside the .xcodeproj directory), there were still a couple of places that read:
MACOSX_DEPLOYMENT_TARGET = 10.6;
I quit Xcode and went and changed the three occurrences to:
MACOSX_DEPLOYMENT_TARGET = 10.5;
After reopening the project, I could build again. Whew!
I had the same error message, none of the above solutions worked for me. I resolved it by deleting the *.pbxuser and *.mode1v3 files inside the xcodeproj file.
Control/click the xcode *.xcodeproj file
Select the "show package contents" option from the menu
A window will open with the contents
Delete the pbxuser/mode1v3 files that start with your user name
Rebuild the project
I had the same issue in a Fortran Makefile.
Added the following option after the compiler (For OSX 10.5):
-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
e.g.,
g77 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
Now the compiler will find the library you want !
Add the following to ~/.profile (for Mac OS X 10.5):
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include
export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib
Given Kirandan's limited scenario (Snow Leopard, Xcode 3.2.1, iphone, library path error), Stefan's answer (above) worked for me, except my exception was with 10.5 (-lcrt1.10.5.o).
Elsewhere, I'd seen an answer by Gabor Cselle (author of reMail), and he fixed this specific issue by using a symbolic link (someone referenced this page, by the way), but he noted this was not the best way.