Same issue for me. After weeks, no solution and no feedback from Apple?

I am still unable to upgrade beyond the original Beta software that came with the DTK - which has lots of odd behavior. Any update on how to update these?

Any update on this? All my native C applications compile for Apple Silicon. However, many scientists leverage my tools using R and their pipelines depend on Fortran for specific functions. Good support for R and Fortran is really important for many scientists.

I get this error on M1 using Big Sur: no quotes. As suggested, I did this without -p and entering the correct password is accepted, but I still get this error.... xcrun altool --notarize-app -t osx --file mydmg.dmg --primary-bundle-id com.mydomain.mySoftware -u myemail@myu.edu myemail@myu.edu's password: 2020-11-26 07:56:05.092 altool[31245:301096] CFURLRequestSetHTTPCookieStorageAcceptPolicy_block_invoke: no longer implemented and should not be called No errors uploading 'mydmg.dmg'. RequestUUID = d5c46e28-cbbd-44f5-802a-12112c3d81***

Thanks to the work of fxcoudert and Iain Sandoe there is now an experimental release of gfortran. It worked well in my limited testing.  https://github.com/fxcoudert/gfortran-for-macOS/releases

Thanks for the quick response. I made the changes you suggested and that did not fix anything. Can you provide a link to any script for notarizing a basic "helloworld" terminal application not using Xcode? I really want to avoid the Xcode route, as it would be nice to port quite a few tools that are popular in my field.

@Etresoft thanks for your solution. This works! There is a tiny typo: "--root ./tmp/usr/local" should read "--root usr/local". I still think Apple could help out the community a lot by providing a graphical tool to help the many cross platform projects that do not use Xcode. There are a lot of moving parts, and the feedback is opaque. It seems like details change between OS releases, so search the web for answers causes issues with solutions that used to work.

Python is a complex project. I would suggest you get a pre-compiled version for your platform. A good place to start would be the miniforge distribution which includes a version compiled for arm64 (Apple Silicon) - https://github.com/conda-forge/miniforge#download. However, you may find that many modules do yet support this architecture (e.g. Pandas), some that do support it are built using experimental compilers (gcc/gFortran) that may have issues or poor performance. Even core modules like numpy exhibit some bugs - https://github.com/numpy/numpy/issues/17964 on the M1, and some native functions perform a magnitude slower than the same function run as translated code - https://github.com/numpy/numpy/issues/17989 (which suggest low hanging fruit for optimization). It seems like these issues are getting rapidly resolved, but in the short term I would suggest sticking with the translated Python unless you are explicitly trying to resolve these limitations.

Hello, Is it still impossible for the Metal fragment shader to write to the depth buffer for the current version of Metal on the M1 CPUs? The image below shows the use case for my MRIcroGL software (with these images showing the correct behavior of OpenGL on my M1). MRIcroGL is a volume raycaster. The vertex shader simply determines the location of the front faces of the cube (left panel). The fragment shader subsequently samples each pixel from the front face of the cube to the back face, accumulating color/opacity from all the voxels it traverses. In OpenGL, I can simply write 'gl_FragDepth' for a ray when it first hits a non-transparent voxel. This has two benefits: first the depth test fro the subsequent crosshairs correctly shows the ntersection with the brain, not the cube. Second, we can read the depth buffer allowing depth picking, where clicking on the brain moves the crosshair to that location (allowing the user to work out the location of features seen on the rendering for 2D orthogonal slices). In every other respect, my software works identically when compiled for OpenGL and Metal. However, the inability to write to a depth buffer seems like a deal breaker for this usage scenario.

At least on my M1, the Metal fragment shader can write to the depth buffer using this method

I get the "Error: Server returned an invalid MIME type: text/html, body" intermittently. While I do appreciate that Apple is attempting to protect users from malware, the notarization process is a nightmare for developers. It seems the opposite of the it just works ethos that made Apple famous.