vtool -set-build-version error: mkstemp: No such file or directory

I'm trying to overcome a problem by changing the build versions within some third party dylibs. See https://developer.apple.com/forums/thread/726412.

However, I'm getting an error when I run the command:

vtool -set-build-version macos 12.0 12.0 -replace -output "/Volumes/Data/Projects/MyApp/Pharo/Builds/1.0.0/Bundle/intel64/MyApp.app/Contents/MacOS/PluginsFixed/libUnixOSProcessPlugin.dylib" "/Volumes/Data/Projects/MyApp/Pharo/Builds/1.0.0/Bundle/intel64/MyApp.app/Contents/MacOS/Plugins/libUnixOSProcessPlugin.dylib"

The error is:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool error: mkstemp: No such file or directory.

It looks like it is failing when creating a temporary file, so maybe it is a configuration problem?

This is my last hurdle with the whole notarization, codesigning journery, and any help is very much appreciated!

Replies

I want to repeat, just for the record, my comment from Notarisation and the macOS 10.9 SDK that you should only monkey around with vtool as a last resort. A much better solution is to rebuild the library with modern tools.

But you know that already (-:

> maybe it is a configuration problem?

That seems likely. I ran your command from Terminal and it worked

% codesign --remove-signature libWaffle.dylib 
% vtool -set-build-version macos 12.0 12.0 -replace -output libWaffle.dylib libWaffle.dylib

This is macOS 13.2.1 with vtool from Xcode 14.2.

Are you running this in some sort of CI system? The fact that the error mentions mkstemp suggests that it doesn’t have its temporary directory set up properly.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Yes, I have been reading and following your guidelines to the letter...they're most helpful - thanks. However I'm stuck with this workaround!

I'm not using any CI Tools (apart from using Smalltalk scripts to run the Command Line tools directly). (Note, I get this problem when running manually from the command line).

All the tools have worked fine so far (both on terminal and via script), apart from this instance.

My setup is macOS 12.0.1 with Xcode 13.1.

Yes, that's my conclusion as well, except I don't know how to configure the temporary directory for mkstemp/Command Line tools? Would I do this through Xcode, or some other environment variable? I guess if I new the directory it was trying to use, maybe I could just create it? I've checked the various $TMPDIR, and ~/Library/Caches and there are some com.apple.dt... files there, including Xcode.

Or it could be permissions/space issue? This post https://stackoverflow.com/questions/16996125/no-usable-temporary-directory-found suggested running df -h and df -i. This doesn't seem to be an issue for me though.

Thanks,

Stew

> except I don't know how to configure the temporary directory for mkstemp / Command Line tools?

You shouldn’t need to do that. The environment that runs a command-line tool is supposed to provide the appropriate temporary directory too it. That’s certainly the case when you run from Terminal, which is why I asked about that. My best guess is that there’s something wonky with your setup that’s broken that environment. I’ve no idea what that is though )-:

> My setup is macOS 12.0.1 with Xcode 13.1.

I don’t have that specific setup handy but I do have a VM with macoS 12.3.1 and Xcode 13.3.1 installed and it doesn’t reproduce the problem.

So, next step: Is this issue tied to a specific library? Try this:

  1. In Xcode, create a new project from the macOS > Library template, selecting Dynamic from the Type popup.

  2. Add some code to the library.

  3. Build it.

  4. In Terminal, run vtool against that library.

Does that reproduce the problem?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Thanks Quinn,

    I'll give that a go tomorrow after some much need sleep! (Also doing battle with Instruments Allocations starting in root directory but that is another story...).

    Cheers,

    Stew

Add a Comment

Hi Quinn,

Good news, and bad news - after building the dummy dylib and running vtool against it - it worked. Furthermore, when I reran vtool against my libraries, it worked too!

I guess it must have set the temp path somehow? Another mystery!

The bad news is that the library (which is not one that I've "fixed") still doesn't load when codesigned - it works fine without it.

Back to reading your notes - I'll create another post after that...

Thanks,

Stew