$ glxinfo32
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig
I found this from steam "glxChooseVisual failed".
$ steam
...
glXChooseVisual failed
glXChooseVisual failedsrc/steamUI/Main.cpp (409) : Assertion Failed: Fatal Error: glXChooseVisual failed
glxinfo32 and other 32bit demos didn't work, but 64bit demos worked.
$ glinfo
GL_VERSION: 4.6 (Compatibility Profile) Mesa 21.3.3
GL_RENDERER: AMD RENOIR (DRM 3.42.0, 5.15.13-arch1-1, LLVM 13.0.0)
GL_VENDOR: AMD
...
$ glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
...
Here are some other errors.
$ glinfo32
freeglut (glinfo32): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow
I learnt that mesa 11.x.y causes segfault but mine is 21.3.3.
$ glxgears_fbconfig32
zsh: segmentation fault (core dumped) glxgears_fbconfig32
I tried to reinstall mesa and other libs.
$ pacman -Qs mesa
local/glu 9.0.2-1
Mesa OpenGL Utility library
local/lib32-glu 9.0.2-1
Mesa OpenGL utility library (32 bits)
local/lib32-mesa 21.3.3-1
An open-source implementation of the OpenGL specification (32-bit)
local/lib32-mesa-demos 8.4.0-3
Mesa demos (32-bit)
local/lib32-mesa-utils 8.4.0-3
essential Mesa utilities (32-bit)
local/lib32-opencl-mesa 21.3.3-1
OpenCL support for AMD/ATI Radeon mesa drivers (32-bit)
local/mesa 21.3.3-2
An open-source implementation of the OpenGL specification
local/mesa-demos 8.4.0-6
Mesa demos
local/mesa-utils 8.4.0-6
essential Mesa utilities
local/opencl-mesa 21.3.3-2
OpenCL support for AMD/ATI Radeon mesa drivers
Not sure if this will help you, but I had lib32-libdrm-git and libdrm installed, which appeared to have different versions (2.4.109-1 and 2.4.66-1).
Try re-installing libdrm and lib32-libdrm.
Do you use a custom built llvm and not the standard-shipped-one? Seems that your lib32-mesa can't find fbconfig.
Related
I compile a macOS driverkit system extension as a Universal library so that it contains both x86_64 and arm64. One Apple Silicon computer A the driver starts when I attach the USB device. On Apple Silicon computer B I can see kernel: exec_mach_imgact: disallowing arm64 platform driverkit binary "com.example.driver", should be arm64e being printed in the Console.app when the USB device is attached. I've looked at the source code
of where this is happening but I cannot figure out what the problem is.
If I compile it for arm64e then it get exec_mach_imgact: not running binary "com.example.driver" built against preview arm64e on computer A, bit then it starts on computer B.
None of the computers have -arm64e_preview_abi set in the boot-args.
If I create a new Xcode (12.4) project on each machine and build Release then computer A and otool -fvv com.example.driver gives
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 73856
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 98304
size 73856
align 2^14 (16384)
On computer B the same command gives
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 73280
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 98304
size 73296
align 2^14 (16384)
How can I make the driver start on both machines?
Dexts should indeed be arm64 and x86_64 (but as pmdj explains, system binaries are still arm64e.)
As hinted by the name of (and need for) the -arm64e_preview_abi, arm64e is currently only exposed as a developer preview, to allow for testing.
However, you shouldn't get the disallowing arm64 error: did you set other interesting boot-args on computer B? (in particular, amfi= may be relevant)
My experience so far indicates that arm64e is the correct and only correct Apple Silicon architecture to use for dexts.
For one, there's the "disallowing arm64 platform" error, and also Apple's own DriverKit based drivers are built for arm64e:
% otool -fvv /System/Library/DriverExtensions/com.apple.AppleUserHIDDrivers.dext/com.apple.AppleUserHIDDrivers
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 96208
align 2^14 (16384)
architecture arm64e
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64E
capabilities CPU_SUBTYPE_ARM64E_PTRAUTH_VERSION 0
offset 114688
size 95312
align 2^14 (16384)
That leaves the question of why your arm64e build isn't working. The "built against preview arm64e" error suggests the problem isn't with the computer but the binary. Are you using identical binaries on the 2 systems? Perhaps one has SIP disabled, so it's more permissive of badly built binaries?
Have you tried a "hello world" style dext, in a freshly created project on the latest version of Xcode? Check that runs natively on both machines. Once that's working, compare Xcode's compiler and linker command lines with those from your build script - or if you're also using Xcode, compare your target's build settings with the "clean" one.
I am working on Phytec based custom board, While porting Phytec BSP from krogoth to thud, I am unable to use gpu based rendering.
Krogoth:
Display -> imx-drm
libegl provider -> imx-gpu-viv
Thud:
Display -> imx-drm
libegl provider -> mesa
I am using one GUI application which requires egl library. It is throwing below error
INFO [0.747]:GLES 2.0: initialize native API
INFO [0.748]:GLES 2.0: Initialize EGL display
WARN [0.749]:eglGetDisplay: failed.
ERROR [0.749]:Can't initialize the display
Please explain GPU driver relation with mesa and imx-gpu-viv and application to use it.
I recently passed from Pyro to Warrior on an iMX6 CPU, and I had some trouble with the GPU. The driver was not compiled at all, and the Gstreamer GPU plugins were not working. It finally worked with the following configuration:
I added to my local.conf (or machine.conf) the line:
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-module-imx-gpu-viv"
I also added the GPU config on my kernel defconfig:
CONFIG_MXC_GPU_VIV=m
Hope it helps.
I'm trying to run the mono profiler, however, I'm not getting any profiler output or error messages.
If I run mono --profile=log program.exe the program runs as expected and there are no error messages, yet there is no output.mlpd file.
I have the profiler libs installed and visible:-
# ldconfig -p | grep libmono-profiler
libmono-profiler-log.so.0 (libc6,hard-float) => /usr/lib/libmono-profiler-log.so.0
libmono-profiler-coverage.so.0 (libc6,hard-float) => /usr/lib/libmono-profiler-coverage.so.0
libmono-profiler-aot.so.0 (libc6,hard-float) => /usr/lib/libmono-profiler-aot.so.0
I've tried using mono-sgen and just about every example of profiler options I could find, and nothing changes.
Changing the profiler to something invalid, like mono --profile=meh program.exe has the same result (program runs, no error message, no profiler output)
I've tried on two different machines (Yocto Thud and Ubuntu 18.04.2)
Mono JIT compiler version 5.18.0.268 (tarball Fri Jun 28 03:01:54 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: normal
Notifications: epoll
Architecture: armel,vfp+hard
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
Suspend: preemptive
GC: sgen (concurrent by default)
Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(600)
Suspend: hybrid
GC: sgen (concurrent by default)
This used to work in previous versions of mono in these environments, however, it's non-trivial to roll back and test.
UPDATE
I've managed to resolve this on some platforms (Ubuntu) with the installation of the mono-profiler package.
This package provides the following files:-
/.
/usr
/usr/bin
/usr/bin/emveepee
/usr/bin/mprof-decoder
/usr/bin/mprof-heap-viewer
/usr/lib
/usr/lib/mono-tools
/usr/lib/mono-tools/Mono.Profiler.Widgets.dll
/usr/lib/mono-tools/emveepee.exe
/usr/lib/mono-tools/mprof-decoder-library.dll
/usr/lib/mono-tools/mprof-decoder.exe
/usr/lib/mono-tools/mprof-heap-snapshot-explorer.dll
/usr/lib/mono-tools/mprof-heap-viewer.exe
/usr/share
/usr/share/doc
/usr/share/doc/mono-profiler
/usr/share/doc/mono-profiler/changelog.Debian.gz
/usr/share/doc/mono-profiler/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/mprof-decoder.1.gz
/usr/share/man/man1/mprof-heap-viewer.1.gz
These appear to be just tools for dealing with profile output. It's not clear which of these files "enables" /usr/bin/mono to actually capture profile data, or why mono is not reporting an error that required files(?) are not present.
The /usr/lib/libmono-profiler-*.so files were already on these platforms (prior to installing mono-profiler)
The remaining platform to resolve is Yocto Thud on ARM. With no package available as with Ubuntu, and no error message, it's difficult to tell what's missing that might be causing this issue.
The solution for Ubuntu was to install the mono-profiler package.
The issue on Yocto Thud was that /usr/lib/libmono-profiler-log.so.0 was present, however, mono looks for /usr/lib/libmono-profiler-log.so (determined using strace) which was not symlinked to /usr/lib/libmono-profiler-log.so.0.
The fact that mono doesn't report this as an error appears to be a bug.
I've been trying to build Mono 3.2.3 on Solaris 11 with no luck. I've made a few minor code changes and turned off configuration features to get to this point but now I'm stuck with mono crashing while trying to build System.dll. Any ideas?
MONO_PATH="./../../class/lib/basic:$MONO_PATH" /home/axsadm/mono-3.2.3/runtime/mono-wrapper ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
+ r=/home/axsadm/mono-3.2.3
+ MONO_CFG_DIR=/home/axsadm/mono-3.2.3/runtime/etc
+ PATH=/home/axsadm/mono-3.2.3/runtime/_tmpinst/bin:/usr/bin:/usr/sbin
+ MONO_SHARED_DIR=/home/axsadm/mono-3.2.3/runtime
+ export MONO_CFG_DIR MONO_SHARED_DIR PATH
+ [ -n '' ]
+ exec /home/axsadm/mono-3.2.3/libtool '--mode=execute' /home/axsadm/mono-3.2.3/mono/mini/mono --config /home/axsadm/mono-3.2.3/runtime/etc/mono/config ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
* Assertion at threads.c:1001, condition `info' not met
Native stacktrace:
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_handle_native_sigsegv+0x1b8 [0x187c58]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'sigabrt_signal_handler+0xa0 [0x1ed97c]
/lib/libc.so.1'__sighndlr+0xc [0xff0254f0]
/lib/libc.so.1'call_user_handler+0x370 [0xff018e50]
/lib/libc.so.1'sigacthandler+0x58 [0xff019040]
/lib/libc.so.1'_lwp_kill+0x8 [0xff029fa0]
/lib/libc.so.1'abort+0xc8 [0xfefaac2c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_g_logv+0x174 [0x3d5454]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_assertion_message+0x38 [0x3d54e8]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach_full+0x2bc [0x2dc650]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach+0x10 [0x2dc37c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_runtime_init+0x23c [0x314034]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mini_init+0x1a60 [0x77158]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main+0x232c [0x1457a4]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main_with_options+0x48c [0x5fa30]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'main+0x2c [0x5fa74]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'_start+0x5c [0x5f3e4]
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
gmake[8]: *** [../../class/lib/build/tmp/System.dll] Abort (core dumped)
Configuration:
Engine:
GC: included Boehm
TLS: pthread
SIGALTSTACK: no
Engine: Building and using the JIT
oprofile: no
BigArrays: no
DTrace: no
LLVM Back End: no (dynamically loaded: no)
Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes
MonoDroid: no
MonoTouch: no
JNI support: IKVM Native
libgdiplus: assumed to be installed
zlib: system zlib
This might be a bit late, but for me I had more luck using the external Boehm GC as opposed to the bundled/included one.
./autogen.sh --prefix=/usr --disable-dtrace --with-sgen=no --with-gc=boehm
This seemed to work OK for Solaris 10 and 11 on Intel. I'm still working on SPARC!
Good luck,
Steve
I am trying to cross-compile Mono framework (3.0.6) for MIPS platform. There are few issues I have found so I would like to ask the community whether there are known or not.
My environment: Linux 3.2.0-39-generic #62-Ubuntu SMP Thu Feb 28 00:28:53 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Toolchain: Sourcery G++ Lite 4.3-51
command-line:
./configure --prefix=/home/dev/mono-3.0.6-mips --host=mips-linux-gnu --enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs --target=mips-linux-gnu --with-moonlight=no --with-tls=pthread --with-sigaltstack=no --with-profile4_5=yes CXXFLAGS="-mips32r2 -march=24kf -mtune=24kf -EL" CFLAGS="-mips32r2 -march=24kf -mtune=24kf -EL" && make
Issue #1:
When I managed it to configure, compilation stopped with the following error:
mini-gc.c:2551: error: redefinition of 'mini_gc_enable_gc_maps_for_aot'
mini-gc.c:2518: error: previous definition of 'mini_gc_enable_gc_maps_for_aot' was here
Issue #2:
After I commented out the second declaration of mini_gc_enable_gc_maps_for_aot it compiled but looks like Sourcery G++ linker crashed:
/home/dev/mips-4.3/bin/../lib/gcc/mips-linux-gnu/4.3.2/../../../../mips-linux-gnu/bin/ld: BFD (Sourcery G++ Lite 4.3-51) 2.18.50.20080215 assertion fail /scratch/clm/2008q3-lite/obj/binutils-src-4.3-51-mips-linux-gnu-i686-pc-linux-gnu/bfd/elfxx-mips.c:2651
Could anyone led some light to this problem? I failed to find any articles/info describing building Mono for MIPS architecture (at least some recent information). According to this link, support for MIPS was added about a year ago. Mono itself should fully support MIPS since 3.0.4 version.
I am posting this info for everyone else who will struggle with the same problem (building Mono for MIPS platform):
At last I was able to build mono runtime for MIPS platform using the following command line:
./configure --prefix=/home/dev/mono-3.0.6-mips --host=mips-linux-gnu --enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs --target=mips-linux-gnu --with-moonlight=no --with-tls=pthread --with-sigaltstack=no --with-profile4_5=yes CXXFLAGS="-mips32r2 -EL" CFLAGS="-mips32r2 -EL" LDFLAGS=-EL CPPFLAGS="-mips32r2 -EL" ASFLAGS=-EL CC="mips-linux-gnu-gcc -EL"
Specifying -EL flag for all the tools fixed issue with mono linking using ld (see Issue #2 in my initial post).
The last issue left is to make the mono build system to build mscorlib.dll. Invoking different make commands inside mcs/class folder doesn`t do anything.