Seems like since Windows 10, the platform.architecture() function has been returning an erroneous value for the Windows Architecture. Shouldn't it identify AMD64? In any case PE is wrong.
From Microsoft:
Windows PE (WinPE) is a small operating system used to install, deploy, and repair Windows desktop editions, Windows Server, and other Windows operating systems.
When I start Python I get:
Python 3.7.9 (tags/v3.7.9:13c94747c7, Aug 17 2020, 18:58:18) [MSC v.1900 64 bit (AMD64)] on win32
Then I execute the following Python commands with the shown result.
import platform
platform.architecture()
('64bit', 'WindowsPE')
platform.architecture doesn't do what you think it does. It returns:
the bit architecture and the linkage format used for the executable.
(emphasis mine)
i.e. the executable passed (sys.executable, your python installation, by default) is 64-bit and is a Windows Portable Executable.
If you want the machine type you want platform.machine:
>>> import platform
>>> platform.machine()
'AMD64'
Related
I run my program perfectly on my Raspberry Pi 3 when I run 32bit Raspibian. It is a Linux 5.10.33-v7+ #1 armv7l system. The programs were compiled on this system, in C++. If I copy the executables to another card with that system, it works.
However, these same executables do not run when I use Debian 4.19.181-1 aarch64 Linux 4.19.0.16-arm64 (I copy the compiled file and paste it on the other system ).
When trying to run, it returns:
-bash: ./Myprogram: No such file or directory.
If I try to run with bash Myprogram, it returns:
Myprogram: cannot execute binary file
From what I've researched, this is an incompatible architectural error.
I've already tried changing permissions with chmod.
I think 32bit files should work on a 64bit system.
The "file" command returns:
ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for
GNU/Linux 3.2.0,
BuildID[sha1]=ad484c860b63e0d8735c2b7aa5c69f2e49caaf29, with
debug_info, not stripped
Thank you so much
I understand the problem is the architecture. But why can the same processor (same raspbery) run an armv7l OS and also an arm64 OS? How does compatibility work?
Why does raspberry run both arm64 OS and armv7l OS but not programs?
it's not just a 32 or 64 bit problem .
you are two differents architectures, for your program to work you have no choice, you must recompile it for this architecture.
If you want to make portability you can use systems like "Make".
when i run simple_dff cocotb example:
make SIM=ghdl TOPLEVEL_LANG=vhdl
i got following error:
loading VPI module 'C:/users/tomek/miniconda3/lib/site-packages/cocotb/libs/libcocotbvpi_ghdl.dll'
%1 is not Valid Win32 Application.
C:\eda\ghdl\bin\ghdl.exe:error: cannot load VPI module
my setup:
Windows 10 64-bit
GHDL 0.37 (v0.37) [Dunoon edition] Compiled with GNAT Version: 9.1.0
Python 3.7.7 [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
conda 4.8.3
cocotb '1.4.0'
i guess something is wrong with 64 vs 32 bit libs...
Any help is welcome
Try to follow those instructions: https://github.com/cocotb/cocotb/wiki/Tier-2-Setup-Instructions#32-bit-python and https://docs.cocotb.org/en/stable/install.html#installation-of-prerequisites
Last time I have checked GHDL had issues to run on Windows (probably not related to cocotb) see: https://github.com/cocotb/cocotb/pull/1644
I need help in compiling binary files from MacOS to Windows32 & Windows64 bit. In documentation it is written that we need to compile binary according to platform but actual options/parameters are not provided in documentation for it
Got the parameters from nwjc --help section, tried with following but nothing works:
nwjc --target-os win32 --target-arch ia32 nwapp/main.js nwapp/main.bin
nwjc --target-os win32 --target-arch x86_64 nwapp/main.js nwapp/main.bin
nwjc --target-os win32 --target-arch x64 nwapp/main.js nwapp/main.bin
By default, the binary compiled on MacOS is running on 64 bit windows without any target parameters.
Can you give me the parameters and possible values for compiling for Windows32 & Windows 64 from MacOS?
I have got the answer from nwjs gitter group. The answer is:
If you want to compile JS files to v8 binary files for a target
platform, let's suppose Windows 32 bit, then you need to compile them
on the target platform only. You cannot compile binaries for Windows
32 from a different OS (in my case I was trying with MacOS)
I try to understand the requirements for developing Linux application running on 64-bit OS (with 64-bit architecture).
If the code was written for 32-bits architecture, does it mean that on regular compilation (gcc -m32) it will run on the 64-bit system OS, without any problems ?
Thank you,
Ran
Yes, it will. The only caveats to this are that you need 32 bit libraries to run the program, and 32 bit development packages to compile it. Most distros provide these and make it simple to install them as well.
I am using a software for graph mining.
I have got the binary of that software in 2 folders for Linux mode and SunOs mode but don't have the source.
I am able to run the binary in Linux machine.
But when I want to run the binary in a Mac machine I am getting "command not found" for both the Linux and SunOs folders' binaries.
Could someone suggest if it can be able to run this in a MAC machine by any means like using a Linux shell or something
Gaurav
EDIT:I am getting "cannot execute binary" error when I set chmod to "u+x"
You'll need to recompile it for OS X or use a VM.
A command not found just means you're not executing it right, make sure it's chmod u+x and it's either on your PATH, or you specify the path explicitly.
If you use the file command you will see the difference, on the linux executable you'll have something like:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.15, not stripped
and something like this for OS X executables:
command: Mach-O universal binary with 2 architectures command (for
architecture x86_64): Mach-O 64-bit executable x86_64 command (for
architecture i386): Mach-O executable i386
Operating systems generally don't support executing object code any extra formats... If Mac osx decended from solaris or Linux, then there could be some incentive for legacy support. But just assume everything to be binarily incomparable if it was compiled for a different arch and platform. There are a few places where you inherit backwards compatibility, running 32 but code on 64 bit oses... Or ppc code support on intel macs, but I suspect that both of those, especially the latter were non trivial engineering tasks.
Here are your options...
Get the source and compile on the Mac, if it compiles on Linux and solaris good chance it will compile and run ok on Mac.
Run through an emulator or boot camp