Library.a not getting signed properly for notarization

Hi Folks, I have experimented with just the command line process and with App Wrapper, which is what I normally use, and I am having trouble including a library in my app that ends in “.a”

Specifically this is an app that I include an embedded version of python in since newer OSX versions no longer include their ancient python build. I’ve had no trouble adding new plugins for that up until now when I’m trying to add the numpy libs. They include some libraries that end in “.a” which somehow are just not getting taken care of during the process.

If I run file against the process I get this, which is what I would expect to get:

file libnpymath.a

libnpymath.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random librarycurrent ar archive random library] [arm64:current ar archive random librarycurrent ar archive random library]

libnpymath.a (for architecture x86_64): current ar archive random library

libnpymath.a (for architecture arm64): current ar archive random library

I have tried running it through just codesign with the “-o library” turned on, but that doesn’t seem to do anything to it. I tried adding that switch to AppWrqappers advanced codesigning command line and that did seem to run at least, but generated a lot more errors from Apple’s notarization than it did without it, including the same one for these libraries.

Specifically the errors that come back from Apple are that it is not signed, and then that it doesn’t contain a secure timestamp. Which I wouldn’t expect it to if it hadn’t been signed at all…

| 35,320|48_build_1055_.dmg: |The binary is not signed. in …/site-packages/numpy/core/lib/libnpymath.a|
| 35,320|48_build_1055_.dmg: |The signature does not include a secure timestamp. in …/site-packages/numpy/core/lib/libnpymath.a|

and then one more for another similar file. The “…” is not in the output I just removed the 3 lines long worth of extra path information that is not actually helpful.

If anyone has any suggestions on how to get this kind of library to sign and notarie properly I would very much like to know! I’ve experimented with moving them to different places inside the bundle. It does not find them in either /Contents/Resources/Plugins nor in just /Contents/Plugins

So it turns out that the .a files are a step in the creation of .dylib or .so libraries and aren’t actually needed by the package at all. Removing them does not appear to have caused the software any problems at all. I have no idea why the install step moved them into place or left them in place rather than getting rid of them. Perhaps it makes it easier to link other things later without having to rebuild the libraries. But in any case false alarm. Did not initially imagine that the solution would be to just delete the files :wink:

2 Likes