Draft for moving network headers from RTEMS to newlib

[Sebastian Huber]

On 26/04/16 07:51, Chris Johns wrote:
> On 26/04/2016 01:06, Christian Mauderer wrote:
>> currently we try to remove the network specific POSIX headers from
>> RTEMS. Instead, we add current headers from FreeBSD to newlib. This will
>> simplify the build process of some libraries that depend on the network
>> (like LibreSSL).
>
> What does this work flow offer over building and installing an RTEMS 
> kernel for a BSP and adding that path to the packages include paths?

You don't build per BSP in this scenario. You build per multilib and 
have only one set of header files installed. You are able to use the 
network header files during GCC build, which makes it easier to build 
the run-time libraries of Ada and Go.

>
> How do you get the flags for the compiler to build the package?

See attached script which builds for example libpng for all multilibs. 
You don't need BSPs installed to do this. The libpng is just an add-on 
to the tool chain.

>
> How are any tests present in the package built and linked?

Tests are executables, so they need a BSP.

>
> Do we risk limited the functionality of a package by restricting the 
> headers exposed to only standards based headers? There are headers 
> which some packages use that will not be present.

In case a common header file is missing for a particular package, then 
we can add this file to Newlib.

>
>> Further it will be another step into the direction of
>> extracting the old RTEMS network stack and build it as an independent
>> package.
>
> Is this just a specialised version of the generic vertical integration 
> problem being discussed in the civetweb thread?
>
> I am not against standards based headers like the ones being discussed 
> here being move to newlib however I currently do not see what the 
> advantage is and how value is being adding over a specific build order 
> of packages.

Building libraries against a particular BSP using actually BSP 
independent header files is not really a great overall setup.

>
> I still see all the normal issues of CFLAGS, LDFLAGS, 3rd party 
> package dependence still being present once this work is completed.

For libraries, the LDFLAGS are irrelevant. One advantage is that the 
built-in search paths are sufficient if you build against a multilib 
(except the machine flags), see attached script.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: install.sh
Type: application/x-shellscript
Size: 1088 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160426/b624b53a/attachment.bin>