Missing library on 64 bit riscv Fedora - fedora

I am working on an assembly-based Forth (on top of Linux - https://github.com/mcmenaminadrian/riscyforth) for Risc-V and I can build it and run it on my real 64 bit hardware (a Nezha SBC running a Debian-based install).
I decided to test it also on QEMU with Fedora but it won't run:
[root#fedora-riscv riscyforth]# ./riscyforth
-bash: ./riscyforth: No such file or directory
This seems to be because I am missing a library:
readelf -a ./riscyforth
....
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000010040 0x0000000000010040
0x0000000000000150 0x0000000000000150 R 0x8
INTERP 0x0000000000000190 0x0000000000010190 0x0000000000010190
0x000000000000000d 0x000000000000000d R 0x1
[Requesting program interpreter: /lib/ld.so.1]
And my understanding this is a 32 bit library - but my OS is 64 bit:
[root#fedora-riscv riscyforth]# uname -a
Linux fedora-riscv 5.10.6-200.0.riscv64.fc33.riscv64 #1 SMP Tue Jan 12 13:46:56 UTC 2021
riscv64 riscv64 riscv64 GNU/Linux
And, rather more importantly, so is the ELF:
[root#fedora-riscv riscyforth]# readelf -a ./riscyforth | more
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x10690
Start of program headers: 64 (bytes into file)
Start of section headers: 98992 (bytes into file)
Flags: 0x5, RVC, double-float ABI
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 23
Section header string table index: 22
I have updated the Fedora install and rebooted (as there was a mix of -33 and -32 packages before) but this has not fixed the issue.
Why do I need to install a 32 library and which one do I need to install? I cannot find an obviously titled RPM.
Or do I need to put something in the Makefile for Fedora that I don't need on the Debian system?

This seems to be because I am missing a library:
You are not missing a library, you are missing the ELF interpreter (/lib/ld.so.1), also known as the dynamic linker or the loader.
And my understanding this is a 32 bit library
I am not sure what "this" in your statement refers to; your binary is definitely 64-bit, and couldn't use any 32-bit libraries in any case.
Why do I need to install a 32 library
You don't.
It appears that normally /lib/ld.so.1 should be present on a RISC-V system and be a symlink to /lib/ld-linux-riscv64-lp64d.so.1 (at least on GLIBC-based systems).
So your QEMU target environment is missing required parts.
I fixed the immediate problem with ln -s /lib/ld-linux-riscv64-lp64d.so.1 /lib/ld.so.1 but I still hope someone can answer why I needed this.
Because you somehow didn't install GLIBC into your QEMU environment properly.

Related

how to use the new ntfs3 driver on fedora 34

linux kernel 5.15 comes with new ntfs3 driver, I'm on fedora 34 with kernel 5.15.6, but when I mount a device using ntfs3, it reports error:
# uname -a
Linux fedora 5.15.6-100.fc34.x86_64 #1 SMP Wed Dec 1 13:41:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
# mount -t ntfs3 /dev/sda1 /run/media/sify/Elements\ SE
mount: /run/media/sify/Elements SE: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
do I need to do anything special to use the new ntfs3 driver?
I solved this by repairing the hard disk on windows using chkdisk, it took a whole day and I lost some data. But after that, I can mount the disk using ntfs3. I suspect I've saved some malformed data on that disk before.

Octave 4.4.1 fails to start on 32 bit Windows 7

Octave 4.0.0 works on Windows 7 32 bit. I have just downloaded 4.4.1 and it has never worked.
Following information:
Problem signature:
Problem Event Name: APPCRASH
Application Name: octave-gui.exe
Application Version: 0.0.0.0
Application Timestamp: 00000000
Fault Module Name: Qt5Core.dll
Fault Module Version: 5.11.0.0
Fault Module Timestamp: 00000000
Exception Code: 40000015
Exception Offset: 002e8696
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3081
Additional Information 1: d1e0
Additional Information 2: d1e00fdc0b78c108f75564157f84c2f0
Additional Information 3: f785
Additional Information 4: f7855e1e76ad3f0614cfa9b98110597e
Found a vaguely similar problem, failing to start GUI on Windows 10, applied suggested solution of setting "Disable display scaling on high DPI settings" under Compatibility tab of executable Properties.
If you download GNU octave from octave.org you'll see a list:
Windows-64 (recommended)
octave-4.4.1-w64-installer.exe (~ 238 MB) [signature]
octave-4.4.1-w64.7z (~ 267 MB) [signature]
octave-4.4.1-w64.zip (~ 481 MB) [signature]
Windows-32 (old computers)
octave-4.4.1-w32-installer.exe (~ 238 MB) [signature]
octave-4.4.1-w32.7z (~ 267 MB) [signature]
octave-4.4.1-w32.zip (~ 481 MB) [signature]
Of couse a 64bit built will NOT run on a Windoze7 32bit so you have to get octave-4.4.1-w32-installer.exe and install this

Why boot system, load two versions of u-boot?

I have a gateway device with MT7620a in MIPS architecture. The device has installed OpenWRT. If I connect to device via UART with the goal of flashing new firmware I see something I don't understand, MCU loading two version U-Boot.
U-Boot 1.1.3
Ralink UBoot Version: 4.3.0.0
Here is Log System after start
U-Boot 1.1.3 (Apr 27 2015 - 13:54:38)
Board: Ralink APSoC DRAM: 128 MB
relocate_code Pointer at: 87fb8000
enable ephy clock...done. rf reg 29 = 5
SSC disabled.
spi_wait_nsec: 29
spi device id: 1c 70 18 1c 70 (70181c70)
find flash: EN25QH128A
raspi_read: from:30000 len:1000
*** Warning - bad CRC, using default environment
============================================
Ralink UBoot Version: 4.3.0.0
--------------------------------------------
ASIC 7620_MP (Port5<->None)
DRAM component: 1024 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 128 MBytes
Flash component: SPI Flash
Date:Apr 27 2015 Time:13:54:38
Of course I have a few additional questions in this issue:
What is different between these U-Boot ?
Why does my device need two versions U-Boot ?
Whether this u-boots need separate *.bin image or these is together
in one image *.bin ? In my device is only one partition for u-boot image and one partition for variables:
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
As Alexandre Belloni said, there is probably only one version of U-Boot on your device, it just has two different version identifiers.
The reason for this is that manufacturers often need to modify the U-Boot source code in order to get it to operate on their device, or to add features.
On your device, it looks like the version of U-Boot that Ralink pulled from the official U-Boot source code repository is 1.1.3. Ralink's own internal version number that they use for tracking their internal modifications is 4.3.0.0.
There is probably only one u-boot and "Ralink UBoot Version: 4.3.0.0" is an internal u-boot version for Ralink.

Cannot run CUDA code that queries NVML - error regarding libnvidia-ml.so

Recently a colleague needed to use NVML to query device information, so I downloaded the Tesla development kit 3.304.5 and copied the file nvml.h to /usr/include. To test, I compiled the example code in tdk_3.304.5/nvml/example and it worked fine.
Over a weekend, something changed in the system (I cannot determine what was changed and I am not the only one with access to the machine) and now any code that uses nvml.h, such as the example code, fails with the following error:
Failed to initialize NVML:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WARNING:
You should always run with libnvidia-ml.so that is installed with your NVIDIA Display Driver. By default it's installed in /usr/lib and /usr/lib64. libnvidia-ml.so in TDK package is a stub library that is attached only for build purposes (e.g. machine that you build your application doesn't have to have Display Driver installed).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
However, I can still run nvidia-smi and read information about my K20m's state, and as far as I am aware nvidia-smi is just a set of calls to nvml.h. The error message I receive is somewhat cryptic, but I believe it is telling me that the nvidia-ml.so file needs to match the Tesla driver that I have installed on my system. Just to ensure everything is correct, I re-downloaded CUDA 5.0 and installed the driver, CUDA runtime, and the test files. I am certain that the nvidia-ml.so file matches the driver (both are 304.54) so I am quite confused as to what could be going wrong. I can compile and run the test code with nvcc as well as run my own CUDA code, as long as it doesn't include nvml.h.
Has anyone encountered this error or have any thoughts on rectifying the issue?
$ ls -la /usr/lib/libnvidia-ml*
lrwxrwxrwx. 1 root root 17 Jul 19 10:08 /usr/lib/libnvidia-ml.so -> libnvidia-ml.so.1
lrwxrwxrwx. 1 root root 22 Jul 19 10:08 /usr/lib/libnvidia-ml.so.1 -> libnvidia-ml.so.304.54
-rwxr-xr-x. 1 root root 391872 Jul 19 10:08 /usr/lib/libnvidia-ml.so.304.54
$ ls -la /usr/lib64/libnvidia-ml*
lrwxrwxrwx. 1 root root 17 Jul 19 10:08 /usr/lib64/libnvidia-ml.so -> libnvidia-ml.so.1
lrwxrwxrwx. 1 root root 22 Jul 19 10:08 /usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.304.54
-rwxr-xr-x. 1 root root 394792 Jul 19 10:08 /usr/lib64/libnvidia-ml.so.304.54
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.54 Sat Sep 29 00:05:49 PDT 2012
GCC version: gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Fri_Sep_21_17:28:58_PDT_2012
Cuda compilation tools, release 5.0, V0.2.1221
$ whereis nvml.h
nvml: /usr/include/nvml.h
$ ldd example
linux-vdso.so.1 => (0x00007fff2da66000)
libnvidia-ml.so.1 => /usr/lib64/libnvidia-ml.so.1 (0x00007f33ff6db000)
libc.so.6 => /lib64/libc.so.6 (0x000000300e400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000300ec00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000300e800000)
/lib64/ld-linux-x86-64.so.2 (0x000000300e000000)
EDIT: The solution was to remove all extra instances of libnvidia-ml.so. For some reason there were a LOT of them.
$ sudo find / -name 'libnvidia-ml*'
/usr/lib/libnvidia-ml.so.304.54
/usr/lib/libnvidia-ml.so
/usr/lib/libnvidia-ml.so.1
/usr/opt/lib/libnvidia-ml.so
/usr/opt/lib/libnvidia-ml.so.1
/usr/opt/lib64/libnvidia-ml.so
/usr/opt/lib64/libnvidia-ml.so.1
/usr/opt/nvml/lib/libnvidia-ml.so
/usr/opt/nvml/lib/libnvidia-ml.so.1
/usr/opt/nvml/lib64/libnvidia-ml.so
/usr/opt/nvml/lib64/libnvidia-ml.so.1
/usr/lib64/libnvidia-ml.so.304.54
/usr/lib64/libnvidia-ml.so
/usr/lib64/libnvidia-ml.so.1
/lib/libnvidia-ml.so.old
/lib/libnvidia-ml.so.1
You are getting this error because the application that is trying to use nvml is loading the stub library that is located in:
...tdk_install_path/lib64/libnvidia-ml.so
instead of the one in:
/usr/lib64/libnvidia-ml.so
I was able to reproduce your error when I added the stub library path to my LD_LIBRARY_PATH environment variable. So that is one possible source of error, if someone added the path of the stub library that comes with the tdk distribution to your LD_LIBRARY_PATH environment variable, but probably not the only way this could happen. If someone in an unusual fashion copied the stub library to some system path, that might also be an issue.
You'll need to try and figure out why your system is loading that stub library in place of the correct one in /usr/lib64. Alternatively, for discovery purposes, you could try deleting all instances of the stub library anywhere on your system (leave the correct libraries in /usr/lib and /usr/lib64 alone), and you should be able to observe correct behavior.
I solved the problem this way on a GTX 1070 using windows 10 : go to device manager, select the GPU that is having a problem, disable the GPU and enable back.
I was having this same or similar issue with EWBF Cuda Miner for zCash.
Here is a way to automatically implement Pro7ech's answer (which worked for me) for WIN10:
Install WDK for Windows 10 if you don't already have it: This will give you the ability to use devcon.exe which allows manipulation of devices via batch scripts:
https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk
You might also need the Windows SDK if you don't have visual studio with Desktop development with C++ workload:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
To make things easier, you might want to add the installation path to your PATH environment variable:
https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/
Devcon.exe was installed here for me:
C:\Program Files (x86)\Windows Kits\10\Tools\x64
So now run this or similar in a cmd.exe prompt to get the device id:
devcon findall * | find /i "nvidia"
Here is what mine looks like:
C:\Users\Soenhay>devcon findall * | find /i "nvidia"
HDAUDIO\FUNC_01&VEN_10DE&DEV_0083&SUBSYS_38426674&REV_1001\5&1C277AD4&0&0001: NVIDIA High Definition Audio
SWD\MMDEVAPI\{0.0.0.00000000}.{574980C3-9747-42EF-A78C-4C304E070B81}: SAMSUNG (NVIDIA High Definition Audio)
ROOT\UNNAMED_DEVICE\0000 : NVIDIA Virtual Audio Device (Wave Extensible) (WDM)
PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000: NVIDIA GeForce GTX 1070
From that I see that my graphics device id is:
PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000
So I create a batch file with the following to disable and re-enable the driver:
devcon disable "#PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000"
devcon enable "#PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000"
Now, when I get the NVML error when starting the miner I just run this batch file and it fixes it. You could also just add those 2 lines to the beginning of your start.bat file to do this every time but I found that the error does not always happen every time I restart the miner time now.
References:
superuser post
devcon commands
devcon examples
No matching devices found.
NOTE:
The command should have the # symbol at the beginning of the device id.
The batch script should be run as administrator.
I have faced the same error.
Found a solutions is to run command:
nvidia-uninstall

MXMLC Incremental compilation not working

Google shows a couple of hits for this issue, but never a solution that I can find. It's always just a few other people saying "it works for me", and the issue dries up. I've tested both with the "-incremental=true" flag to mxmlc and with the <incremental>true</incremental> tag in my flex config.xml with the same result:
Failed to match the compile target with /export/vampire/build/Editor.swf.cache. The cache file will not be reused.
I get this on each compile after the first that creates the cache, whether the source files were modified or not.
I've checked file permissions (not expecting anything - the cache file and the swf it's checking against were both created by MXMLC to begin with):
-rw-rw-r-- 1 nathan nathan 3181508 2009-07-15 17:50 Editor.swf
-rw-rw-r-- 1 nathan nathan 5756512 2009-07-15 17:50 Editor.swf.cache
$ flex_sdk/bin/mxmlc -version
Version 3.3.0 build 4852
$ uname -a
Linux sargasso 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux
Ubuntu 8.04
It looks like the "Failed to match compile target" error is being caused by an updated timestamp on the flex config file. Even if the config file is unmodified, mxmlc will throw out the old compile cache and recompile everything as long as the timestamp is newer than that on the cache file. This misleading error message is all the info you get.