When developing iOS apps with XCode, there is a build setting called Install Directory. Does XCode ignore this? I've changed it to /Applications and the app still gets installed in the sandbox. I'm using a jailbroken phone and would like my app to get installed in /Applications for system read privileges. The only other way, it seems, is to use SSH to drop the bundle in /Applications. Doing that forces me to build+archive, thus I can't use the debugger for console output.
Is there a solution to this problem? (I am a paid dev with a proper certificate, no hacks)
This setting is mainly for OSX apps, but I think it may also place the main executable inside that directory inside of the App bundle. So if you had Test.app, the executable binary file would be in Test.app/Applications/test. At least it did that for me a while back when I was messing around with different settings. It may have changed.
You can use the xcode 'Behaviors' settings to specify a script to run when a build succeeds, or you can set 'Pre-build' and 'Post-build' actions (can also run a custom script) for each scheme in your project. You could automate the process of SSH'ing and moving the bundle with a post-build script.
Edit:
I just tested changing this setting and building debug/release/test/etc versions of my project, and nothing changed about the bundle or archive that was build. Seems this setting has no effect on iOS apps.
Actually, after more testing it does change the directory inside a release archive. This is how the archive looks after changing that setting to ApplicationsTest:
[ 12:12 Jonathan#MacBookPro ~/Library/Developer/Xcode/Archives/2011-09-28 ]$ cd Universal\ 9-28-11\ 12.11\ PM.xcarchive/Products/
[ 12:12 Jonathan#MacBookPro ~/Library/Developer/Xcode/Archives/2011-09-28/Universal 9-28-11 12.11 PM.xcarchive/Products ]$ ll
total 0
drwxr-xr-x 3 Jonathan staff 102B Sep 28 12:11 ApplicationsTest
[ 12:12 Jonathan#MacBookPro ~/Library/Developer/Xcode/Archives/2011-09-28/Universal 9-28-11 12.11 PM.xcarchive/Products ]$ ll ApplicationsTest/
total 0
drwxr-xr-x 187 Jonathan staff 6.2K Sep 28 12:11 Universal.app
And changing it to SomethingElse:
[ 12:15 Jonathan#MacBookPro ~/Library/Developer/Xcode/Archives/2011-09-28/Universal 9-28-11 12.15 PM.xcarchive/Products ]$ pwd
/Users/Jonathan/Library/Developer/Xcode/Archives/2011-09-28/Universal 9-28-11 12.15 PM.xcarchive/Products
[ 12:15 Jonathan#MacBookPro ~/Library/Developer/Xcode/Archives/2011-09-28/Universal 9-28-11 12.15 PM.xcarchive/Products ]$ ll
total 0
drwxr-xr-x 3 Jonathan staff 102B Sep 28 12:14 SomethingElse
[ 12:15 Jonathan#MacBookPro ~/Library/Developer/Xcode/Archives/2011-09-28/Universal 9-28-11 12.15 PM.xcarchive/Products ]$ ll SomethingElse/
total 0
drwxr-xr-x 187 Jonathan staff 6.2K Sep 28 12:15 Universal.app
Related
Note: There are several similar questions, which I have seen and read. None of them are the precise problem I'm having, and none of their answers work for me.
I have installed several Python versions (Python 2.7, 3.8, 3.9, and 3.10) on my macOS Ventura system using Pyenv. The installed directories include a python-config file in /bin and an /include directory with many header files, so I do not need to install python-devel or similar:
$ ls -al /Users/williamsn/.pyenv/versions/3.10.9/bin/*-config
lrwxr-xr-x 1 williamsn staff 17 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python-config -> python3.10-config
lrwxr-xr-x 1 williamsn staff 17 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python3-config -> python3.10-config
-rwxr-xr-x 1 williamsn staff 2073 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python3.10-config
$ ls -al /Users/williamsn/.pyenv/versions/3.10.9/include/python3.10/
total 1192
drwxr-xr-x 86 williamsn staff 2752 Dec 19 17:24 .
drwxr-xr-x 3 williamsn staff 96 Dec 19 17:24 ..
-rw-r--r-- 1 williamsn staff 3224 Dec 19 17:24 Python.h
...
-rw-r--r-- 1 williamsn staff 3026 Dec 19 17:24 import.h
...
-rw-r--r-- 1 williamsn staff 48878 Dec 19 17:24 pyconfig.h
...
-rw-r--r-- 1 williamsn staff 2863 Dec 19 17:24 weakrefobject.h
As a best practice, I work exclusively in virtualenvs to keep the base Python installation clean and pristine. I create my virtualenvs using the venv module built in to Python 3:
$ python3.10 -m venv my_venv
After doing so, there are two problems:
The my_venv/include directory is empty (does not contain the python3.10 directory or any of the header files from the parent Python and does not symlink to the parent Python)
There is no python-config / python3-config / python3.10-config in my_venv/bin.
So, for things requiring the Python headers:
If it tries to find the headers using python-config (which many projects do), it will fail.
If it tries to find the headers using the Python prefix and adding /include to it (which many projects do, notably Boost), it will fail.
If it tries to find the headers by importing sysconfig and calling sysconfig.get_paths(), it will succeed, albeit with paths outside the virtualenv.
Now, on a case-by-case basis, I can work around this, and already have. I can manually copy over python_config and then either export CPATH to add /Users/williamsn/.pyenv/versions/3.10.9/include/python3.10 or modify the virtualenv to symlink to /Users/williamsn/.pyenv/versions/3.10.9/include. These work, but they don't seem right to me. I can't make a global workaround anywhere (such as exporting CPATH in my Bash profile), because I'm working with multiple Python versions, and I'd end up with the wrong headers half the time. It seems to me like a virtualenv that has an empty include directory and is missing python-config when its parent has a full include directory and contains python-config is a broken virtualenv.
Is there an option I'm missing to include these pieces? Is this a bug I need to file against Python/venv?
Running RHEL 7.7 on the head node of a compute cluster. When I open VS Code 1.57.1 it hangs on the intro screen. Running with $ code --verbose, it shows the error: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.20 not found. I have to kill -9 the hanging code process. Google tells me that the new version of VS Code uses Electron that requires the updated GLIBCXX version.
The installed version in /usr/lib64/libstdc++ is definitely out of date, and I can't update it. But I do have a newer version of GCC that is loaded by the $ module load gcc8/8.4.0 command that loads GCC from /cm/shared/apps/gcc8/8.4.0/. The library /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 has the requested version of GLIBCXX.
I have tried loading gcc8 before running code, but that doesn't change the error.
Is there a way to make VS Code use the alternative location for libstdc++.so.6? Is there an alternative to updating the system-wide libstdc++.so.6 library?
This is the full error message from --verbose:
Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1846)
This shows the out-of-date default version of libstdc++:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.18
GLIBCXX_3.4.19 <----Nope, this version is too old!
GLIBCXX_DEBUG_MESSAGE_LENGTH
This shows the other libstdc++ library has the required version:
$ strings /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.19
GLIBCXX_3.4.20 <--- Here it is!
GLIBCXX_3.4.21
...
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH
Per scroveez's suggestion, the /usr/lib64/libstdc++.so.6 was indeed a symlink to the older version. To fix it I copied the 'new' version 25 library into /usr/lib64/ and changed the symlink to point to the newer version.
$ ll /usr/lib/libstdc++.so.*
lrwxrwxrwx 1 root root 18 Apr 30 2019 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 739520 Nov 13 2014 /usr/lib/libstdc++.so.5.0.7
lrwxrwxrwx 1 root root 19 Jul 6 08:56 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.25
-rwxr-xr-x 1 root root 934644 Mar 25 2020 /usr/lib/libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 1570176 Jul 6 08:55 /usr/lib/libstdc++.so.6.0.25
$
I was having issues with a workspace so I tried disabling all of extensions for it. Then the only option was to enable all extensions for the workspace. I have extensions globally configured to be off or on, but I'm not sure how to get a workspace to reset to the global extensions now?
I know I can open a new window up and start manually enable/disabling the extensions in my workspace to match the new fresh window. The problem is that it would then have its own workspace extensions defined, so if I toggled one at a global level it would still have an override.
I also tried deleting the .vscode folder in the workspace, but that doesn't seem to change the extensions for the workspace.
It's not a great method but I guess this works with a lot of manual leg work.
Enable all extensions for workspace
Open a new VSCode window
Goto extensions and filter by #disabled
You can also do #enabled and disable all extensions in the first step if you have more disabled than enabled.
Now you have a list you can target. Just click Disable instead of Disable for Workspace.
I believe this should get your workspace back to normal. There has to be an easier way though. You may also have to toggle enabled extensions to disabled and then back to enabled in case it has a workspace override for them -- I didn't check how it would behave if a new window disabled the extension whether or not it would keep staying on.
I've found a way to reset all settings for a given workspace.
First, navigate to ~/.config/Code/User/workspaceStorage. Inside there, you'll find a lot of folders with seemingly random names. Each folder seems to represent one workspace.
# cd ~/.config/Code/User/workspaceStorage
# ls -la
total 156
drwxr-xr-x 39 micael micael 4096 Feb 18 15:00 .
drwxr-xr-x 6 micael micael 4096 Nov 15 13:05 ..
drwxr-xr-x 2 micael micael 4096 Jan 18 16:09 0cf549e23d37c32c70a7e30998ade1fe
drwxr-xr-x 3 micael micael 4096 Dec 29 17:42 1b637cb30f6c3acc9273df20c84be7aa
drwxr-xr-x 2 micael micael 4096 Jan 17 22:09 2010f3fb6dbb2574f12a5ba614b3b136
drwxr-xr-x 2 micael micael 4096 Feb 18 15:01 a09a9ab934662794ac48730fc950a654
...
Inside each folder, there's a workspace.json file that contains the path of the folder your workspace was created from.
We can use grep to quickly search all those folders for a matching string:
grep -r 'myfolder' ., where myfolder should be the name of the folder your workspace is using.
In this example, my workspace was created from a folder called python-playground:
# grep -r 'python-playground' .
./a09a9ab934662794ac48730fc950a654/workspace.json: "folder": "file:///home/micael/projects/python-playground"
grep: ./a09a9ab934662794ac48730fc950a654/state.vscdb: binary file matches
grep: ./a09a9ab934662794ac48730fc950a654/state.vscdb.backup: binary file matches
In my case, the folder I'm looking for is ./a09a9ab934662794ac48730fc950a654.
You'll likely get a few results, all inside the same folder. Let's first take a look inside the folder:
# ls -la a09a9ab934662794ac48730fc950a654
total 64
drwxr-xr-x 2 micael micael 4096 Feb 18 15:01 .
drwxr-xr-x 39 micael micael 4096 Feb 18 15:00 ..
-rw-r--r-- 1 micael micael 28672 Feb 18 15:01 state.vscdb
-rw-r--r-- 1 micael micael 24576 Feb 18 15:01 state.vscdb.backup
-rw-r--r-- 1 micael micael 64 Feb 18 15:00 workspace.json
# cat a09a9ab934662794ac48730fc950a654/workspace.json
{
"folder": "file:///home/micael/projects/python-playground"
}%
Now, we can either remove this folder or move it elsewhere. Make sure to close VSCode before doing so.
# rm -rf a09a9ab934662794ac48730fc950a654
I'm adding binaries to a release in github by dragging and dropping them into the binaries upload section when creating a new release. The binaries have the following permissions on my local (OSX):
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file1
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file2
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file3
-rwxr-xr-x 1 user group 100 Mar 22 00:00 file4
However when I download the binary from Releases the file mode has changed:
-rw-r--r--# 1 user group 100 Mar 22 09:00 file1
Has this been documented anywhere? Is there a way to preserve file permissions when uploading binaries to github?
Is there a way to preserve file permissions when uploading binaries to github?
I don't believe so. People that download the file will need to chmod +x to get the execute permission back. A file's permission is not stored within the file itself, rather it is an attribute of the file on the file system.
If you really need to preserve complex permissions for files, I would suggest storing the files in a container that preserve permissions. Like a DMG for macOS, and uploading the DMG instead.
I've got a chrome os app crashing regularly and causing all other chrome processes to crash as well.
I'm seeing crash reports in chrome://crashes, but no way to see the details of the report. I also can't find any minidump files to analyse.
What is the way to get crash report internals in chrome os?
Try the solution in this SO post.
root#localhost:-$ mkdir /tmp/misc && chmod 777 /tmp/misc
root#localhost:-$ cd /tmp
root#localhost:-$ watch -n 1 'find . -mmin -1 -exec cp {} /tmp/misc/ \;'
Then, as a regular user (not root):
google-chrome --enable-logging --v=1
Once you see files created by the watch command, run:
root#localhost:-$ ls -l
-rw------- 1 root root 230432 Apr 16 09:06 chromium-renderer-minidump-2113a256de381bce.dmp
-rw------- 1 root root 230264 Apr 16 09:12 chromium-renderer-minidump-95889ebac3d8ac81.dmp
-rw------- 1 root root 231264 Apr 16 09:13 chromium-renderer-minidump-da0752adcba4e7ca.dmp
-rw------- 1 root root 236246 Apr 16 09:12 chromium-upload-56dc27ccc3570a10
-rw------- 1 root root 237247 Apr 16 09:13 chromium-upload-5cebb028232dd944
Now you can use breakpad to work on the *.dmp files.
You need to be in dev mode in order to access the crash reports. There's no way otherwise to access where the crashes are saved (system crashes under /var/spool/crash and browser/user crashes under /home/chronos/*/crash/).
However, if you're using official Chrome OS builds, we don't currently publish the symbols for the binaries, so it'll probably be a bit difficult to debug using those minidumps.