t-kernel team mailing list archive
-
t-kernel team
-
Mailing list archive
-
Message #00229
Re: Draft for moving network headers from RTEMS to newlib
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@xxxxxxxxxxxxxxxxxx
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Attachment:
install.sh
Description: application/shellscript
_______________________________________________
devel mailing list
devel@xxxxxxxxx
http://lists.rtems.org/mailman/listinfo/devel