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