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
Related
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'
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 have compiled the python3.6 program on CentOS 6.8 using pyinstaller and tested on a newer version of Linux. It's working as expected. CentOS 6.8 has installed GLIBC 2.12
pyinstaller --onefile --clean --hidden-import sqlite3 --hidden-import pycryptodome my_python.py
However, I'm getting the follwing error when execute the compiled program on Redhat 5.8 as it has installed the GLIBC 2.5
[24522] Error loading Python lib '/tmp/_MEIl16Rvq/libpython3.6m.so.1.0': dlopen: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /tmp/_MEIl16Rvq/libpython3.6m.so.1.0)
Can you please help me how to compile the python3.6 program on CentOS 6 for Redhat 5.8?
P.S: I cannot update the GLIBC as I'm going to distribute the same program to the many Linux servers.
Answer to this question is listed in pyinstaller's FAQ as first one in GNU/Linux section. Here it is, a bit cut down version with my emphasis.
The executable that PyInstaller builds is not fully static, in that it still depends on the system libc. Under Linux, the ABI of GLIBC is [...] not forward compatible. [...] The supplied binary bootloader should work with older GLIBC. However, the libpython.so and other dynamic libraries still depends on the newer GLIBC. The solution is to compile the Python interpreter with its modules (and also probably bootloader) on the oldest system you have around, so that it gets linked with the oldest version of GLIBC.
I have downloaded node 0.10.31 source and built on my Linux machine using same steps mentioned in wiki. The source is just as it is and no changes made at all. The build is successful but when I compare bin/node file size with the one from binary downloaded there is around 900kb difference (built from source is bigger).
What is the reason?
Did I miss any optimizer or special config? Actually I wanted to use locally build node (after some change) in production. I just don't want to miss some settings here.
My environment:
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Python 2.6.6 (r266:84292, Nov 21 2013, 10:50:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Release: 6.5
Codename: Santiago
Note: Already posted in node.js groups, sorry for the cross post.
Thanks
You can try and strip out debugging symbols. E.g.,
$ strip node
Debugging symbols are pieces of information embedded in an object file, and useful for debugging purposes. Unfortunately, they take up space in the file, so if you do not plan debugging the node interpreter itself you could get rid of them.
Moreover, please check out strip's manual page for a full list of choices when discarding symbols from object files.
I met an err when I installed JikesRVM, that is,
skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.4/libstdc++.so when searching for -lstdc++
So I am trying to install/update it to a later version. Now, the machine already has
gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
I am new to openSUSE, could you help?
Thanks!
You need to install 32 bit support for the GNU C/C++ compiler since JikesRVM on x86_64 currently supports only the 32 bit architecture.
To install this support in OpenSuSE 11.2 type
sudo zypper install gcc44-32bit gcc-32bit libstdc++44-devel-32bit
The first two provide runtime support for the C language and the 32-bit version of libgcc, the GCC low level runtime library. The third provides the 32-bit version of libstdc++, both the static import library and the dynamic library. It is the static libstdc++.a that was missing for JikesRVM.
To verify that the 32bit C++ build system is installed correctly you can test it with the following
echo "int main(){}" | g++ -x c++ -m32 -
Note Official support for OpenSuSE 11.2 has ended. Evergreen support will be available through 2013. Yet it is reasonable to update to 11.3 or a later version soon.