RTEMS + g++ + #include <netinet/in.h>

[Chris Johns]

Ralf Corsepius wrote:
> 
> Chris Johns wrote:
> >
> > Hi,
> >
> > The simple test program :
> >
> > ------ 8< - tst.cpp ------
> > #include <sys/types.h>
> > #include <netinet/in.h>
> > ------ 8< ----------------
> >
> > gives :
> >
> > $ m68k-rtems-g++ -c -I /opt/rtems/rtems/bare-5200/lib/include tst.cpp
> > In file included from tst.cpp:2:
> > /opt/rtems/rtems/bare-5200/lib/include/netinet/in.h:282: ANSI C++
> > forbids data member `ip_opts' with same name as enclosing class
> 
> Try m68k-rtems-g++ -isystem /opt/rtems/rtems/bare-5200/lib/include
> -c tst.cpp
> 
> or (preferred)
> m68k-rtems-g++ -B/opt/rtems/rtems/bare-5200/lib/ -c tst.cpp
> 

Ok. I will check this option out.

> [Note: This implies using
>  CXX=m68k-rtems-g++ -B/opt/rtems/rtems/bare-5200/lib/
> ]
> 
> > So GCC knows a file is included from a system directory. The result is
> > <netinet/in.h> compiles on FreeBSD, but fails under RTEMS as we do not
> > place <netinet/in.h> in a path which GCC sees as a system directory.
> >
> > Looking at the m68k-rtems-gcc I have, the system include is listed as :
> >
> >  /opt/rtems/lib/gcc-lib/m68k-rtems/2.95.2/../../../../m68k-rtems/include
> 
> = /opt/rtems/m68k-rtems/include
> = ${prefix)/$target/include
> = $(tooldir)/include
> 

I found on FreeBSD the following :

 ok : g++ -c tst.cpp
 ok : g++ -I /usr/include tst -c tst.cpp

while with <netinet/in.h> moved to the default system include path :

 ok  : m68k-rtems-g++ -c tst.cpp
 err : m68k-rtems-g++ -I /opt/rtems/m68k-rtems/include tst.cpp

so it seems the path is a direct match not one based on the actual final
path.

> > Should the RTEMS install put this file in the correct spot ?
> This in fact would be the correct spot for bsp-independent,
> target-only dependent header files.
> 
> However, RTEMS currently is built per BSP, so a bsp-independent
> installation directory can not be used (yet).
> 
> Actually, your observation is an indication for yet another hidden
> general structural weakness in RTEMS.
> 

I also found when porting the BSD /bin commands to RTEMS that the
networking code and BSD parts (libc etc) are "upside" down. I feel RTEMS
should have a bsd source tree under which the networking and bin code
resides. The problem I have with the bsd bin commands, such as `ls',
`cat', `rm' etc, which I have ported but not merged is I need more of
the BSD libc as well as some of the already ported networking files. I
do not wish to merge in the bin commands and create another location
where a few more BSD libc files exist. The BSD is a great port and shows
how useful BSD code is in RTEMS. I would like to make more use of it
without creating more problems.

> > Comments,
> Joel, Eric N. and I already have an ongoing discussion on PM on a
> related subject.
> 
> I am already working on part of this subject as part of the bsp
> split out effort, however I currently do not have much time left for
> working on RTEMS (almost none), so progress is very slow.
> 

I understand. My current situation is similar.

> > solutions welcome.
> For now, all RTEMS headers (=RTEMS system headers) have to be
> installed to $(prefix)/<BSP>/lib/include.
> I.e. -isystem $(prefix)/<BSP>/lib/include or -B$(prefix)/<BSP>/lib/
> has to be _prepended_ to the compile command if using gcc.
> If using 3rd party compilers, you will probably have a hard time
> getting this working at all.
> 

Thanks for the excellent reply.

-- 
 Chris Johns, mailto:cjohns at cybertec.com.au mailto:ccj at acm.org