Compilation error of rtems for sparc-leon2 with multilib enabled

Jan Sommer soja-misc at aries.uberspace.de
Sun Jun 7 16:13:31 UTC 2015


Sorry for digging up this old thread, but while playing around with the 
raspberry pi, I just noticed the following:
If I build rtems without the --enable-multilib option it will create a 
socket.h for each bsp under 
/opt/rtems-4.11-leon/sparc-rtems4.11/<bspname>/lib/include/sys/socket.h
However when building gcc again with Ada enabled it won't find the sys-include 
folder.
With multilib enabled the headers will be in 
/opt/rtems-4.11-leon/sparc-rtems4.11/include/sys/socket.h
and will be found automatically when building gcc.

As --enable-multilib is not working for Sparc currently I was wondering how 
one would build the Ada toolchain then. Is there a gcc option to pass the path 
for the header files? I tried --with-local-prefix= but it didn't work.

Best regards,

   Jan

Am Sonntag, 3. Mai 2015, 16:22:30 schrieb Sebastian Huber:
> ----- Jan Sommer <soja-misc at aries.uberspace.de> schrieb:
> > Am Samstag, 2. Mai 2015, 11:09:00 schrieb Joel Sherrill:
> > > On May 2, 2015 11:00:55 AM CDT, Jan Sommer
> > > <soja-misc at aries.uberspace.de>
> > 
> > wrote:
> > > >It works if I don't use --enable-multilib
> > > 
> > > That's the issue. A normal BSP build doesn't turn that on. It was added
> > > long ago as a testing way to ensure the cpukit could be successfully
> > > compiled for all CPU model variants gcc knows even if we don't have a
> > > BSP that really uses it or if the odd combination even exists in
> > > silicon. Disable that and the leon2 will build.
> > 
> > Ok, I didn't know that. It's a bit confusing to me. When building gcc you
> > usually want to enable-multilib and here you shouln't?
> 
> Yes, this is very confusing and you are not the first RTEMS user that
> encountered this problem.
> > > Out of curiosity, what combination isn't building?
> > 
> > How would I find out? Tried to find something in the build log but wasn't
> > sure what I was looking for.
> > 
> > Anyways, thank you very much for your help.
> 
> I guess the SPARC multilib support in general is broken due to the
> <libcpu/*.h> include.  This file must move to a cpukit location.



More information about the users mailing list