<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 3:06 PM, Thibaud Backenstrass <span dir="ltr"><<a href="mailto:thibaud.backenstrass@phelma.grenoble-inp.fr" target="_blank">thibaud.backenstrass@phelma.grenoble-inp.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><b>Thibaud BACKENSTRASS</b><br><i>Élève-ingénieur - Grenoble INP-Phelma - 3A SLE</i><br></div>E-mail : <a href="mailto:thibaud.backenstrass@phelma.grenoble-inp.fr" target="_blank">thibaud.backenstrass@phelma.grenoble-inp.fr</a><br></div></div></div></div></div></div></div></div></div></div>
<div dir="ltr"><div><div><div>Hello,<br><br></div>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 :<br><br>../../lib/include/pci/access.h:17:30: fatal error: libcpu/byteorder.h: No such file or directory<br><br></div><div>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 <a href="http://ftp.rtems.org" target="_blank">ftp.rtems.org</a>, but
both raised the same error. Moreover, I have run the bootstrap script
right before trying to build. Any help would be highly appreciate!<br><br><br></div></div></div></div></blockquote><div><br></div><div>Famous Henny Youngman joke comes to mind. </div><div><br></div><div> The patient says, "Doctor, it hurts when I do this." "Then don't do that!" <br></div><div><br></div><div>The multilib build concept was really a developer only option to ensure we didn't break</div><div>the rules for what was allowed to be used or conditionally compiled on in the cpukit.</div><div>In some cases, it won't build in this mode due to a dependency like you see. In others,</div><div>it may be a CPU core variant that is not fully supported but isn't used by any BSP yet</div><div>so really doesn't impact anything.</div><div><br></div><div>For "normal" builds, you build with a BSP, don't enable multilib, and these issues go away.</div><div><br></div><div>In this particular case, libpci is a Gaisler submission that is included as experimental</div><div>and only enabled on the SPARC. It hasn't been tested anywhere else AFAIK but</div><div>it looks very promising.</div><div><br></div><div>I hope that makes sense. More below.</div><div><br></div><div>We would love a pointer to your application if possible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div></div><div>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:<br><br></div></div></div></div></blockquote><div><br></div><div>Awesome! It is always nice to see someone have success with the RSB</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div></div><div>$ sparc-rtems4.11-gcc --version -v<br>sparc-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB no-repo, Newlib 2.2.0.20150423)<br>[...]<br>Target: sparc-rtems4.11<br>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++<br>[...]<br></div><div><br></div><div>Options given to build RTEMS:<br>../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<br><br></div><div>Options given to RSB (RTEMS Source Builder), I used the version available in the directory 4.11.0-rc3 on <a href="http://ftp.rtems.org" target="_blank">ftp.rtems.org</a>):<br>../source-builder/sb-set-builder --log=sparc.log --prefix=$RTEMS/tools 4.11/rtems-sparc<br></div><div><br></div></div></div></div></blockquote><div><br></div><div>Were there any issues with rc3? We definitely appreciate feedback. This is the first release cut</div><div>using the RSB infrastructure and the RSB is being enhanced to support getting tool source</div><div>from <a href="http://rtems.org">rtems.org</a> to support users long term. Otherwise, we can't control if a project host dies,</div><div>reorganizes, deletes files, or changes URLs, Plus there will be no fetches from tool git or svn</div><div>for releases. We will capture tarballs for the same longevity reasons and configuration </div><div>management.</div><div><br></div><div>We are working to make RTEMS and tools reproducible long-term. We really believe that</div><div>meets user needs better than pre-built binaries tied to increasingly out of date host OSes.</div><div>That ignores disk space to store them, defining the hosts and much more.</div><div><br></div><div>I hope this provides some insight.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div><br></div><div>References:<br></div>[1] See comment in gcc/ada/gsocket.h, in gcc sources.<br>[2] <a href="https://lists.rtems.org/pipermail/users/2015-April/028751.html" target="_blank">https://lists.rtems.org/pipermail/users/2015-April/028751.html</a><br><br><br></div>Best regards,<br><br clear="all"><b>Thibaud</b></div></div>
<br>_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br></blockquote></div><br></div></div>