Notarization issue with library (dylib)

The libraries and the executable are packaged and sent to the notarization service, and the response is that the notarization is successful. 

What do you mean "libraries and the executable"? The libraries should be bundled inside the executable. If not there, they should be bundled inside an installer package, or perhaps something even more esoteric.

Checking with codesign, all looks to be good:

Really? What about "test-requirement: code failed to satisfy specified code requirement(s)"?

I strongly recommend against using that "notarized" requirement or the "--check-notarization" flag. I had to double check these because I didn't recognize them. I did find one of those flags in the codesign man page and I saw Eskimo reference the other one. So, they are valid, but that doesn't mean they do what people think they do.

There is only one way to check notarization. You have to download the notarized file and run it. If it works, then the notarization is successful. There is absolutely no other tool, command-line trick, or codesign operation that will suffice - absolutely nothing. You must download the app with Safari, run it, and it must work.

There are quite a few validation stages that a notarized app must pass. I don't know anything about your software, so I can't begin to speculate about where the problem lies with that particular build. Generally speaking, if you correctly build an app in Xcode, archive the app, and the submit the app to the notarization service, then it works perfectly 99.999% of the time. I can't say 100% because I'm sure there is always some oddball case or the notarization service is down.

When people have problems with notarization, here are the top explanations:
1) the notarization service is down
2) the Xcode project is not correctly structured and is hacked up
3) the developer isn't building the project with Xcode and did something wrong
4) the developer isn't building the project with Xcode, is using some crazy 3rd party development tool, and has no idea what can of worms they have opened up upon themselves

My guess is that you are in category 3, or maybe 4. People who report notarization problems are almost always category 4.

Thank you for the response, Etresoft.

In all honesty, I did not see the the third line. I used to use the verification as references on the official Apple webpage for debugging notarization issue., which returns only the first two lines:

Code Block 
codesign -vvv --deep --strict <my_lib.dylib>
<my_lib.dylib>: valid on disk
<my_lib.dylib>: satisfies its Designated Requirement

But then saw the post from eskimo and though to give that at try, as well, and it seemed to return the same thing (which I now see it does not).

The whole build process is fully automated and only this particular build has problems (without any error in the notarization plists returned by the various tools used in the process). The dylibs and exe file is zipped and sent to the notarization tool.

In any case, I will use the verification suggested by eskimo in order to at least get a hint if the notarization may have failed and also do the smoke test as you suggested.
However, it's a bit disappointing to see that automation is not supported for the verification and, more so, that there is no indication regarding this on the official Apple documentation

The dylibs and exe file is zipped and sent to the notarization tool.

What does that mean? You can't just stuff files in a zip file. Notarization is designed for specific structures, such as apps, installer packages, and dmg files. Maybe this is why you keep referencing "<my_lib.dylib>". Maybe you should start by explaining just what you are attempting to do - at very high level. Forget about notarization. What are you distributing here?

also do the smoke test as you suggested.

I didn't say anything about a "smoke test". There is only one way to verify notarization. One of the primary things people do that breaks notarization is inventing new ways to build and use dylibs. It sounds like you fall into that category. What is being broken in this case is not the signature or the scripts, but the process of loading dylibs and executing code. That can't be tested with a script on the build machine.

However, it sounds like you aren't even making it that far. You are attempting to validate a dylib or something? I don't know if you can even notarize a dylib by itself.