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
Related
My os is windows running on parallels Desktop app on Mac M2
When I Try to build the libraries I get this error
fatal error C1189: #error: "Byte order of target CPU unknown."
This is what I got in the console of VS when I finished installing
274>------ Build started: Project: ALL_BUILD, Configuration: Release ARM64 ------ 274>Building Custom Rule C:/VTK-9.2.2/src/CMakeLists.txt ========== Build: 157 succeeded, 117 failed, 0 up-to-date, 0 skipped ========== ========== Elapsed 11:48.565 ==========
If you are using an old (<2.8 cmake, this can be the issue): https://cmake.org/Bug/view.php?id=13808
In any case, you might try to set the byte-order manually in your cmake file:
set( CMAKE_CXX_BYTE_ORDER BIG_ENDIAN)
You could also check that CMAKE_OSX_ARCHITECTURES only specify one architecture or all architectures shares the same byte-order.
Seems like many people hit this and there seems to be no solution that I can find.
Follow exact instructions, downloaded precompiled libs, v 3.0.5 - latest stable build
set wxwin env var
make new 32bit empty project
copy the hello world app into new source file
set additional include
set preproc defintions -> UNICODE & _UNICODE on
set linker libs
build ->
1>------ Build started: Project: wxtest, Configuration: Debug Win32 ------
1>Source.cpp
1>c:\work\wxwin\include\wx\wxcrt.h(487): error C3861: 'wxStrcoll': identifier not found
1>c:\work\wxwin\include\wx\wxcrt.h(487): message : 'wxStrcoll': function was not declared in the template definition context and can be found only via argument-dependent lookup in the instantiation context
1>c:\work\wxwin\include\wx\wxcrt.h(496): message : see reference to function template instantiation 'int wxStrcoll_String<const wchar_t*>(const wxString &,const T &)' being compiled
1> with
1> [
1> T=const wchar_t *
1> ]
1>Done building project "wxtest.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Unfortunately you need to manually modify the header to fix the build with MSVS 2019 in 3.0.5 and remove defined(__VISUALC__) || part of the check before wxNEEDS_DECL_BEFORE_TEMPLATE definition in wx/wxcrt.h.
FWIW this problem was fixed since a long time (~6 years) in wx 3.1 and you can compile 3.1.3 or the soon to be released 3.1.4 out of the box with MSVS 2019.
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 have cross compiled my project in scratchbox, it uses :---
1> WX-widget base class (i.e uses socket, thread, string related classes..... no GUI stuff) (http://www.wxwidgets.org/)
2> Libwebsocket (http://libwebsockets.org/trac)
Compilation is successfull without error. Target is Debian Weezy & Processor is Raspberry pi.
Scratchbox uses QEmu for running cross executables.
When i run executable under sb2( scratchbox ). I get following error
x$ sb2 -e vscpd
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Exit reason and status: signal 11 (core dumped)
----------------- Qemu GDB log ------------------------
ignite#ignite:~/sbox2/rootfs/rfs-raspbian/home/pi/vscp_software/src/vscp/daemon/linux$ sb2 -t rfs-raspbian -eR gdb vscpd
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ignite/sbox2/rootfs/rfs-raspbian/home/pi/vscp_software/src/vscp/daemon/linux/vscpd...done.
===========================================================
Welcome to scratchbox2 enabled gdb!
Before starting target program you should run command
'sb2-prepare' that sets breakpoint which is used
to stop target before its main() gets called. After
the breakpoint is hit, you are able to set furtherbreakpoints and do normal debugging actions.
If you are attaching to already running process or
examining a core dump, this step is not necessary.
===========================================================
(sb2-emulate-gdb) sb2-prepare
Function "_dl_debug_state" not defined.
Temporary breakpoint 1 (_dl_debug_state) pending.
(sb2-emulate-gdb) run
Starting program: /home/ignite/sbox2/rootfs/rfs-raspbian/home/pi/vscp_software/src/vscp/daemon/linux/vscpd
qemu: Unsupported syscall: 26
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
qemu: Unsupported syscall: 26
During startup program terminated with signal SIGSEGV, Segmentation fault.
(sb2-emulate-gdb)
Please suggest this error is because of what ?
//Katoch
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.