RTEMS 4.11 build fails for sparc-leon3 with multilib enabled

Joel Sherrill joel at rtems.org
Thu Mar 31 23:29:09 UTC 2016

On Thu, Mar 31, 2016 at 3:06 PM, Thibaud Backenstrass <
thibaud.backenstrass at phelma.grenoble-inp.fr> wrote:

> *Élève-ingénieur - Grenoble INP-Phelma - 3A SLE*
> E-mail : thibaud.backenstrass at phelma.grenoble-inp.fr
> Hello,
> I recently tried to build RTEMS with multilib enabled in order to install
> a GNAT Ada toolset [1]. However, the compilation failed with the error :
> ../../lib/include/pci/access.h:17:30: fatal error: libcpu/byteorder.h: No
> such file or directory
> The same problem has already been mentionned last year [2], but no
> solution was given. I've tried with the version of RTEMS sources available
> on Github, on branch 4.11, but also with the version 4.11.0-rc3 published
> on ftp.rtems.org, but both raised the same error. Moreover, I have run
> the bootstrap script right before trying to build. Any help would be highly
> appreciate!
Famous Henny Youngman joke comes to mind.

 The patient says, "Doctor, it hurts when I do this." "Then don't do that!"

The multilib build concept was really a developer only option to ensure we
didn't break
the rules for what was allowed to be used or conditionally compiled on in
the cpukit.
In some cases, it won't build in this mode due to a dependency like you
see. In others,
it may be a CPU core variant that is not fully supported but isn't used by
any BSP yet
so really doesn't impact anything.

For "normal" builds, you build with a BSP, don't enable multilib, and these
issues go away.

In this particular case, libpci is a Gaisler submission that is included as
and only enabled on the SPARC. It hasn't been tested anywhere else AFAIK but
it looks very promising.

I hope that makes sense. More below.

We would love a pointer to your application if possible.

I'm working with Debian 8.3 Jessie and I used RSB to install the C/C++
> cross compiler for Leon3. Here are some additional information about my
> configuration:
Awesome! It is always nice to see someone have success with the RSB

> $ sparc-rtems4.11-gcc --version -v
> sparc-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB no-repo, Newlib
> [...]
> Target: sparc-rtems4.11
> Configured with: ../gcc-4.9.3/configure
> --prefix=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools
> --bindir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/bin
> --exec_prefix=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools
> --includedir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/include
> --libdir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/lib
> --libexecdir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/libexec
> --mandir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/share/man
> --infodir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/share/info
> --datadir=/home/thibaud/Etudes/Ensimag3A/rtems/4.11.0-rc3/tools/share
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=sparc-rtems4.11
> --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib
> --with-system-zlib --disable-nls --without-included-gettext
> --disable-win32-registry --enable-version-specific-runtime-libs
> --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv
> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
> --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
> [...]
> Options given to build RTEMS:
> ../rtems-4.11.0-rc3/configure --prefix=$RTEMS --target=sparc-rtems4.11
> --enable-rtemsbsp=leon3 --enable-tests --enable-multilib --enable-cxx
> --enable-posix --enable-networking
> Options given to RSB (RTEMS Source Builder), I used the version available
> in the directory 4.11.0-rc3 on ftp.rtems.org):
> ../source-builder/sb-set-builder --log=sparc.log --prefix=$RTEMS/tools
> 4.11/rtems-sparc
Were there any issues with rc3?  We definitely appreciate feedback. This is
the first release cut
using the RSB infrastructure and the RSB is being enhanced to support
getting tool source
from rtems.org to support users long term. Otherwise, we can't control if a
project host dies,
reorganizes, deletes files, or changes URLs,   Plus there will be no
fetches from tool git or svn
for releases. We will capture tarballs for the same longevity reasons and

We are working to make RTEMS and tools reproducible long-term. We really
believe that
meets user needs better than pre-built binaries tied to increasingly out of
date host OSes.
That ignores disk space to store them, defining the hosts and much more.

I hope this provides some insight.


> References:
> [1] See comment in gcc/ada/gsocket.h, in gcc sources.
> [2] https://lists.rtems.org/pipermail/users/2015-April/028751.html
> Best regards,
> *Thibaud*
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160331/991b8ae6/attachment-0002.html>

More information about the users mailing list