Bad cpu type in executable wine mac os

macOS Catalina: wine doesn’t work #51

Comments

antelle commented Oct 8, 2019

So, this package throws an error indeed. Example: electron/electron-packager#1055

Would be nice to find a mitigation.

The text was updated successfully, but these errors were encountered:

MarshallOfSound commented Oct 8, 2019

This is an issue with your install of wine , Catalina disables 32bit applications

malept commented Oct 8, 2019

@MarshallOfSound I think the answer is to add the x64 binary to node-rcedit (#50).

antelle commented Oct 8, 2019 •

It won’t work because there’s no x64 version of wine for mac.

malept commented Oct 8, 2019 •

Then I suppose the workaround is to either run Windows in a VM, or Linux (with Wine) in a container/VM.

cap10morgan commented Oct 11, 2019

When I install wine on my Mac via Homebrew, I get a /usr/local/bin/wine64 that works. If there were a 64-bit version of rcedit.exe, it would likely work with that wine binary.

alexluoli commented Oct 25, 2019

brew upgrade wine, make sure «/usr/local/bin/wine64» exist rm -rf

/.wine

edit «node_modules/rcedit/lib/rcedit.js», change «wine» to «wine64» at line 42

download «https://github.com/electron/rcedit/releases/download/v1.1.1/rcedit-x64.exe», rename to «rcedit.exe» and replace «node_modules/rcedit/bin/rcedit.exe»

maximilianschmidt commented Oct 25, 2019 •

thanks @alexluoli, works like a charme. i didn’t even had to follow step 2 ( rm -rf

/.wine ). it seems that a fix is already waiting to be merged: #50

AndreiSoroka commented Oct 25, 2019 •

maximilianschmidt commented Oct 25, 2019

@AndreiSoroka you should target the node_modules folder in your project

AndreiSoroka commented Oct 25, 2019 •

@maximilianschmidt oh, but I didn’t have rcedit.

rcedit should be in the dependencies on vue-cli-plugin-electron-builder?

P.s. this is my first experience with electron

maximilianschmidt commented Oct 25, 2019

@AndreiSoroka i think its a peer-dependency and thus not listed in the package.json. just use Finder for navigating to /node_modules/rcedit

AndreiSoroka commented Oct 25, 2019 •

@maximilianschmidt yep.
I checked: ./node_modules/** (with deep folders)
find ./node_modules -name rcedit
And not found

antelle commented Oct 26, 2019 •

Nice, question to authors: what about rebuilding the package? 😉
(oops, haven’t noticed that a PR is already there)

paul321 commented Oct 30, 2019

Why isn’t anyone updating this repo with rcedit-x64 if that is the solution?

charmer1989 commented Nov 23, 2019

brew install homebrew/cask/wine-stable Then mv /usr/local/bin/wine64 /usr/local/bin/wine

esigalas commented Nov 27, 2019

. and replace «node_modules/rcedit/bin/rcedit.exe» .

can I ask what is the full path for that file?
thanks

unbreakableglass commented Dec 2, 2019

. and replace «node_modules/rcedit/bin/rcedit.exe» .

can I ask what is the full path for that file?
thanks

esigalas commented Dec 2, 2019

. and replace «node_modules/rcedit/bin/rcedit.exe» .

can I ask what is the full path for that file?
thanks

now I am confused
why do I have to have npm installed?

kylekrzeski commented Dec 2, 2019

1. brew install homebrew/cask/wine-stable Then mv /usr/local/bin/wine64 /usr/local/bin/wine
2. download «https://github.com/electron/rcedit/releases/download/v1.1.1/rcedit-x64.exe», rename to «rcedit.exe» and replace «node_modules/rcedit/bin/rcedit.exe» (Thanks from #51 (comment))

rcedit wasn’t in my project or /usr/local/lib/node_modules. I tried npm installing it and doing those steps though that didn’t seem to work. Any idea what to do if it’s not there?

esigalas commented Dec 8, 2019

ok actually I found a solution to my problem.

I have installed wine-stable using brew cask.
when I run the wine command I get the known error
% wine zsh: bad CPU type in executable: wine

but there is a proper binary installed as well, so I just used the command wine64 instead

Источник

Question: Q: «Bad CPU Type In Executable»

After upgrading from an eMac to an Intel Mac Mini, I noticed that I needed to reinstall Xcode. Once I reinstalled Xcode (v2.4), I made some changes to one of my applications. After testing it fully on my new Mac, I copied the .app file to my old eMac and attempted to re-run. In doing so, I received the following error message:

«You cannot open the application ‘NAME OF APPLICATION’ because it may be damaged or incomplete.»

So, in Terminal, I navigated through the Package Contents to the actual executable and tried to run it. I, then, received the following error:

«Bad CPU type in executable.»

How do I correct this error, so it will run on both of my Macs??

THANKS IN ADVANCE!!

WBELL

eMac Specs:
1GHz, 768MB DDR, OSX 10.4.x
Mini Specs:
1.5GHz Core Solo, 1024MB DDR2, OSX 10.4.x

Mac Mini Mac OS X (10.4.7) 1.5GHz Core Solo

Posted on Sep 19, 2006 1:26 PM

Helpful answers

Sep 19, 2006 2:56 PM

I believe you have to make the change to the «Architectures» setting for each of your build configurations. so, for example, if you made the change while you were working on a «Debug» version of your app and later switched to a «Release» version, built and moved the app across to your other machine. the Release version would not have the dual-architecture setting.

Go back to the «Build» tab in your Project Settings and use the pop-up menu at the top to check both the «Debug» and «Release» configuration to make sure PPC and Intel are set for both of them.

EDIT: Also make sure the «SDK Path» is set to «/Developer/SDKs/MacOSX10.4u.sdk» for both configurations.

Sep 28, 2006 9:58 AM

There’s more to the conversation

Loading page content

Page content loaded

Sep 19, 2006 2:56 PM

Thanks, Daniel, I’ll try that, and then let you know if it worked.

Sep 21, 2006 12:35 PM

I went into «Edit Project Settings», from the «Project» menu. Under «General», there is a section called «Cross-Develop Using Target SDK». This was, and is, set to «Mac OS X 10.4 (Universal)». I saw nothing that allowed me to choose PowerPC and/or Intel CPU types. I also tried rebuilding the project using «Mac OS X 10.2». This still didn’t work. I still get the same errors, using either selection. There’s got to be an easier solution that I’m missing. Any ideas?

Sep 21, 2006 1:08 PM

Under the «Project» settings select the «Build» tab. The first item in the list should be «Architectures». Double-click «Architectures» and it should display a sheet allowing you to select PowerPC and/or Intel.

Sep 21, 2006 8:02 PM

WOW!! Thanks!! This help is VERY appreciated!

Sep 28, 2006 8:30 AM

Well, I thought we had figured it out, but it appears that it is still not working. After checking the «PPC» box, I now get «You cannot open the application because it is not supported on the architecture.»

Sep 28, 2006 9:10 AM

I believe you have to make the change to the «Architectures» setting for each of your build configurations. so, for example, if you made the change while you were working on a «Debug» version of your app and later switched to a «Release» version, built and moved the app across to your other machine. the Release version would not have the dual-architecture setting.

Go back to the «Build» tab in your Project Settings and use the pop-up menu at the top to check both the «Debug» and «Release» configuration to make sure PPC and Intel are set for both of them.

EDIT: Also make sure the «SDK Path» is set to «/Developer/SDKs/MacOSX10.4u.sdk» for both configurations.

Sep 28, 2006 9:58 AM

Below are links to screenshots of my current «General» and «Build» tabs. The current configuration, when built, will not run on any PowerPC.

Thanks again, for the help!

Sep 28, 2006 10:40 AM

Hmm.. I’m not sure what to suggest.

If you select your built application in Finder and do a «File -> Get Info» what does it say next to «Kind:»? It should say «Application (Universal)».

If it doesn’t say it’s universal then something’s still not right with your build settings. Maybe try doing a «Clean» and then another «Build».

If it does say it’s universal. but still gives you the error that it’s not built for that architecture. I’m not sure what to suggest. :^(

Sep 28, 2006 11:10 AM

Nope. My «Get Info» is saying «Kind: Application (Intel)». We must be missing a setting somewhere.

Sep 28, 2006 11:15 AM

I know you’re busy, but have you managed to find other possible solutions??

Oct 4, 2006 9:05 AM

At this point I’m not sure what to suggest. Maybe your build results window would have some clue. Do a «Build->Clean» on your project, then select «Window->Tools->Build Results» to open the build results window. Then click the «Build» button to rebuild your app.

When I build a Universal binary the build results window shows several «Copying» steps, then a couple of «Precompiling» steps, followed by «Compiling» for each of my .m files, then «Building ZeroLink launcher». then a second set of «Compiling» steps for each .m (for the second architecture), then another «Building ZeroLink launcher» and finally a «Creating Universal Binary» step.

What are you seeing in your build result window? Do you see the second set of «Compiling» steps?

Oct 4, 2006 9:43 AM

Here’s what I’m seeing.

I wonder why I’m getting these errors?

Oct 12, 2006 8:21 AM

Here are a couple of things to check.

First, from your screen shot it appears that the main.m file is from an older AS Studio application (ie is this a project that was originally created some time ago. perhaps under Project Builder?). The main.m file that gets included with relatively new AS Stdio apps looks like this:

So you may want to copy/paste the main.m code from a newly created AS Studio app into your (older?) existing project. I’m not sure the above problem would cause the failure to build a Universal app, but changing code in main.m may get rid of the warnings you’re seeing.

But also, the screenshot made me wonder if your target(s) needs to be converted to the newer «native» target format (this is different from the «conversion» that Xcode does to an older project file). With your project open click on Xcode’s «Project» menu. is the option «Upgrade ‘YourTargetName’ to Native Target» or «Upgrade all Targets in Project to Native» available? If so, I think you must convert to native targets in order to build universal binaries.

Источник

bad CPU type in executable: nmap (x86 -> x64) #1722

Comments

dotnes commented Sep 2, 2019

Nmap is not working on the latest release of Mac OS 10.15 since it is a 32 bit application. Apple dropped support for 32-bit applications as per the latest release which kills a lot of applications.

The text was updated successfully, but these errors were encountered:

dmiller-nmap commented Sep 4, 2019

Thanks for the report. What version of Nmap are you using? This was supposed to be fixed in Nmap 7.80, as reported in issue #1371 .

dotnes commented Sep 17, 2019

installed via brew version stable 7.80 (bottled), HEAD

westz36 commented Oct 15, 2019

allupaku commented Oct 20, 2019 •

aliasmee commented Oct 22, 2019

vegetableZucchini commented Oct 22, 2019

PfeisiMark commented Oct 24, 2019

dmiller-nmap commented Oct 28, 2019

We do not support the Homebrew builds. If you have a problem with the Nmap source or our .dmg installer from https://nmap.org/download.html#macosx then we will address those issues here.

FrancYescO commented Mar 8, 2020 •

EDIT: follow @natersoz, next, just the wrong way to do the same.

For anyone interested to fix the brew installation:

Probably the Catalina upgrade fucked up the old installation/symlinks
after nmap update via brew keep issuing brew link nmap
and deleting with sudo all the files (or in some case folders, but pay attention that are only nmap/npin/ncat related) it say cannot write

like:
some LANGUAGE folders in /usr/local/share/man/LANGUAGE
sudo rm -rf /usr/local/share/ncat
sudo rm /usr/local/share/ncat
sudo rm /usr/local/share/ncat/ca-bundle.crt

natersoz commented Apr 11, 2020

FYI: This required the following command to get it to work for me:
brew link —overwrite nmap

Источник

CrossOver Support — Community Forums

The following comments are owned by whoever posted them. We are not responsible for them in any way.

Not being able to create a bottle may be due to the removal of 32 bit executables starting with macOS Catalina.

I have experimented with both 32 bit-bottles and 64-bit bottles on Catalina. The application I use is 32-bit application but it cannot be run using CrossOver even in a 64-bit bottle.

I have reinstalled Mojave on my MacBook to make the app functional again.

I will continue to explore ways to make it possible to a 32-bit windows exe on 64-bit bottle but I am in a halt right now.

Crossover does not work with Mac OS Catalina.

Codeweavers are working to solve this.

As Caleb said, Crossover 19 is currently in testing and does allow 32-bit Windows apps to run on Catalina.
Crossover 19 should be available soon, with Codeweavers announcing that officially on their blog.

Yes, I am testing the 2nd beta of crossover 19 and out of 27 32-bit PC games (all of them complex wargames or strategy games) for which I had working bottles in Mojave, 23 (85%) work fine in Catalina.

So I am extremely pleased with the extraordinary work Codeweavers is doing, and certain that a near perfect capability of running 32 bit Windows programs in Catalina will be possible.

Please Note: This Forum is for non-application specific questions relating to installation/configuration of CrossOver. All application-specific posts to this Forum will be moved to their appropriate Compatibility Center Forum.

CrossOver Forums: the place to discuss running Windows applications on Mac and Linux

Getting Around

CodeWeavers

We’re rebels. We’re misfits. But mostly, we’re software liberators. And we’re very, very good at what we do. We have to be. Lots of developers work with open source, but only a tiny fraction of those are good enough to get software that was designed for one platform to work on another one. We invented CrossOver software — a unique approach to cross-platform compatibility that does not require dual-boot or another OS license. We launched PortJump to help app and game developers broaden their market beyond Windows® users. And we launched ExecMode to help organizations solve really ugly technical challenges.

Please upgrade your browser to use our website.

Источник