Has anyone tried to port Mono to RTEMS

Sun Jul 23 22:44:46 UTC 2017

So I downloaded mono from git and changed to "mono-4.8.0-branch" branch and
ran ./autogen.sh. I had to install some tools and modify autogen.sh to work
on FreeBSD.

My commands are here: https://pastebin.com/y0XN7FDf
The output from autogen.sh is here: https://pastebin.com/zNVJB6qp

Note that my output is *much* different from yours. My system does NOT
check for the same items - notably your missing timezone item. Possibly for
one a few reasons that I could see: Different host operating system,
different compiler version or different compiler requirements. You won't
know unless you build for your host system first.

Anyway, I ran make. The whole thing fails on line 1. Ha ha!

root at rtems412:~/mono # gmake
Git submodules updated successfully
gmake  all-recursive
gmake[1]: Entering directory '/root/mono'
Making all in po
gmake[2]: Entering directory '/root/mono/po'
Making all in mcs
gmake[3]: Entering directory '/root/mono/po/mcs'
test ! -f ./mcs.pot || \
  test -z "es.gmo ja.gmo de.gmo pt_BR.gmo" || gmake es.gmo ja.gmo de.gmo
pt_BR.gmo
gmake[4]: Entering directory '/root/mono/po/mcs'
: --update  --lang=es es.po mcs.pot
rm -f es.gmo && : -c --statistics --verbose -o es.gmo es.po
mv: rename t-es.gmo to es.gmo: No such file or directory
gmake[4]: *** [Makefile:181: es.gmo] Error 1
gmake[4]: Leaving directory '/root/mono/po/mcs'
gmake[3]: *** [Makefile:218: stamp-po] Error 2
gmake[3]: Leaving directory '/root/mono/po/mcs'
gmake[2]: *** [Makefile:451: all-recursive] Error 1
gmake[2]: Leaving directory '/root/mono/po'
gmake[1]: *** [Makefile:535: all-recursive] Error 1
gmake[1]: Leaving directory '/root/mono'
gmake: *** [Makefile:465: all] Error 2

Your still a long way off from compiling, it still needs to clone a bunch
of packages and download binaries that it uses for bootstrapping the
builds. I would check autogen.sh against the rtems compilers but I'm still
unable to complete the RSB for FreeBSD reasons.

HTH
Russ

On Sun, Jul 23, 2017 at 8:40 AM, Joel Sherrill <joel at rtems.org> wrote:

> I would add that if you got far enough for the timezone probe to fail, you
> can try io compile that test code by hand. Then figure out which side is at
> fault. Maybe timezone as a variable is not required by POSIX so we don't
> have it. Then Mono needs adjustment. Maybe you need to add a -Dxxx to turn
> on optional features in the C Library.
>
> A port like this has to get the build working but then it is a series of
> small steps about issues like this.
>
>
>
> On Jul 23, 2017 10:35 AM, "Russell Haley" <russ.haley at gmail.com> wrote:
>
>> Did you run make? Did you get it to build? Lets slow down a sec:
>>
>> (Once again, I'm just another schmuck on the board, this is not rtems
>> position, but I'm interested in your work):
>>
>> The reason nobody can help you is because from what I can tell, nobodies
>> tried this yet. You need to get all the other parts in order before you
>> attempt something new. I know you don't want to here this (I hate hearing
>> it too!). That's what I had to do to get new drivers working in the FreeBSD
>> kernel, I had to stop, slow down and start with the basics and work back
>> up, and now I have an SSD working on my  IMX6 board! (I was trying to build
>> the whole image. I had to back up and started with the snapshot image from
>> the website, and then modified the kernel, then when back and compared my
>> image to the stock image to find what was wrong).
>>
>> So here's a thought. If you could record what you are doing and send the
>> instructions and the complete output then I would be able to a) see what
>> your running and b) try to follow along and reproduce what your attempting.
>> If you don't feel like sharing, that's fine, but currently nobody here has
>> much clarity into what you're doing or what you've done. None of  us are
>> able to follow along. If you write down each step you take in a document,
>> then  you (or us if you share it) can see what you have done and attempt to
>> reproduce it. When your running your commands, record your outputs at the
>> same time. I use "script /tmp/output.txt ... end"  or just cut and paste
>> into a document and then upload that to pastebin.com to share.
>>
>> A good indication of where you should direct your work output and
>> questions would be who's source code you are compiling (sometimes, I just
>> got a terse email from the lua maintainer about where a FreeBSD patch
>> should be applied. double entendre intended!). However:
>>
>> How did you build your compiler (it is assumed you used the rsb)?
>> Can you build rtems currently and link in a test application? Does it run
>> on your target?
>> Can you build mono separately with the default host compilers?
>> Can  you build mono separately and make it run on your target?
>> Can you build something simple like a little C program with the rtems
>> compilers you're using? Does it work with rtems?
>>
>> (IMHO) it would be good for you to organise your notes because you are
>> obviously smart and determined enough on this to perhaps get it done.
>>
>> SO, start from the beginning. Can you compile Mono for your host?
>>
>>
>>
>> On Sun, Jul 23, 2017 at 7:27 AM, xuelin.tian <xuelin.tian at qkmtech.com>
>> wrote:
>>
>>> In my thought, it is not just like the build environment like RSB, it is
>>> like everything... including mcs, CLR, and so on. And these should all be
>>> installed in RTEMS, so I tried to cross-compile it. I do not know if I am
>>> on the right path. How do I run (or install) these in RTEMS?
>>>
>>>
>>> ------------------ Original ------------------
>>> *From: * "Russell Haley"<russ.haley at gmail.com>;
>>> *Date: * Fri, Jul 21, 2017 01:09 PM
>>> *To: * "xuelin.tian"<xuelin.tian at qkmtech.com>;
>>> *Cc: * "Joel Sherrill"<joel at rtems.org>; "users"<users at rtems.org>;
>>> *Subject: * Re: Has anyone tried to port Mono to RTEMS
>>>
>>> This is just the configuration step. It's setting up your build
>>> environment akin to what ‎the rtems-source-builder sb-check does.
>>>
>>> It looks like your on the right path. It checked your compilers and
>>> verified it can use them.
>>>
>>> Russ
>>>
>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>> *From: *xuelin.tian at qkmtech.com
>>> *Sent: *Thursday, July 20, 2017 8:11 PM
>>> *To: *Russell Haley
>>> *Cc: *Joel Sherrill; users at rtems.org
>>> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>>>
>>> Sorry about some missing information.
>>> My host is ubuntu 14.4 (--host=x86_64-unknown-linux), and target is
>>> Zynq, ARM family (--target=arm-rtems4.11).
>>> I want to cross-compile Mono from source, downloaded from Github, the
>>> version is 4.8.1.0, not the HEAD.
>>>
>>> I think what you mean by build output is shown below:
>>> =================================================
>>> Running libtoolize...
>>> libtoolize: putting auxiliary files in `.'.
>>> libtoolize: copying file `./ltmain.sh'
>>> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
>>> libtoolize: copying file `m4/libtool.m4'
>>> libtoolize: copying file `m4/ltoptions.m4'
>>> libtoolize: copying file `m4/ltsugar.m4'
>>> libtoolize: copying file `m4/ltversion.m4'
>>> libtoolize: copying file `m4/lt~obsolete.m4'
>>> Running aclocal -I m4 -I .  ...
>>> Running autoheader...
>>> Running automake --gnu  ...
>>> Running autoconf ...
>>> Running libgc/autogen.sh ...
>>> Running libtoolize...
>>> libtoolize: putting auxiliary files in `.'.
>>> libtoolize: copying file `./ltmain.sh'
>>> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
>>> libtoolize: copying file `m4/libtool.m4'
>>> libtoolize: copying file `m4/ltoptions.m4'
>>> libtoolize: copying file `m4/ltsugar.m4'
>>> libtoolize: copying file `m4/ltversion.m4'
>>> libtoolize: copying file `m4/lt~obsolete.m4'
>>> Running aclocal  -Wnone ...
>>> Running automake --gnu  ...
>>> Makefile.am:32: error: Libtool library used but 'LIBTOOL' is undefined
>>> Makefile.am:32:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
>>> Makefile.am:32:   to 'configure.ac' and run 'aclocal' and 'autoconf'
>>> again.
>>> Makefile.am:32:   If 'LT_INIT' is in 'configure.ac', make sure
>>> Makefile.am:32:   its definition is in aclocal's search path.
>>> **Error**: automake failed.
>>> Done running libgc/autogen.sh ...
>>> Running eglib/autogen.sh ...
>>> Running libtoolize...
>>> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
>>> libtoolize: copying file `m4/libtool.m4'
>>> libtoolize: copying file `m4/ltoptions.m4'
>>> libtoolize: copying file `m4/ltsugar.m4'
>>> libtoolize: copying file `m4/ltversion.m4'
>>> libtoolize: copying file `m4/lt~obsolete.m4'
>>> Running aclocal -I m4  ...
>>> Running autoheader...
>>> Running automake --gnu  ...
>>> Running autoconf ...
>>> Skipping configure process.
>>> Done running eglib/autogen.sh ...
>>> Running ./configure --enable-maintainer-mode --enable-compile-warnings
>>> --prefix=/opt/Mono/mono-4.8.1.0/mono-arm --target=arm-rtems4.11
>>> --host=x86_64-unknown-linux CC=/opt/rtems-4.11.1-release/4
>>> .11-tools/bin/arm-rtems4.11-gcc CFLAGS=-qrtems
>>> -B/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/lib
>>> -B/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/
>>> -I//opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/include
>>> --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard
>>> -mtune=cortex-a9 ...
>>> checking build system type... x86_64-unknown-linux-gnu
>>> checking host system type... x86_64-unknown-linux-gnu
>>> checking target system type... arm-unknown-rtems4.11
>>> checking for a BSD-compatible install... /usr/bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for x86_64-unknown-linux-strip... no
>>> checking for strip... strip
>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>> checking for gawk... no
>>> checking for mawk... mawk
>>> checking whether make sets $(MAKE)... yes
>>> checking how to create a ustar tar archive... gnutar
>>> checking whether to enable maintainer-specific portions of Makefiles...
>>> yes
>>> checking whether ln -s works... yes
>>> checking whether make supports nested variables... yes
>>> checking host platform characteristics... ok
>>> checking for x86_64-unknown-linux-gcc... /opt/rtems-4.11.1-release/4.11
>>> -tools/bin/arm-rtems4.11-gcc
>>> checking for x86_64-unknown-linux-gcc... (cached)
>>> /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... yes
>>> checking for suffix of object files... o
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> accepts -g... yes
>>> checking for /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> option to accept ISO C89... none needed
>>> checking for style of include used by make... GNU
>>> checking dependency style of /opt/rtems-4.11.1-release/4.11
>>> -tools/bin/arm-rtems4.11-gcc... gcc3
>>> checking for x86_64-unknown-linux-g++... no
>>> checking for g++... g++
>>> configure: WARNING: using cross tools not prefixed with host triplet
>>> checking whether we are using the GNU C++ compiler... yes
>>> checking whether g++ accepts -g... yes
>>> checking dependency style of g++... gcc3
>>> checking dependency style of /opt/rtems-4.11.1-release/4.11
>>> -tools/bin/arm-rtems4.11-gcc... gcc3
>>> checking for gawk... (cached) mawk
>>> checking whether /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> and cc understand -c and -o together... yes
>>> checking how to run the C preprocessor... /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> -E
>>> checking for grep that handles long lines and -e... /bin/grep
>>> checking for egrep... /bin/grep -E
>>> checking for ANSI C header files... yes
>>> checking how to print strings... printf
>>> checking for a sed that does not truncate output... /bin/sed
>>> checking for fgrep... /bin/grep -F
>>> checking for ld used by /opt/rtems-4.11.1-release/4.11
>>> -tools/bin/arm-rtems4.11-gcc... /opt/rtems-4.11.1-release/4.11
>>> -tools/arm-rtems4.11/bin/ld
>>> checking if the linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld)
>>> is GNU ld... yes
>>> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
>>> checking the name lister (/usr/bin/nm -B) interface... BSD nm
>>> checking the maximum length of command line arguments... 1572864
>>> checking whether the shell understands some XSI constructs... yes
>>> checking whether the shell understands "+="... yes
>>> checking how to convert x86_64-unknown-linux-gnu file names to
>>> x86_64-unknown-linux-gnu format... func_convert_file_noop
>>> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
>>> format... func_convert_file_noop
>>> checking for /opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld
>>> option to reload object files... -r
>>> checking for x86_64-unknown-linux-objdump... objdump
>>> checking how to recognize dependent libraries... pass_all
>>> checking for x86_64-unknown-linux-dlltool... dlltool
>>> checking how to associate runtime and link libraries... printf %s\n
>>> checking for x86_64-unknown-linux-ar... no
>>> checking for ar... ar
>>> checking for archiver @FILE support... @
>>> checking for x86_64-unknown-linux-strip... strip
>>> checking for x86_64-unknown-linux-ranlib... no
>>> checking for ranlib... ranlib
>>> checking command to parse /usr/bin/nm -B output from
>>> /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc object... ok
>>> checking for sysroot... no
>>> checking for x86_64-unknown-linux-mt... no
>>> checking for mt... mt
>>> checking if mt is a manifest tool... no
>>> checking for sys/types.h... yes
>>> checking for sys/stat.h... yes
>>> checking for stdlib.h... yes
>>> checking for string.h... yes
>>> checking for memory.h... yes
>>> checking for strings.h... yes
>>> checking for inttypes.h... yes
>>> checking for stdint.h... yes
>>> checking for unistd.h... yes
>>> checking for dlfcn.h... yes
>>> checking for objdir... .libs
>>> checking if /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> supports -fno-rtti -fno-exceptions... no
>>> checking for /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> option to produce PIC... -fPIC -DPIC
>>> checking if /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> PIC flag -fPIC -DPIC works... yes
>>> checking if /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> static flag -static works... yes
>>> checking if /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> supports -c -o file.o... yes
>>> checking if /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> supports -c -o file.o... (cached) yes
>>> checking whether the /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld -m
>>> elf_i386) supports shared libraries... no
>>> checking dynamic linker characteristics... GNU/Linux ld.so
>>> checking how to hardcode library paths into programs... unsupported
>>> checking whether stripping libraries is possible... yes
>>> checking if libtool supports shared libraries... no
>>> checking whether to build shared libraries... no
>>> checking whether to build static libraries... yes
>>> checking how to run the C++ preprocessor... g++ -E
>>> checking for ld used by g++... /opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld
>>> -m elf_i386
>>> checking if the linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld
>>> -m elf_i386) is GNU ld... no
>>> checking whether the g++ linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld
>>> -m elf_i386) supports shared libraries... yes
>>> checking for g++ option to produce PIC... -fPIC -DPIC
>>> checking if g++ PIC flag -fPIC -DPIC works... yes
>>> checking if g++ static flag -static works... yes
>>> checking if g++ supports -c -o file.o... yes
>>> checking if g++ supports -c -o file.o... (cached) yes
>>> checking whether the g++ linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld
>>> -m elf_i386) supports shared libraries... yes
>>> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>>> checking how to hardcode library paths into programs... unsupported
>>> checking for bash... /bin/bash
>>> checking if dolt supports this host... yes, replacing libtool
>>> checking for ld used by /opt/rtems-4.11.1-release/4.11
>>> -tools/bin/arm-rtems4.11-gcc... (cached) /opt/rtems-4.11.1-release/4.11
>>> -tools/arm-rtems4.11/bin/ld
>>> checking if the linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld)
>>> is GNU ld... (cached) yes
>>> checking for ld used by GCC... /opt/rtems-4.11.1-release/4.11
>>> -tools/arm-rtems4.11/bin/ld
>>> checking if the linker (/opt/rtems-4.11.1-release/4.11-tools/arm-rtems4.11/bin/ld)
>>> is GNU ld... yes
>>> checking for shared library run path origin... done
>>> checking for iconv... yes
>>> checking for working iconv... guessing yes
>>> checking for iconv declaration...
>>>          extern size_t iconv (iconv_t cd, char * *inbuf, size_t
>>> *inbytesleft, char * *outbuf, size_t *outbytesleft);
>>> checking sys/filio.h usability... yes
>>> checking sys/filio.h presence... no
>>> configure: WARNING: sys/filio.h: accepted by the compiler, rejected by
>>> the preprocessor!
>>> configure: WARNING: sys/filio.h: proceeding with the compiler's result
>>> checking for sys/filio.h... yes
>>> checking sys/sockio.h usability... yes
>>> checking sys/sockio.h presence... no
>>> configure: WARNING: sys/sockio.h: accepted by the compiler, rejected by
>>> the preprocessor!
>>> configure: WARNING: sys/sockio.h: proceeding with the compiler's result
>>> checking for sys/sockio.h... yes
>>> checking netdb.h usability... no
>>> checking netdb.h presence... no
>>> checking for netdb.h... no
>>> checking utime.h usability... yes
>>> checking utime.h presence... yes
>>> checking for utime.h... yes
>>> checking sys/utime.h usability... yes
>>> checking sys/utime.h presence... yes
>>> checking for sys/utime.h... yes
>>> checking semaphore.h usability... yes
>>> checking semaphore.h presence... yes
>>> checking for semaphore.h... yes
>>> checking sys/un.h usability... no
>>> checking sys/un.h presence... no
>>> checking for sys/un.h... no
>>> checking linux/rtc.h usability... no
>>> checking linux/rtc.h presence... no
>>> checking for linux/rtc.h... no
>>> checking sys/syscall.h usability... no
>>> checking sys/syscall.h presence... no
>>> checking for sys/syscall.h... no
>>> checking sys/mkdev.h usability... no
>>> checking sys/mkdev.h presence... no
>>> checking for sys/mkdev.h... no
>>> checking sys/uio.h usability... yes
>>> checking sys/uio.h presence... no
>>> configure: WARNING: sys/uio.h: accepted by the compiler, rejected by the
>>> preprocessor!
>>> configure: WARNING: sys/uio.h: proceeding with the compiler's result
>>> checking for sys/uio.h... yes
>>> checking sys/param.h usability... yes
>>> checking sys/param.h presence... yes
>>> checking for sys/param.h... yes
>>> checking sys/sysctl.h usability... no
>>> checking sys/sysctl.h presence... no
>>> checking for sys/sysctl.h... no
>>> checking libproc.h usability... no
>>> checking libproc.h presence... no
>>> checking for libproc.h... no
>>> checking sys/prctl.h usability... no
>>> checking sys/prctl.h presence... no
>>> checking for sys/prctl.h... no
>>> checking for sys/param.h... (cached) yes
>>> checking sys/socket.h usability... no
>>> checking sys/socket.h presence... no
>>> checking for sys/socket.h... no
>>> checking sys/ipc.h usability... no
>>> checking sys/ipc.h presence... no
>>> checking for sys/ipc.h... no
>>> checking sys/utsname.h usability... yes
>>> checking sys/utsname.h presence... no
>>> configure: WARNING: sys/utsname.h: accepted by the compiler, rejected by
>>> the preprocessor!
>>> configure: WARNING: sys/utsname.h: proceeding with the compiler's result
>>> checking for sys/utsname.h... yes
>>> checking alloca.h usability... yes
>>> checking alloca.h presence... yes
>>> checking for alloca.h... yes
>>> checking ucontext.h usability... no
>>> checking ucontext.h presence... no
>>> checking for ucontext.h... no
>>> checking pwd.h usability... yes
>>> checking pwd.h presence... yes
>>> checking for pwd.h... yes
>>> checking sys/select.h usability... no
>>> checking sys/select.h presence... no
>>> checking for sys/select.h... no
>>> checking netinet/tcp.h usability... no
>>> checking netinet/tcp.h presence... no
>>> checking for netinet/tcp.h... no
>>> checking netinet/in.h usability... no
>>> checking netinet/in.h presence... no
>>> checking for netinet/in.h... no
>>> checking for unistd.h... (cached) yes
>>> checking for sys/types.h... (cached) yes
>>> checking link.h usability... yes
>>> checking link.h presence... no
>>> configure: WARNING: link.h: accepted by the compiler, rejected by the
>>> preprocessor!
>>> configure: WARNING: link.h: proceeding with the compiler's result
>>> checking for link.h... yes
>>> checking asm/sigcontext.h usability... no
>>> checking asm/sigcontext.h presence... no
>>> checking for asm/sigcontext.h... no
>>> checking sys/inotify.h usability... no
>>> checking sys/inotify.h presence... no
>>> checking for sys/inotify.h... no
>>> checking arpa/inet.h usability... no
>>> checking arpa/inet.h presence... no
>>> checking for arpa/inet.h... no
>>> checking complex.h usability... yes
>>> checking complex.h presence... yes
>>> checking for complex.h... yes
>>> checking unwind.h usability... yes
>>> checking unwind.h presence... yes
>>> checking for unwind.h... yes
>>> checking for linux/netlink.h... no
>>> checking for linux/rtnetlink.h... no
>>> checking for sys/user.h... no
>>> checking linux/serial.h usability... no
>>> checking linux/serial.h presence... no
>>> checking for linux/serial.h... no
>>> checking zlib.h usability... yes
>>> checking zlib.h presence... no
>>> configure: WARNING: zlib.h: accepted by the compiler, rejected by the
>>> preprocessor!
>>> configure: WARNING: zlib.h: proceeding with the compiler's result
>>> checking for zlib.h... yes
>>> Using system zlib
>>> checking elf.h usability... no
>>> checking elf.h presence... no
>>> checking for elf.h... no
>>> checking poll.h usability... no
>>> checking poll.h presence... no
>>> checking for poll.h... no
>>> checking sys/poll.h usability... yes
>>> checking sys/poll.h presence... no
>>> configure: WARNING: sys/poll.h: accepted by the compiler, rejected by
>>> the preprocessor!
>>> configure: WARNING: sys/poll.h: proceeding with the compiler's result
>>> checking for sys/poll.h... yes
>>> checking sys/wait.h usability... yes
>>> checking sys/wait.h presence... yes
>>> checking for sys/wait.h... yes
>>> checking grp.h usability... yes
>>> checking grp.h presence... yes
>>> checking for grp.h... yes
>>> checking syslog.h usability... no
>>> checking syslog.h presence... no
>>> checking for syslog.h... no
>>> checking wchar.h usability... yes
>>> checking wchar.h presence... yes
>>> checking for wchar.h... yes
>>> checking ieeefp.h usability... yes
>>> checking ieeefp.h presence... yes
>>> checking for ieeefp.h... yes
>>> checking for isinf... yes
>>> checking for _finite... no
>>> checking for _finite in math.h... no
>>> checking linux/magic.h usability... no
>>> checking linux/magic.h presence... no
>>> checking for linux/magic.h... no
>>> checking size of void *... 4
>>> checking for clang... no
>>> checking for -Wno-unused-but-set-variable option to gcc... yes
>>> checking whether NLS is requested... profile_default
>>> checking for msgfmt... /usr/bin/msgfmt
>>> checking for gmsgfmt... /usr/bin/msgfmt
>>> checking for xgettext... /usr/bin/xgettext
>>> checking for msgmerge... /usr/bin/msgmerge
>>> checking for pkg-config... /usr/bin/pkg-config
>>> checking for -mno-tls-direct-seg-refs option to gcc... no
>>> yes
>>> checking for visibility __attribute__... yes
>>> checking whether /opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>> supports zero length arrays... yes
>>> checking nacl/nacl_dyncode.h usability... no
>>> checking nacl/nacl_dyncode.h presence... no
>>> checking for nacl/nacl_dyncode.h... no
>>> checking signal.h usability... yes
>>> checking signal.h presence... yes
>>> checking for signal.h... yes
>>> checking for sigaction... yes
>>> checking for kill... yes
>>> checking for signal... yes
>>> checking for library containing clock_gettime... none required
>>> checking for clock_nanosleep... no
>>> checking for dlopen... yes
>>> checking for preceeding underscore in symbols... (cached) no
>>> checking for dlerror... yes
>>> checking execinfo.h usability... no
>>> checking execinfo.h presence... no
>>> checking for execinfo.h... no
>>> checking sys/auxv.h usability... no
>>> checking sys/auxv.h presence... no
>>> checking for sys/auxv.h... no
>>> checking sys/resource.h usability... yes
>>> checking sys/resource.h presence... yes
>>> checking for sys/resource.h... yes
>>> checking for getgrgid_r... yes
>>> checking for getgrnam_r... yes
>>> checking for getpwnam_r... yes
>>> checking for getpwuid_r... yes
>>> checking for getresuid... no
>>> checking for setresuid... no
>>> checking for kqueue... no
>>> checking for backtrace_symbols... no
>>> checking for mkstemp... yes
>>> checking for mmap... yes
>>> checking for madvise... no
>>> checking for getrusage... yes
>>> checking for getpriority... no
>>> checking for setpriority... no
>>> checking for dl_iterate_phdr... no
>>> checking for dladdr... no
>>> checking for sysconf... yes
>>> checking for getrlimit... no
>>> checking for prctl... no
>>> checking for sched_getaffinity... no
>>> checking for sched_setaffinity... no
>>> checking for sched_getcpu... no
>>> checking for sched_setaffinity from glibc < 2.3.4... yes
>>> checking if off_t is 64 bits wide... ok
>>> checking for socket in -lsocket... no
>>> checking for MSG_NOSIGNAL... no
>>> checking for IPPROTO_IP... no
>>> checking for IPPROTO_IPV6... no
>>> checking for IPPROTO_TCP... no
>>> checking for SOL_IP... no
>>> checking for SOL_IPV6... no
>>> checking for SOL_TCP... no
>>> checking for IP_PKTINFO... no
>>> checking for IPV6_PKTINFO... no
>>> checking for IP_DONTFRAG... no
>>> checking for IP_DONTFRAGMENT... no
>>> checking for IP_MTU_DISCOVER... no
>>> checking for IP_PMTUDISC_DO... no
>>> checking for struct ip_mreqn... no
>>> checking for struct ip_mreq... no
>>> checking for getaddrinfo... no
>>> checking for gethostbyname2_r... no
>>> checking for gethostbyname2... no
>>> checking for gethostbyname... no
>>> checking for getprotobyname... no
>>> checking for getnameinfo... no
>>> checking for inet_ntop... no
>>> checking for gethostbyaddr... no
>>> checking for gethostbyaddr in -lnsl... no
>>> checking for inet_pton... no
>>> checking for inet_aton... no
>>> checking for main in -lpthread... no
>>> checking pthread.h usability... yes
>>> checking pthread.h presence... yes
>>> checking for pthread.h... yes
>>> checking pthread_np.h usability... no
>>> checking pthread_np.h presence... no
>>> checking for pthread_np.h... no
>>> checking for pthread_mutex_timedlock... yes
>>> checking for pthread_getattr_np... yes
>>> checking for pthread_attr_get_np... no
>>> checking for pthread_setname_np... no
>>> checking for pthread_kill... yes
>>> checking for PTHREAD_MUTEX_RECURSIVE... ok
>>> checking for pthread_attr_setstacksize... yes
>>> checking for pthread_attr_getstack... yes
>>> checking for pthread_attr_getstacksize... yes
>>> checking for pthread_get_stacksize_np... no
>>> checking for pthread_get_stackaddr_np... no
>>> checking for mincore... no
>>> checking for working __thread... cross compiling
>>> checking for working sigaltstack... cross compiling
>>> checking for library containing sem_init... none required
>>> checking for library containing shm_open... no
>>> checking for shm_open... no
>>> checking for tm_gmtoff in struct tm... no
>>> checking for timezone variable... no
>>> configure: error: unable to find a way to determine timezone
>>> ===============================================
>>> I googled the time zone variable, and still working on it.
>>>
>>> But actually, I want to know whether I am doing it the right way? I
>>> mean, is this a right way to port Mono to RTEMS, just modifying some
>>> configuration options? I am still confusing about it.
>>>
>>> ------------------------------
>>> Best wishes,
>>> xuelin.tian at qkmtech.com
>>>
>>>
>>> *From:* Russell Haley <russ.haley at gmail.com>
>>> *Date:* 2017-07-21 10:42
>>> *To:* xuelin.tian at qkmtech.com
>>> *CC:* Joel Sherrill <joel at rtems.org>; users at rtems.org
>>> *Subject:* Re: Re: Has anyone tried to port Mono to RTEMS
>>>
>>> On Thu, Jul 20, 2017 at 7:07 PM, xuelin.tian at qkmtech.com <
>>> xuelin.tian at qkmtech.com> wrote:
>>>
>>>> I just followed the instructions from Mono, and did some changes
>>>> obviously.
>>>> I did not use ScratchBox to cross-compile my Mono on ARM, just use
>>>> arm-rtems4.11-gcc to cross-compile it. Is that right?
>>>> Do I need to modify the source code from Mono to port to RTEMS?
>>>>
>>> Some context you really should provide:
>>> - What platform are you building on?
>>> - Where did you get the source files? (if git, are you building head? I
>>> have had many problems building mono from head)
>>> - Without posting your complete build output there is no way to tell
>>> what is happening.
>>>
>>> This is just a shot in the dark, but did you google Time Zone variable?
>>> Google says you need to set a TZ environment variable.
>>>
>>> Russ
>>>
>>>> ------------------------------
>>>> Best wishes,
>>>> xuelin.tian at qkmtech.com
>>>>
>>>>
>>>> *From:* Russell Haley <russ.haley at gmail.com>
>>>> *Date:* 2017-07-21 00:16
>>>> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
>>>> <joel at rtems.org>
>>>> *CC:* users <users at rtems.org>
>>>> *Subject:* Re: Has anyone tried to port Mono to RTEMS
>>>> Did you get it to build natively?‎ What is your host. Build output
>>>> would be helpful.
>>>>
>>>> Russ
>>>>
>>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>>> *From: *xuelin.tian at qkmtech.com
>>>> *Sent: *Thursday, July 20, 2017 5:53 AM
>>>> *To: *Russell Haley; Joel Sherrill
>>>> *Cc: *users at rtems.org
>>>> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>>>>
>>>> I have been struck by it for like 2 days.
>>>> I want to cross-compile Mono for a test, and I enter:
>>>>
>>>> *./autogen.sh --prefix=/opt/Mono/mono-4.8.1.0/mono-arm
>>>> --target=arm-rtems4.11 --host=x86_64-unknown-linux
>>>> CC=/opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc
>>>> CFLAGS="-qrtems -B/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/lib
>>>> -B/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/
>>>> -I//opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/include
>>>> --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard
>>>> -mtune=cortex-a9"*
>>>>
>>>> It goes well at first, then the error came up:
>>>>
>>>> *checking for timezone variable... noconfigure: error: unable to find a
>>>> way to determine timezone*
>>>>
>>>> I can not really understand the content from config.log
>>>>
>>>> Can anyone help me with this? Thanks a lot
>>>>
>>>> ------------------------------
>>>> Best wishes,
>>>> xuelin.tian at qkmtech.com
>>>>
>>>>
>>>> *From:* Russell Haley <russ.haley at gmail.com>
>>>> *Date:* 2017-07-14 12:44
>>>> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
>>>> <joel at rtems.org>
>>>> *CC:* users <users at rtems.org>
>>>> *Subject:* Re: Has anyone tried to port Mono to RTEMS
>>>> Thinking about it, Lua is designed to be statically linked into C
>>>> applications and your scripts are loaded and executed by your application
>>>> at runtime. This is how lua is plugged into many video games like world or
>>>> warcraft and roblox.
>>>>
>>>> From my simplistic understanding of rtems (and everything I just said),
>>>> that would be the way you would statically link lua into rtems?
>>>>
>>>> Russ
>>>>
>>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>>> *From: *xuelin.tian at qkmtech.com
>>>> *Sent: *Thursday, July 13, 2017 9:03 PM
>>>> *To: *Russell Haley; Joel Sherrill
>>>> *Cc: *users at rtems.org
>>>> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>>>>
>>>> OK, thanks a lot.
>>>> I will go through Lua today, to see if there is something interesting
>>>> there.
>>>>
>>>> ------------------------------
>>>> Best wishes,
>>>> xuelin.tian at qkmtech.com
>>>>
>>>>
>>>> *From:* Russell Haley <russ.haley at gmail.com>
>>>> *Date:* 2017-07-14 11:57
>>>> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
>>>> <joel at rtems.org>
>>>> *CC:* users <users at rtems.org>
>>>> *Subject:* Re: Has anyone tried to port Mono to RTEMS
>>>> Just my opinion on the 'or other vm' comment.
>>>>
>>>> If your requirement is not strictly mono, I highly suggest something
>>>> small and simple like Lua. It's a a very efficient vm and is cross
>>>> compatible with all major platforms. The only requirement for Lua is c99.
>>>>
>>>> The language is very simple and bare bones. You pick your tools from
>>>> git or a repository manager called luarocks (luarocks.org). That's
>>>> where the 'hard part' of Lua comes in. It's very hands on because you need
>>>> to find or write almost everything you need.
>>>>
>>>> I am putting together a 'lightweight' IoT platform using Lua 5.3 and a
>>>> very sophisticated polling library called cqueues. There is an http library
>>>> called lua-http based on cqueues that contains a client and server
>>>> implementation of most major http standards including http2 and websockets.
>>>> The requirements for cqueues are a polling library such as epoll or kqueues
>>>> (or even poll or select). I'm not sure how well that would plug into rtems.
>>>> ‎At this point I'm cross compatible for most major Nixs' though.
>>>>
>>>> Nonetheless, the overhead of mono is not really worth it if you are
>>>> doing simple things. ‎That's why I switched away from DotNet for my
>>>> project. If you have code to port, or have DotNet developers, mono makes
>>>> sense.
>>>>
>>>> ‎Just my opinion.
>>>>
>>>> HTH
>>>> Russ
>>>>
>>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>>> *From: *xuelin.tian at qkmtech.com
>>>> *Sent: *Thursday, July 13, 2017 8:38 PM
>>>> *To: *Joel Sherrill; Russell Haley
>>>> *Cc: *users at rtems.org
>>>> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>>>>
>>>> Yes, I am trying to build it from source according to Russell.
>>>>
>>>> As to .net core, I may not have a deep understanding of it. I think for
>>>> now, Mono may be the best choice for me, since I need to make it (porting
>>>> Mono or other VM to rtems) work in a few days.
>>>>
>>>> ------------------------------
>>>> Best wishes,
>>>> xuelin.tian at qkmtech.com
>>>>
>>>>
>>>> *From:* Joel Sherrill <joel at rtems.org>
>>>> *Date:* 2017-07-13 01:08
>>>> *To:* Russell Haley <russ.haley at gmail.com>
>>>> *CC:* xuelin.tian at qkmtech.com; users at rtems.org
>>>> *Subject:* Re: Re: Has anyone tried to port Mono to RTEMS
>>>> The reply from Russell is very good advice. Look forward when porting
>>>> and
>>>> make sure you are porting something with a future.
>>>>
>>>> For Mono, I did exactly what he outlined. I built native. I recall it
>>>> using a
>>>> fairly normal configure script and I just added --target=XXX-rtems. I
>>>> might
>>>> have added some CFLAGS but don't recall.
>>>>
>>>> I focused on the run-time interpreter and ignored the JIT. The run-time
>>>> translated Mono calls into C library and POSIX calls. If there was a
>>>> compilation issue, I tried to fix it where ever it had to be fixed.
>>>> Always being
>>>> open to adding something to either RTEMS or newlib if possible
>>>> and needed.
>>>>
>>>> --joel
>>>>
>>>> On Wed, Jul 12, 2017 at 11:03 AM, Russell Haley <russ.haley at gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, Jul 11, 2017 at 9:31 PM, xuelin.tian at qkmtech.com
>>>>> <xuelin.tian at qkmtech.com> wrote:
>>>>> > Dear Joel,
>>>>> > Recently, I continue to port Mono to RTEMS.
>>>>> > Porting consists of two parts, according to the Mono documents
>>>>> online, JIT
>>>>> > engine and OS support.
>>>>> > JIT part is already done, since I use ARM platform.
>>>>> > And I am confuesd about OS part and how to build Mono on RTEMS.
>>>>> > Could you recall any details about how to build Mono on RTEMS? Thank
>>>>> you.
>>>>>
>>>>> I'm not sure that's quite right. There are really 3 parts: The
>>>>> application framework, the 'JIT' (Mono Runtime, or Common Language
>>>>> Runtime in Microsoft .Net) and the OS specific layer. The application
>>>>> framework and the JIT are common to all platforms. The OS specific
>>>>> parts are in the Mono Runtime where it translates the Interediate
>>>>> Language (IL) to machine specific code at ... er ... runtime. The Mono
>>>>> Runtime is being slowly replaced by the Roslyn compiler, which is open
>>>>> source from Microsoft (very very cool stuff).
>>>>>
>>>>> Building Mono requires a number of parts, including boot strapping the
>>>>> build and downloading binaries from nuget (last time I did it,
>>>>> anyway). I've never attempted to cross compile Mono. I would assume
>>>>> you would change the make file to point to a cross compiler such as
>>>>> arm-unknown-gcc (not sure about the RTEMS specifics).
>>>>>
>>>>> In my opinion the best bet is to pull the mono repository from GitHub
>>>>> and build it for your host platform first. Then you could look at
>>>>> modifying it to build on arm.
>>>>>
>>>>> That said, Mono is a dead/dying platform. Microsoft has bought
>>>>> Xamarian (Mono sponsor company). Now the Mono Dev Team is slowly
>>>>> porting everything over to the Microsoft .Net Core code. Once the
>>>>> majority of libraries are converted, they can then write Mono specific
>>>>> modules for legacy applications and then shuffle everyone over to
>>>>> DotNet Core. It might be wise to look at using the DotNet Core instead
>>>>> of Mono. There are a number of reasons to prefer the DotNet Core:
>>>>>
>>>>> - Designed to be small and use a package manager to import required
>>>>> external libraries. This was done with embedded systems in mind.
>>>>> - Better interpreter: the new interpreters (Rosylin and the other that
>>>>> I don't remember the name of) are very efficient compared to the Mono
>>>>> mc.
>>>>> - More efficient runtime. The Mono Runtime is known to be slow.
>>>>>
>>>>> Here would be a good place to start with the DotNet Core as they have
>>>>> nightly arm builds.
>>>>>
>>>>> https://stevedesmond.ca/blog/net-core-on-arm
>>>>>
>>>>>
>>>>> HTH,
>>>>>
>>>>> Russ
>>>>>
>>>>> > ________________________________
>>>>> > Best wishes,
>>>>> > xuelin.tian at qkmtech.com
>>>>> >
>>>>> >
>>>>> > From: Joel Sherrill
>>>>> > Date: 2017-05-24 20:19
>>>>> > To: xuelin.tian
>>>>> > CC: rtems-users at rtems.org
>>>>> > Subject: Re: Has anyone tried to port Mono to RTEMS
>>>>> >
>>>>> >
>>>>> > On May 23, 2017 8:58 PM, "xuelin.tian at qkmtech.com" <
>>>>> xuelin.tian at qkmtech.com>
>>>>> > wrote:
>>>>> >
>>>>> > Dear all,
>>>>> > Is that possible to port Mono to RTEMS? Has anyone tried this before?
>>>>> > As I notice that there is an open project in RTEMS projects.
>>>>> >
>>>>> >
>>>>> > Sometime ago, I was asked to provide an estimate for this. It had to
>>>>> be
>>>>> > between five and ten years ago because we were at the old office but
>>>>> after
>>>>> > we had done a few years of GSoC. I did enough work preparing the
>>>>> estimate
>>>>> > where I had the code building without too much effort. I saw the
>>>>> challenge
>>>>> > as getting the test suite running since you would have to create a
>>>>> test
>>>>> > harness and build/assembly helper that packaged the interpreted code
>>>>> with
>>>>> > the interpreter in order to run it. At that time, I envisioned
>>>>> having to
>>>>> > create a base image and a filesystem image per test.
>>>>> >
>>>>> > Our POSIX was good enough then to avoid much trouble. It should only
>>>>> be
>>>>> > easier now since the POSIX support has improved.
>>>>> >
>>>>> > There were a lot of Mono tests and I expected most to pass quickly.
>>>>> But
>>>>> > there was no way to know how many issues would be encountered and
>>>>> how many
>>>>> > root causes there would be. I expected to fix one or two things and
>>>>> then run
>>>>> > all the tests. That was where I expected time to be consumed.
>>>>> >
>>>>> > FWIW I recall the GSoC date part because they thought we could
>>>>> magically get
>>>>> > students to do testing for free on a schedule. :)
>>>>> >
>>>>> > I hope that helps. It is feasible but the key is testing.
>>>>> >
>>>>> > --joel
>>>>> >
>>>>> >
>>>>> > ________________________________
>>>>> > Best wishes,
>>>>> > xuelin.tian at qkmtech.com
>>>>> >
>>>>> > _______________________________________________
>>>>> > users mailing list
>>>>> > users at rtems.org
>>>>> > http://lists.rtems.org/mailman/listinfo/users
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > users mailing list
>>>>> > users at rtems.org
>>>>> > http://lists.rtems.org/mailman/listinfo/users
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> 自动判断 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语
>>> 丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语
>>> 冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语
>>> 北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语
>>> 茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语 自动选择 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语
>>> 俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语
>>> 加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语
>>> 拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语
>>> 斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语
>>> 班图语祖鲁语 有道翻译 百度翻译 必应翻译 谷歌翻译 谷歌翻译（国内） 翻译 朗读 复制 正在查询，请稍候…… 重试 朗读 复制 复制 朗读
>>> 复制 via 译
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170723/f873d93e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0F4A8637 at D1878C7A.38B27459
Type: application/octet-stream
Size: 56875 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20170723/f873d93e/attachment-0001.obj>