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
Related
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.
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.
I am facing below exception while launching the Oculus SDK 0.6.0.1 demo program.
**Exception Info
Exception report file: C:\Users\Exception Report (2015-06-26 12.41.23).txt
Exception minidump file: C:\Users\Exception Minidump (2015-06-26 12.41.23).mdmp
Time (GMT): 2015/06/26 12:41:23
Time (local): 2015/06/26 18:11:23
Thread name: (not available)
Thread handle: 0x000000d8
Thread sys id: 976 (0x3d0)
Exception instruction address: 0x0ff4f677 (see callstack below)
Exception description: ACCESS_VIOLATION reading address 0x00000000
Exception location: ovr_WaitTillTime (59911)**
below is my app and system Info :
App Info
Process path: C:\Users\Downloads\ovr_sdk_win_0.6.0.0\OculusSDK\Samples\OculusWorldDemo\Release\OculusWorldDemo.exe
App format: 32 bit
App version info not present
System Info
OS name: Windows 7, version: 6.1 build 7601, 32 bit, platform id: 2, service pack: Service Pack 1
Debugger present: no
Processor count: 4
Processor type: x86
Processor level: 6
Processor revision: 10759
Memory load: 87%
Total physical memory: 3240 MiB
Available physical memory: 389 MiB
Total page file memory: 6480 MiB
Available page file memory: 2323 MiB
Total virtual memory: 2047 MiB
Free virtual memory: 1974 MiB
Can someone help me to understand what to do, to fix this issue :(
You didn't include any info about your video hardware & drivers; the first thing I'd try is upgrading them. Also try upgrading to the latest Oculus 0.7.0.1 runtime.
I am using Fedora and when I execute $ hackrf_info in the terminal, this is displayed:
Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1
Part ID Number: 0xa000cb3c 0x006c4757
Serial Number: 0x00000000 0x00000000 0x14d463dc 0x2f908de1
In the log section at the bottom in gnuradio-companion, HackRFOne is not displaying after debugging as an execute device.
Is there a problem with VID and PID of new versions and old hardware versions — for example statically hard-coded numbers in gnuradio-companion? D
I see this device:
Bus 002 Device 021: ID 1d50:6089 OpenMoko, Inc.
Where is the problem?
In the source code for GNU-Radio Companion, in which file/files can I edit information for detecting HackRFOne hardware?
Sorry, it's ok, I make upgrade from Fedora 20 to Fedora 21 and it's fine!
So, I've tried everything I can do right now, not really getting anywhere with this, so I am turning to the guys on SO for some assistance.
System Details:
Fedora 17 x86_64
Intel® Pentium(R) Dual CPU E2160 # 1.80GHz × 2
1.9 GiB memory
KCacheGrind 0.7.1
KDE Platform Version 4.9.4
Procedure Details:
I get an XDEBUG log from the server or from a Chrome Ext called Xdebug Helper. And I run it, either directly from the icon or from a Shell Script I created.
#!/bin/bash
export $(dbus-launch)
kcachegrind
And I get an error "No Profile Data Loaded"
Any ideas?
SORRY: error reads "(No function selected)"
Forgive me. I am a n00b at Linux and KCacheGrind.
I used root. Fixed. Adding 10 or more characters.