Power PC error message on MacBook Pro

Yes, that makes sense, as after the command line start, they don’t appear in the GUI. Thanks!

@john_drivenupthewall, who has to run SketchUp from the command line first time? I’m concerned @boatanchors has a corrupt download. @boatanchors, did you download Pro or Make, and when you do cmd-i in finder, where does it say the .dmg came from?

@Barry, this was a solution posted on the other thread, I’m surprised it worked then and now…

based on other reports I don’t think it’s corrupted downloads, it seems more like a incorrect flag is being set during the install…

john

I did some web searching, and SketchUp isn’t the only app whose users are reporting this problem. It seems there are some circumstances in which OS X can get confused during installation about the architecture of a perfectly valid 64-bit Intel app. So far as I could find, nobody knows exactly what goes wrong or why.

Another fix seen in forums for other apps is to copy the app onto the desktop, run it from there (which somehow avoids the PowerPC issue) and then copy it back to the proper folder. Some people also reported that changing the extension to something other than .app and then changing it back worked.

1 Like

Not likely a corrupt download as i downloaded it several times at widely differing times and got the same result each time. Here is the Info pane for the dmg file:

On further reading, both the problem and all of the fixes are consistent with the Launch Services database somehow getting an incorrect architecture entry for SketchUp. This database is automatically updated when certain things happen that make the system aware of a new application - for example, copying it into the Applications folder (as happens when you install), running it from somewhere else that the launch service doesn’t normally scan, changing it into something other than a .app and then back again, etc. OS X is also supposed to scan /Applications and update the database when the system boots, though it might not do anything unless it appears the app has been changed.

3 Likes

For those SketchUp users experiencing this problem, have you ever had a PowerPC version of SketchUp installed in the past?

I have an @Last installation disk for SketchUp version 2.0 (2003) that says it requires MacOS X 10.1 or later so PowerPC versions have existed. It might be that version 3 or 4 was the last that worked on non-Intel processors. To use a PowerPC version of SketchUp you would have to have a PowerPC computer that wouldn’t be able to run any current version of SU. And vice versa. The IMac I bought for my daughter about 10 years ago was no longer able to run PPC applications.

Anssi

I have never had a PowerPC program installed on the MacBook in question.

Apple switched to Intel CPUs in 2006, so for a period of time they needed to support both Intel and PowerPC. The standard way to distribute an app for both architectures is to use a so-called “universal” binary, which is really just separate binaries gathered together in a single bundle (making the bundle large, which is why this variety is sometimes called a “fat app”). SketchUp came out that way for a while (I found one site that claimed SU 7 would run on PowerPC). As time has passed, fewer and fewer apps have been distributed in this format. It eats up disk space and also forces developers to support both architectures. Not many apps are coming out this way any more, because the extra effort isn’t justified by the small remaining PowerPC market.

But, I wonder how Launch Services marks an app in the database when it is distributed as a universal binary? Could it be that the database says the app is ok for both architectures even though you only have Intel, and that installing a new version under El Capitan fails to clear the obsolete flag? I don’t have an old installer to try this theory out…

Edit: on further thought, the previous theory doesn’t make sense. Each incarnation of SketchUp is installed and registered separately, not as a update to the previous one. They get separate entries in the Launch Services database, which is why multiple versions can coexist on the same Mac.

As far as I can tell by looking at a dump of the launch services database, there doesn’t seem to be any information pertaining to the supported CPU architectures stored there. My (very, very speculative) theory was that users experiencing this problem might have had a PowerPC version of SketchUp installed in the past and that a corrupted launch services database was causing the system to try to execute that instead of the real SU2016.

There are a lot of ifs in that theory that need to be satisfied for it to make any sense though:

  • Had to have installed a PowerPC version of SketchUp in the past.
  • Had to have updated to the current system configuration from a version of OS X that could have executed Power PC binaries in the first place (PowerPC binary support on Intel CPUs was removed in OS X 10.6).
  • The launch services database needs to be preserved through OS upgrades (and I don’t know if it is) in order for it to “remember” an old PowerPC version of SketchUp.

So anyway, my question about whether or not users experiencing this problem have ever installed a PowerPC version of SketchUp was an attempt at narrowing this down. If people who are having this problem have never, ever run a PowerPC version of SketchUp then clearly this cannot be the source of the trouble.

Oops. It looks like Rosetta (the PowerPC to Intel translation software) was removed from OS X 10.6 but would still run there if you could install it (or kept it from your previous installation). Support for it was officially dropped in 10.7.

Thayer & I were chatting: perhaps you’ve used a Time Machine backup at some point in time? Time Machine, anyone?

I have taken regular TM backups, but have never restored from one.

the flag shown using mdls for SU v5 on my mac kMDItemExecutableArchitectures = ( ppc )

if I try to open v5 I get the exact same dialog [as expected for v5]

my totally speculative guess, is this same flag is being ‘set’ when the dmg’s drag’n’drop is done in a List View…

and the error dialog is generated by this flag…

thinking out loud…

john

From lsregister -dump, scroll down until you see the item flags (I added the ** trying to make it bold):

Container mount state: mounted
bundle  id:            111392
        Mach-O UUIDs:  252A9512-A9D8-3E33-B12D-3C0984F23C4C
        sequenceNum:   617
        FamilyID:      0
        PurchaserID:   0
        DownloaderID:  0
        installType:   0
        appContainer:  
        dataContainer: 
        path:          /Applications/SketchUp 2016/SketchUp.app
        name:          SketchUp
        displayName:   
        itemName:      
        teamID:        J8PVMCY7KL
        staticSize:    0
        storeFront:    0
        versionID:     0
        sourceAppID:   
        category:      
        identifier:    com.sketchup.SketchUp.2016 (0x800e094e)
        canonical id:  com.sketchup.sketchup.2016 (0x80041d88)
        vendor:        
        type:          
        version:       16.1.1451 (0x00004000002005ab)
        versionString: 16.1.1451
        displayVersion 16.1
        codeInfoID:    
        mod date:      2/24/2016 14:37:07
        reg date:      3/22/2016 10:14:37
        type code:     'APPL'
        creator code:  'SKPa'
        flags:         has-display-name  relative-icon-path  
        item flags:    container  package  application  extension-hidden  native-app  **x86_64**  
        icons:         Contents/Resources/sketchup_icons.icns
        executable:    Contents/MacOS/SketchUp
        inode:         44161063
        exec inode:    44162076
        container id:  32
        min version:   10.9 (0x0000280001200000)
        mach min ver:  10.9 (0x0000280001200000)
        execSDK ver:   10.9 (0x0000280001200000)
        library:       
        library items:
        schemesList:   NONE
        activityTypes: NOTIFICATION#J8PVMCY7KL:com.sketchup.SketchUp.2016, pv-f49b821ba1f3db
        --------------------------------------------------------
        type    id:            48748
                uti:           com.sketchup.skp
                description:   SketchUp Model file
                flags:         exported  active  trusted  
                icon:          
                conforms to:   public.data, public.content

Doh! Missed that. Thank you for highlighting it.

‘Rosetta’ was incorporated until OSX v10.6.8 ‘Snow Leo’ and dropped with 10.7 ‘Lion’… ‘Rosetta’ is an integral part of the OS and cannot be installed separately.

This issue recently appeared for us in our QA lab and we found the following.

Here’s the TL;DR:

  • The problem is with a corrupted Launch Services database.
  • The corruption can be fixed by forcing Launch Services to rebuild its database using the following command:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain user

And some more detail for the curious:

In our case it was the LayOut app’s icon that was flagged with the “white circle and slash” while SketchUp and Style Builder looked fine. As expected based on the Finder icons, LayOut failed to run and presented the dreaded “You can’t open the application “SketchUp” because PowerPC applications are no longer supported.” error. SU and SB ran without any problems (again, this was expected based on their icons).

Digging into the Launch Services database with lsregister -dump we found that the entry for LayOut.app was incorrect and was missing the x86_64 flag (this is included in the “item flags” field of the lsregister output that @slbaumgartner included above). SketchUp.app and Style Builder.app were correctly marked as supporting x86_64 even though these app bundles came from the same dmg and the same build.

A bit of web searching revealed that Launch Services can be forced to rebuild its database using the command shown above. After rebuilding the database and rerunning lsregister -dump we found that LayOut.app’s entry was now correctly flagged as supporting x86_64, LayOut.app’s icon was no longer badged with the white circle and slash, and LayOut.app ran correctly when double-clicked in the Finder.

A few more tidbits:

  • As observed by some users, this problem can be fixed by moving the offending app bundle to a new location. This is because the Launch Services database contains the full path to the offending application so it treats the same bundle differently depending on its location on disk. If you move an app bundle to a new location, Launch Services will create a new database entry and that entry will not contain the corruption from the entry for the original location. This is also why the issue reappears if you move the app bundle from a location where it works back to a location where it previously failed.

  • Launching directly from the terminal by running SketchUp.app/Contents/MacOS/SketchUp will work even when launching from the Finder does not because direct invocation of the app’s executable binary in the terminal side-steps Launch Services.

3 Likes

Haha… I noticed this randomly, I thought, when I could launch it from
lldb but not Finder or terminal directly. Wow.

1 Like