Cross compiling Mono framework 3.0.6+ for MIPS - mono

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.

Related

Mono profiler not running

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.

Android Gradle - Gitlab CI - Docker - CMake - NullPointerException

I'm trying to get simple Android Unit Tests to run on Gitlab CI, but I'm having troubles getting things to build correctly in the CI Docker image. I have the master project which pulls from a Library project. The Library has C code in it, so I need to use CMake to get it to build. All of this is working locally on my windows machine when using Android Studio. However, once I move to the CI server, things break with the following error:
Using incremental javac compilation for :Library debug.
Incremental java compilation is an incubating feature.
Checking the license for package CMake 3.6.3155560 in /android-sdk-linux/licenses
License for package CMake 3.6.3155560 accepted.
Preparing "Install CMake 3.6.3155560 (revision: 3.6.3155560)".
"Install CMake 3.6.3155560 (revision: 3.6.3155560)" ready.
Finishing "Install CMake 3.6.3155560 (revision: 3.6.3155560)"
Installing CMake 3.6.3155560 in /android-sdk-linux/cmake/3.6.3155560
"Install CMake 3.6.3155560 (revision: 3.6.3155560)" complete.
"Install CMake 3.6.3155560 (revision: 3.6.3155560)" finished.
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':Library'.
> java.lang.NullPointerException (no error message)
* Try:
Run with --debug option to get more log output.
* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':Library'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:94)
at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:89)
...
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
Caused by: java.lang.NullPointerException
at com.android.builder.sdk.DefaultSdkLoader.installSdkTool(DefaultSdkLoader.java:572)
at com.android.build.gradle.internal.SdkHandler.installCMake(SdkHandler.java:302)
at com.android.build.gradle.tasks.ExternalNativeJsonGenerator.create(ExternalNativeJsonGenerator.java:628)
at com.android.build.gradle.internal.TaskManager.createExternalNativeBuildJsonGenerators(TaskManager.java:1241)
at com.android.build.gradle.internal.LibraryTaskManager.lambda$createTasksForVariantData$11(LibraryTaskManager.java:240)
...
at com.sun.proxy.$Proxy15.afterEvaluate(Unknown Source)
at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:82)
... 56 more
BUILD FAILED
Total time: 1 mins 25.384 secs
Stopped 0 worker daemon(s).
Received result Failure[value=org.gradle.initialization.ReportedException: org.gradle.internal.exceptions.LocationAwareException: A problem occurred configuring project ':Library'.] from daemon DaemonInfo{pid=39, address=[1f3b75f9-7080-48b5-b298-0e6136640a0a port:41964, addresses:[/127.0.0.1]], state=Busy, lastBusy=1496784783851, context=DefaultDaemonContext[uid=0e3eadf0-a7bd-4ede-9eb8-0c2a96ebef58,javaHome=/usr/lib/jvm/java-8-openjdk-amd64,daemonRegistryDir=/root/.gradle/daemon,pid=39,idleTimeout=10800000,daemonOpts=-Xmx1536m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en, -Duser.variant]} (build should be done).
ERROR: Job failed: exit code 1
Judging by the line
Caused by: java.lang.NullPointerException
at com.android.builder.sdk.DefaultSdkLoader.installSdkTool(DefaultSdkLoader.java:572)
at com.android.build.gradle.internal.SdkHandler.installCMake(SdkHandler.java:302)
it looks like it is a problem with the CMake. But it looks like it is installed and the licence is accepted as noted by the output at the start of that block above.
Can anyone give me some pointers on what is the problem?
* Is it that gradle doesn't know where CMake was installed?
* Is it a problem perhaps with the NDK?
* Or perhaps where I can find the source code for com.android.build.gradle.internal.SdkHandler.installCMake and com.android.builder.sdk.DefaultSdkLoader.installSdkTool.
My searches have been unfruitful.
I can provide more about my setup upon request. (i.e. android project, docker image, gitlab-ci.yml, etc.)
Well, mbertin commented on Feb 2 at here that by using a lower gradle build tool, it solved the problem for him. (i.e. classpath 'com.android.tools.build:gradle:2.2.2).
After giving it an attempt, my build script got passed that error! (anyone know why?)
Thanks for the emotional support Stack Overflow! You are the best!

linuxbrew installed cmake on a cluster cannot find lib in /usr/lib64

I'm trying to build caffe on a GGPU cluster. I've installed a lot of dependencies in a subfolder of my home using linuxbrew. One of those dependencies is an updated version of cmake(needed).
When i launch the command
cmake ..
i get this output
-- Boost version: 1.59.0
-- Found the following Boost libraries:
-- system
-- thread
-- filesystem
-- Found gflags (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libgflags.so)
-- Found glog (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libglog.so)
-- Found PROTOBUF Compiler: /home/cgvg/.linuxbrew/bin/protoc
-- Found lmdb (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/liblmdb.a)
-- Found LevelDB (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libleveldb.so)
-- Found Snappy (include: /home/cgvg/.linuxbrew/include, library: /home/cgvg/.linuxbrew/lib/libsnappy.so)
-- CUDA detected: 7.5
-- Automatic GPU detection failed. Building for all known architectures.
-- Added CUDA NVCC flags for: sm_20 sm_21 sm_30 sm_35 sm_50
-- OpenCV found (/home/cgvg/sottile/opencv/share/OpenCV)
CMake Error at /home/cgvg/.linuxbrew/Cellar/cmake/3.4.1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find Atlas (missing: Atlas_LAPACK_LIBRARY)
Call Stack (most recent call first):
/home/cgvg/.linuxbrew/Cellar/cmake/3.4.1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindAtlas.cmake:42 (find_package_handle_standard_args)
cmake/Dependencies.cmake:88 (find_package)
CMakeLists.txt:38 (include)
-- Configuring incomplete, errors occurred!
See also "/home/cgvg/sottile/caffe/build/CMakeFiles/CMakeOutput.log".
See also "/home/cgvg/sottile/caffe/build/CMakeFiles/CMakeError.log".
and it seems there is nothing i can do to link the ATLAS libs correctly.
The missing libs are under
/usr/lib64/atlas-sse3
Is it possible that there exists a limitation such that my linuxbrewed cmake cannot link to upper folders?
In the error message it says that:
cmake/Modules/FindAtlas.cmake:42
I tried to modify that file adding the correct paths:
set(Atlas_INCLUDE_SEARCH_PATHS
/usr/include
$ENV{Atlas_ROOT_DIR}
$ENV{Atlas_ROOT_DIR}/include
)
set(Atlas_LIB_SEARCH_PATHS
/usr/lib64/atlas
/usr/lib64/atlas-sse3
$ENV{Atlas_ROOT_DIR}
$ENV{Atlas_ROOT_DIR}/lib
)
and nothing happened.
i tried to change the PATH and LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/atlas-sse3
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/include/atlas-x86_64-base-sse3/
and nothing happened.
I'm not a linux veteran so i apologize if i missed some important information. Any suggestion is appreciated.
EDIT:
this is the content of /usr/lib64/atlas3-sse3:
libatlas.a libcblas.so.3.0 libf77blas.so.3.0 libptcblas.so.3
libatlas.so libclapack.so liblapack.a libptcblas.so.3.0
libatlas.so.3 libclapack.so.3 liblapack.so libptf77blas.a
libatlas.so.3.0 libclapack.so.3.0 liblapack.so.3 libptf77blas.so
libcblas.a libf77blas.a liblapack.so.3.0 libptf77blas.so.3
libcblas.so libf77blas.so libptcblas.a libptf77blas.so.3.0
libcblas.so.3 libf77blas.so.3 libptcblas.so
libatlas.a libcblas.so.3.0 libf77blas.so.3.0 libptcblas.so.3
libatlas.so libclapack.so liblapack.a libptcblas.so.3.0
libatlas.so.3 libclapack.so.3 liblapack.so libptf77blas.a
libatlas.so.3.0 libclapack.so.3.0 liblapack.so.3 libptf77blas.so
libcblas.a libf77blas.a liblapack.so.3.0 libptf77blas.so.3
libcblas.so libf77blas.so libptcblas.a libptf77blas.so.3.0
libcblas.so.3 libf77blas.so.3 libptcblas.so
It seems that lapack is bundled in atlas, for this reason FindAtlas.cmake is not able to find alapack_r, alapck or lapack_atlas.
It is enough to edit caffe_folder/cmake/Module/FindAtlas.cmake, look for Atlas_LAPACK_LIBRARY NAMES and add clapack to the list of libs.
It completely solve the problem.

SIGABRT while building mono on Solaris

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

Issues with running nunit-console.exe with Mono

I could make a dll for NUnit NUnit test under mono, but when I tried to run in with nunit-console.exe I get the following error message.
Runtime Environment -
OS Version: Unix 10.3.0.0
CLR Version: 2.0.50727.1433 ( 2.6.4 (tarball Thu Apr 22 13:24:33 MDT 2010) )
ProcessModel: Default DomainUsage: Single
Execution Runtime: mono-2.0
** (/Users/smcho/bin/NUnit-2.5.5.10112/bin/net-2.0/nunit-console.exe:36800): WARNING **: The following assembly referenced from /private/var/folders/m4/m4u1hmP+FHOQaiZbHj1UCk+++TI/-Tmp-/nunit20/ShadowCopyCache/36800_634111616836311880/Tests_-22323139/assembly/shadow/54274fc2/118e035c_45a94c9e_00000001/mut.dll could not be loaded:
Assembly: nunit.framework (assemblyref_index=1)
Version: 2.5.5.10112
Public Key: 96d09a1eb7f44a77
System error: Invalid argument
** (/Users/smcho/bin/NUnit-2.5.5.10112/bin/net-2.0/nunit-console.exe:36800): WARNING **: Could not load file or assembly 'nunit.framework, Version=2.5.5.10112, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies.
What might be wrong? I have nunit.framework.dll under /Users/smcho/bin/NUnit-2.5.5.10112/bin/net-2.0/framework, but it doesn't seem to know about this.
This is another frustrating point about using NUnit in Mono. As far as I've been able to tell, you need to have all of those missing files (there will be more than just nunit.framework.dll) in the same directory as nunit-console.exe.
There might be a command line option either in mono or nunit-console.exe to specify another directory to search for missing DLLs -- I'm not sure. Barring that, you'll have to copy the missing DLLs into the same folder as nunit-console.exe, or you'll have to cd into the framework folder and use mono ../nunit-console.exe /path/to/my/tests.dll
Once nuget is installed, you can use it to install nunit.console like so:
(This is from my .circlci/config.yml file)
- run: mono --runtime=v4.0 nuget.exe install nunit.console
- run: msbuild MySolution.sln
- run: mono --runtime=v4.0 NUnit.ConsoleRunner.3.12.0/tools/nunit3-console.exe FirstModule.Tests/bin/Debug/FirstModule.Tests.dll
- run: mono --runtime=v4.0 NUnit.ConsoleRunner.3.12.0/tools/nunit3-console.exe SecondModule.Tests/bin/Debug/SecondModule.Tests.dll
The trick is to specify the entire path for the NUnit.ConsoleRunner and to watchout for the - changing into a . by version 3