Completely deleting a project from Xcode

I have to say that I consider the whole process of developing with Xcode deeply annoying. I recently had a problem where it claimed that I needed to set a development team for signing even though I already had. After spending a lot of time deleting, recreating projects etc etc, I realized that clearly Xcode was keeping some information elsewhere that was causing the problem.

Turns out that it caches some information in:


Each project has a folder here. I deleted any folders that had the same name as my project and that fixed the problem. Ugh. And don’t get me started on bitcode…

Manipulating static libraries with ar

I came across a situation where I had to replace an object file in a static library. First problem encountered was that it was a “fat” library – it had the same code compiled for multiple architectures. The architectures included can be displayed with this command:

lipo -archs fred.a

To get around this, it was necessary to create a new thin library with just the architecture in which I was interested – arm64 in this case. This can be done with lipo again:

lipo fred.a -thin arm64 -output fred64.a

fred64.a will just contain the version for the chosen architecture. In my case, I wanted to replace a large set of object files so I decided to just expand the static library into all of its component object files:

ar x fred64.a

Then I could easily replace the necessary object files. Finally, I recreated the thin library:

ar cr fred64new.a *.o

It’s easy to check what is in the new library using:

ar t fred64new.a

For even more detail, the nm command will display the exposed symbols in the library:

nm fred64new.a

Building the VPX Example and Installing Xcode command line tools

I have been trying to build the VPX Example and the webm part of the build was failing with a messy error message:

2022-05-10 16:43:50.292 xcodebuild[6851:523507] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in
2022-05-10 16:43:50.293 xcodebuild[6851:523507] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in failed because: build exited with error (2)

Turned out to be that the Xcode command line tools had not been installed. The install can be kicked off by typing this at a Terminal command line:

xcode-select --install

However, that didn’t fix it. Based on this page, I then tried:

softwareupdate --list
softwareupdate -i "Command Line Tools for Xcode-13.3"

By running the webm with the –show-build-output I was able to see that the real error was that it was using old libraries. Adding “-stdlib=libc++” to the CXXFLAGS:

CXXFLAGS="-arch ${ARCH2:-${ARCH}} -isysroot ${SDKROOT} ${OPT_FLAGS}
            -miphoneos-version-min=6.0 -stdlib=libc++"

allowed the webm build to complete. Unfortunately, the VPX Example project still didn’t build in Xcode…

Displaying a system’s DMI information

Linux has a very handy function, dmidecode, that can be used to display useful information about the hardware configuration of a system. The more general purpose command hardinfo displays some of the same information but not all.

Basic usage is:

sudo dmidecode

The output can be made more specific using one of the options described here. In my case, I wanted to know what the part number of the DRAM fitted to a system was while the system was running and without literally looking at the part. This command selects the memory information:

sudo dmidecode -t memory

Ignoring the annoying SIG32 signal when debugging SPDK apps in QtCreator

Well I don’t know if I am doing something wrong but, every time I close down an app using SPDK being debugged via QtCreator, SIG32 gets trapped and pauses execution rather than cleaning up and exiting. It’s easy to suppress the pop-up window but I couldn’t work out how to avoid trapping the signal entirely. Fortunately I found this post which has the solution.

Basically, you open up the Options window and select Debugger. Then select the GDB tab. Within that, there’s a window for Additional Startup Commands. Within that window, add the line:

handle SIG32 pass nostop noprint

Then press Apply and Ok. From now on, the app won’t get hung up if this signal is generated on exit.

Forcing a specific Linux kernel at boot time

Another problem I had with the irdma driver build mentioned in the previous post is that it would not build with the default kernel in my Ubuntu 20.04 install (5.11.0). However, I knew it would build using 5.4.0 which was present but not automatically selected. The trick is to get grub to default to the desired version. To do this, first list /boot/grub/grub.cfg and find the appropriate string for the desired version. In my case, this was:

Ubuntu, with Linux 5.4.0-42-generic

Then, edit /etc/default/grub and change the GRUB_DEFAULT line to this:

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-42-generic"

Finally, run:

sudo update-grub

to activate the new default option and then reboot.

Solving a kernel module signing issue

I am currently working on getting an E810 100G ethernet NIC working and had a bit of trouble building the irdma driver due to a signing problem:

At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: ../crypto/bio/bss_file.c:69
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: ../crypto/bio/bss_file.c:76
sign-file: certs/signing_key.pem: No such file or directory

After some research, I came across the solution here, which seemed to work for me. Specifically the solution is (reproduced here just in case I can’t find the original again!):

cd /lib/modules/$(uname -r)/build/certs

sudo tee x509.genkey > /dev/null << 'EOF'
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts
[ req_distinguished_name ]
CN = Modules
[ myexts ]

sudo openssl req -new -nodes -utf8 -sha512 -days 36500 -batch -x509 -config x509.genkey -outform DER -out signing_key.x509 -keyout signing_key.pem

Debugging DPDK and SPDK applications in QtCreator: the root issue

There doesn’t seem to be any easy way to get SPDK and DPDK to work without root permission (ok, there is a way but this technique works for these and other things). Not impossible to deal with when running code but it does present a problem when debugging with QtCreator (or any other IDE that directly calls the debugger). There is a trick that allows gdb to be run with root permission without requiring a password (largely as described here).

sudo visudo

and add this line at the bottom of the file:

<username> ALL=(root) NOPASSWD:/usr/bin/gdb

where <username> is the appropriate user name. Now all that’s needed is to call sudo gdb instead of gdb. This can be done by creating a simple executable script called sudo-gdb containing:

sudo gdb $@

QtCreator then needs to know to use this version of the debugger. Go to Tools -> Options and select Kits. Select the Debugger tab and click on Add. Enter the full path to the new script. Then click on the Kits tab and select the new debugger in the Debugger drop-down and then click on Ok.

Yes, I should probably do it with the permissions trick and I will. One day.

Adding a password protected share to Ubuntu

This is one of those posts that helps me remember how to do something I knew how to do once but would inevitably forget how to do again one millisecond later. In this case it is how to configure a directory that is shared on the network but only to registered users.

First off, create a new group for the users (I will use the group name sharegroup as an example):

sudo addgroup sharegroup

Then add yourself to the group:

sudo usermod -aG sharegroup $USER

Add any other users to the group in the same way.

Now it is time to prepare the directory to be shared. Create (or choose) the directory and share it using the local network share option from the GUI. Alternatively, edit /etc/samba/smb.conf directly by adding something like this at the bottom:

  path = <full path to shared directory>
  writeable = yes
  guest ok = no
  read only = no
  browsable = yes
  create mask = 0770
  directory mask = 0770
  valid users = @sharegroup

and then restart samba:

sudo systemctl restart smbd

Then the directory group ownership must be set to the new group. Set the directory as current and enter:

sudo chgrp -R sharegroup *
sudo chgrp sharegroup .

Be very careful any time using the -R option with sudo as it is easy to completely mess up the OS! Generally it is best to start in the directory that’s being modified. That way, there’s less chance of making unintentional modifications.

Now change the permissions to allow group members to operate on files properly:

sudo chmod -R g+rw *
sudo chmod g+rw .

Then the users must be added to samba – for example:

sudo smbpasswd -a $USER

This will ask for a password to be used to access the share. That’s it!

Using UWB asset tags to dynamically create rt-ispace augmentations

Essentially, an asset tag is a small device that can be used to locate and instantiate, using UWB in this case, an augmentation in an rt-ispace environment completely dynamically. The augmentation follows the position and orientation of the asset tag, making for a very simple way to implement augmented spaces. If engineered properly, it could be an extremely simple piece of hardware that would be essentially UWB hardware along with a MEMS IMU and a battery. Instead of WiFi as in this prototype, pose updates could be sent over the UWB infrastructure to make things really simple. Ideally, these would be extremely cheap and could be placed anywhere in a space as a simple way of adding augmentations. These augmentations can be proxy objects (all aspects of a proxy object augmentation can be modified by remote servers) and can be as simple or complex as desired.

There are some similarities and differences with the ArUco marker system for instantiating augmentations. The ArUco marker can provide an ID but that has to be matched with a previously instantiated object that has the same ID attached. Asset tags don’t require any pre-configuration like that. Another problem with ArUco markers is that they are very affected by occlusion – even a wire running across a marker might make it undetectable. Asset tags are not affected by occlusion and so will function correctly in a much wider range of circumstances. They do require UWB enabled spaces, however. In the end, both styles of augmentation instantiation have their place.

Note that the asset tag doesn’t need to contain the actual asset data (although it could if desired). All it needs to do is to provide a URL of a repository where the asset (either Unity assetbundle or glTF blob) can be found. The asset is then streamed dynamically when it needs to be instantiated. It also provides information about where to find function servers in the case of a proxy object. The rt-ispace user app (in this case an iOS app running on an iPad Pro) doesn’t need to know anything about asset tags – they just inject normal looking (but transient) augmentation updates into the rt-ispace system so that augmentations magically appear. Obviously, this kind of flexibility could easily be abused and, in real life, a proper security strategy would need to be implemented in most cases. For development, though, it’s nice for things just to work!

One application that I like is a shared space where people can bring along their virtual creations in the form of some asset tags and just place them in the rt-ispace space so that any user in the space  could see them.

Another idea is that items in stores could have rt-ispace asset tags attached to them (like security tags today) so that looking at the item with an AR device would perhaps demonstrate some kind of feature. Manufacturers could supply the asset and functions servers, freeing the retail store from having to implement something for every stocked item. 

The video above shows how the augmentation tracks the UWB tag around and that the IMU controls the augmentation’s orientation. For now, the hardware is a complete hack with multiple components but it does prove that the concept is viable. The UWB tag (the white box on the floor under the figure’s right foot) controls the location of the augmentation in the physical space. A Raspberry Pi fitted with an IMU provides orientation information and drives the resulting pose via WiFi to the rt-ispace servers. The augmentation is the usual glTF sample CesiumMan.