Re: Draft for moving network headers from RTEMS to newlib
On 27/04/16 08:20, Chris Johns wrote: On 27/04/2016 15:58, Sebastian Huber wrote: On 27/04/16 05:53, Chris Johns wrote: On 26/04/2016 19:26, Sebastian Huber wrote: On 26/04/16 10:27, Chris Johns wrote: On 26/04/2016 17:31, Sebastian Huber wrote: On 26/04/16 07:51, Chris Johns wrote: On 26/04/2016 01:06, Christian Mauderer wrote: [...] Does gcc's multilib search extend beyond it's own install base? A multilib is a normal library which is available via the builtin search paths of GCC: LIBRARY_PATH=/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/ Does this mean all multilib libraries need the same prefix as gcc? Yes, as far as I know. The NetSNMP package is put here as Specific because it uses a large number of platform specific header files to access things like interfaces and routing tables. My point is, when a user considers 3rd party packages they have moved to the specific requirements for a specific project and multilibs verses per BSP builds mean little. The multilib view is nice when viewed from the RTEMS developer perspective or someone providing a service to clients where they bundle packages as prebuilt libraries, but is it nice to users from the community? I do not know. If both multilib and specific libraries can coexist I have no issue but this needs to be shown. Note, the layout is based on the Project Sandboxing documentation I have in the Getting Started Guide (https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). This documentation would need to be updated (hint). What is the benefit of per BSP libpng for example? What is built is tested, there is a 1:1 relationship here. The user is able to see and understand what is built, where it is installed and what they are linking too. Multilibing packages adds a layer of indirection and with that extra complexity. Multilibs in gcc is not very user friendly $ i386-rtems4.11-gcc -print-multi-lib .; m486;@mtune=i486 mpentium;@mtune=pentium mpentiumpro;@mtune=pentiumpro soft-float;@msoft-float m486/soft-float;@mtune=i486@msoft-float The output is just like the clang output. I suspect clang was forced to follow gcc. :) What do you mean with not user friendly? It is designed to be machine decoded. I suspect few on this list could decode that output and understand it and this is the interface a user gets if they want to use it. Its good enough to simply use it in the previously attached script. I think RTEMS has to do much better than 'hey hack on my script'. This was not my intended message. The GCC -print-multi-lib output is good enough to be easily used by scripts. [...] except that you see standard network headers even if the BSP is built without a network stack. Does this mess with the dummy.c support and create weird linker errors? I don't think this will pull in default-configuration (previously know as dummy.c). If you use socket() without a network stack, then you get an unresolved symbol to socket() linker error. default-configuration.c is only involved if you use a module and don't provide the module configuration. I assume all externals in the headers moved over have to have symbols added. We should come to a conclusion if we want the standard network headers in Newlib or not. There are 2 threads happening here. The benefit or impact of multibed libraries and the move to newlib of standard headers. I am ok with the header move. I am sure things will come up but I am also sure they can be addressed. The impact of multilibed library can consider mute because you have answer my central question which is both models for libraries can be supported. You can provide a library in a multilib directory or in a BSP-specific directory or in whatever directory you want to use. The linker search path determines which one is actually used. -- 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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Draft for moving network headers from RTEMS to newlib
On 27/04/2016 15:58, Sebastian Huber wrote: On 27/04/16 05:53, Chris Johns wrote: On 26/04/2016 19:26, Sebastian Huber wrote: On 26/04/16 10:27, Chris Johns wrote: On 26/04/2016 17:31, Sebastian Huber wrote: On 26/04/16 07:51, Chris Johns wrote: On 26/04/2016 01:06, Christian Mauderer wrote: [...] 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. Nice. Maybe limiting what is added to just building languages would be a nice first starting point. How do you get the flags for the compiler to build the package? See attached script which builds for example libpng for all multilibs. Multilibs has not had a very successful history with RTEMS (outside of gcc). They are not very user friendly and are a source of questions and issues. I think multilibs are great for libraries which don't depend on BSP specifics. I know ... https://lists.rtems.org/pipermail/users/2012-February/024544.html :) It is a useful idea and I like the work being done with the standards based headers. There is something inconsistent about this I am yet to put my finger on. I suspect it is related to some libraries being multilib and some libraries not being multilib. Consider an example app and lets assume all packages are working perfectly .. 1) GCC, newlib. - Multilib, /bd/rtems/4.11.0 2) RTEMS - Specific, /bd/rtems/4.11.0/bsps 3) NTP - Multilib, /bd/rtems/4.11.0/bsps 4) Protobufs - Multilib, /bd/rtems/4.11.0/bsps 5) Civetweb - Multilib, /bd/rtems/4.11.0/bsps 6) NetSNMP - Specific, /bd/rtems/4.11.0/bsps 7) Application - Executable I wonder what the application linker command line looks like? Does gcc's multilib search extend beyond it's own install base? A multilib is a normal library which is available via the builtin search paths of GCC: LIBRARY_PATH=/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/ Does this mean all multilib libraries need the same prefix as gcc? The NetSNMP package is put here as Specific because it uses a large number of platform specific header files to access things like interfaces and routing tables. My point is, when a user considers 3rd party packages they have moved to the specific requirements for a specific project and multilibs verses per BSP builds mean little. The multilib view is nice when viewed from the RTEMS developer perspective or someone providing a service to clients where they bundle packages as prebuilt libraries, but is it nice to users from the community? I do not know. If both multilib and specific libraries can coexist I have no issue but this needs to be shown. Note, the layout is based on the Project Sandboxing documentation I have in the Getting Started Guide (https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). This documentation would need to be updated (hint). What is the benefit of per BSP libpng for example? What is built is tested, there is a 1:1 relationship here. The user is able to see and understand what is built, where it is installed and what they are linking too. Multilibing packages adds a layer of indirection and with that extra complexity. Multilibs in gcc is not very user friendly $ i386-rtems4.11-gcc -print-multi-lib .; m486;@mtune=i486 mpentium;@mtune=pentium mpentiumpro;@mtune=pentiumpro soft-float;@msoft-float m486/soft-float;@mtune=i486@msoft-float The output is just like the clang output. I suspect clang was forced to follow gcc. :) What do you mean with not user friendly? It is designed to be machine decoded. I suspect few on this list could decode that output and understand it and this is the interface a user gets if they want to use it. Its good enough to simply use it in the previously attached script. I think RTEMS has to do much better than 'hey hack on my script'. $ arm-rtems4.11-gcc -print-multi-lib .; thumb;@mthumb thumb/armv6-m;@mthumb@march=armv6-m thumb/armv7-a;@mthumb@march=armv7-a thumb/armv7-r;@mthumb@march=armv7-r thumb/armv7-m;@mthumb@march=armv7-m thumb/armv7-a/neon/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard thumb/armv7-r/vfpv3-d16/hard;@mthumb@march=armv7-r@mfpu=vfpv3-d16@mfloat-abi=hard thumb/armv7-m/fpv4-sp-d16/hard;@mthumb@march=armv7-m@mfpu=fpv4-sp-d16@mfloat-abi=hard eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r eb/thumb/armv7-r/vfpv3-d16/hard;@mbig-endian@mthumb@march=armv7-r@mfpu=vfpv3-d16@mfloat-abi=hard I have no idea what this all means. One problem is that even you don't find the places where things are documented in RTEMS:
Re: Draft for moving network headers from RTEMS to newlib
On 27/04/16 05:53, Chris Johns wrote: On 26/04/2016 19:26, Sebastian Huber wrote: On 26/04/16 10:27, Chris Johns wrote: On 26/04/2016 17:31, Sebastian Huber wrote: On 26/04/16 07:51, Chris Johns wrote: On 26/04/2016 01:06, Christian Mauderer wrote: [...] I see an explosion of libraries if we build them for each BSP. We have count of BSPs > count of multilibs, otherwise the GCC configuration is broken. This is only valid for developers who have to build all BSPS. Most uses have one or maybe 2 BSPs they are working with at a time. My question was, do we care about this? You do not see it as an issue because your need to package built tools and libraries is important, and I can live with it cause I have fast machines and fast disks but we are just 2 people. I think its quite nice if you are able to build support libraries as a part of the tool chain and not specific to a particular BSP. FYI there are 11 variants in ARM. Yes, and we need them all. 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. Nice. Maybe limiting what is added to just building languages would be a nice first starting point. How do you get the flags for the compiler to build the package? See attached script which builds for example libpng for all multilibs. Multilibs has not had a very successful history with RTEMS (outside of gcc). They are not very user friendly and are a source of questions and issues. I think multilibs are great for libraries which don't depend on BSP specifics. I know ... https://lists.rtems.org/pipermail/users/2012-February/024544.html :) It is a useful idea and I like the work being done with the standards based headers. There is something inconsistent about this I am yet to put my finger on. I suspect it is related to some libraries being multilib and some libraries not being multilib. Consider an example app and lets assume all packages are working perfectly .. 1) GCC, newlib. - Multilib, /bd/rtems/4.11.0 2) RTEMS - Specific, /bd/rtems/4.11.0/bsps 3) NTP - Multilib, /bd/rtems/4.11.0/bsps 4) Protobufs - Multilib, /bd/rtems/4.11.0/bsps 5) Civetweb - Multilib, /bd/rtems/4.11.0/bsps 6) NetSNMP - Specific, /bd/rtems/4.11.0/bsps 7) Application - Executable I wonder what the application linker command line looks like? Does gcc's multilib search extend beyond it's own install base? A multilib is a normal library which is available via the builtin search paths of GCC: LIBRARY_PATH=/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/thumb/armv7-m/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/:/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/6.0.1/../../../../arm-rtems4.12/lib/ The NetSNMP package is put here as Specific because it uses a large number of platform specific header files to access things like interfaces and routing tables. My point is, when a user considers 3rd party packages they have moved to the specific requirements for a specific project and multilibs verses per BSP builds mean little. The multilib view is nice when viewed from the RTEMS developer perspective or someone providing a service to clients where they bundle packages as prebuilt libraries, but is it nice to users from the community? I do not know. If both multilib and specific libraries can coexist I have no issue but this needs to be shown. Note, the layout is based on the Project Sandboxing documentation I have in the Getting Started Guide (https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). This documentation would need to be updated (hint). What is the benefit of per BSP libpng for example? What is built is tested, there is a 1:1 relationship here. The user is able to see and understand what is built, where it is installed and what they are linking too. Multilibing packages adds a layer of indirection and with that extra complexity. Multilibs in gcc is not very user friendly $ i386-rtems4.11-gcc -print-multi-lib .; m486;@mtune=i486 mpentium;@mtune=pentium mpentiumpro;@mtune=pentiumpro soft-float;@msoft-float m486/soft-float;@mtune=i486@msoft-float The output is just like the clang output. What do you mean with not user friendly? Its good enough to simply use it in the previously attached script. $ arm-rtems4.11-gcc -print-multi-lib .; thumb;@mthumb thumb/armv6-m;@mthumb@march=armv6-m thumb/armv7-a;@mthumb@march=armv7-a thumb/armv7-r;@mthumb@march=armv7-r thumb/armv7-m;@mthumb@march=armv7-m thumb/armv7-a/neon/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard thumb/armv7-r/vfpv3-d16/hard;@mthumb@march=armv7-r@mfpu=vfpv3-d16@mfloat-abi=hard thumb/armv7-m/fpv4-sp-d16/hard;@mthumb@march=armv7-m@mfpu=fpv4-sp-d16@mfloat-abi=hard eb/thumb/armv7-r;@mbig-endian@mthumb@march=armv7-r
Re: Draft for moving network headers from RTEMS to newlib
On 26/04/2016 19:26, Sebastian Huber wrote: On 26/04/16 10:27, Chris Johns wrote: On 26/04/2016 17:31, Sebastian Huber wrote: 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. Hmm multilib, this is what I thought was happening. I see this exploding the libraries if packages are built this way. Do we manage this or not bother and just accept all variants have to be built? The multilibs are there for a purpose. In case a particular architecture has superfluous multilibs, then we should remove them. I have no idea which variants of each architecture are actually used. I suspect we need to document this better. I see clang has better support for multilib than in the past ... $ clang -print-multi-lib .; x86_64;@m64 This is nice. I see an explosion of libraries if we build them for each BSP. We have count of BSPs > count of multilibs, otherwise the GCC configuration is broken. This is only valid for developers who have to build all BSPS. Most uses have one or maybe 2 BSPs they are working with at a time. My question was, do we care about this? You do not see it as an issue because your need to package built tools and libraries is important, and I can live with it cause I have fast machines and fast disks but we are just 2 people. FYI there are 11 variants in ARM. 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. Nice. Maybe limiting what is added to just building languages would be a nice first starting point. How do you get the flags for the compiler to build the package? See attached script which builds for example libpng for all multilibs. Multilibs has not had a very successful history with RTEMS (outside of gcc). They are not very user friendly and are a source of questions and issues. I think multilibs are great for libraries which don't depend on BSP specifics. I know ... https://lists.rtems.org/pipermail/users/2012-February/024544.html :) It is a useful idea and I like the work being done with the standards based headers. There is something inconsistent about this I am yet to put my finger on. I suspect it is related to some libraries being multilib and some libraries not being multilib. Consider an example app and lets assume all packages are working perfectly .. 1) GCC, newlib. - Multilib, /bd/rtems/4.11.0 2) RTEMS - Specific, /bd/rtems/4.11.0/bsps 3) NTP - Multilib, /bd/rtems/4.11.0/bsps 4) Protobufs - Multilib, /bd/rtems/4.11.0/bsps 5) Civetweb - Multilib, /bd/rtems/4.11.0/bsps 6) NetSNMP - Specific, /bd/rtems/4.11.0/bsps 7) Application - Executable I wonder what the application linker command line looks like? Does gcc's multilib search extend beyond it's own install base? The NetSNMP package is put here as Specific because it uses a large number of platform specific header files to access things like interfaces and routing tables. My point is, when a user considers 3rd party packages they have moved to the specific requirements for a specific project and multilibs verses per BSP builds mean little. The multilib view is nice when viewed from the RTEMS developer perspective or someone providing a service to clients where they bundle packages as prebuilt libraries, but is it nice to users from the community? I do not know. If both multilib and specific libraries can coexist I have no issue but this needs to be shown. Note, the layout is based on the Project Sandboxing documentation I have in the Getting Started Guide (https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/start/index.html#project-sandboxing). This documentation would need to be updated (hint). What is the benefit of per BSP libpng for example? What is built is tested, there is a 1:1 relationship here. The user is able to see and understand what is built, where it is installed and what they are linking too. Multilibing packages adds a layer of indirection and with that extra complexity. Multilibs in gcc is not very user friendly $ i386-rtems4.11-gcc -print-multi-lib .; m486;@mtune=i486 mpentium;@mtune=pentium mpentiumpro;@mtune=pentiumpro soft-float;@msoft-float m486/soft-float;@mtune=i486@msoft-float $ arm-rtems4.11-gcc -print-multi-lib .; thumb;@mthumb thumb/armv6-m;@mthumb@march=armv6-m thumb/armv7-a;@mthumb@march=armv7-a thumb/armv7-r;@mthumb@march=armv7-r thumb/armv7-m;@mthumb@march=armv7-m
Re: Draft for moving network headers from RTEMS to newlib
On 26/04/16 10:27, Chris Johns wrote: On 26/04/2016 17:31, Sebastian Huber wrote: 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. Hmm multilib, this is what I thought was happening. I see this exploding the libraries if packages are built this way. Do we manage this or not bother and just accept all variants have to be built? The multilibs are there for a purpose. In case a particular architecture has superfluous multilibs, then we should remove them. I see an explosion of libraries if we build them for each BSP. We have count of BSPs > count of multilibs, otherwise the GCC configuration is broken. 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. Nice. Maybe limiting what is added to just building languages would be a nice first starting point. How do you get the flags for the compiler to build the package? See attached script which builds for example libpng for all multilibs. Multilibs has not had a very successful history with RTEMS (outside of gcc). They are not very user friendly and are a source of questions and issues. I think multilibs are great for libraries which don't depend on BSP specifics. What is the benefit of per BSP libpng for example? I would like to see something more than a script posted before I get excited and accepting of this path. I would like to understand the work flow for the project, the developers and the users? You don't need BSPs installed to do this. The libpng is just an add-on to the tool chain. Sure, I understand this and it is nice. I hope users do not forget to build the BSP. ;) The work flow is build the tool chain, build all support libraries you are interested in, then build the actual BSPs. How are any tests present in the package built and linked? Tests are executables, so they need a BSP. Yes, so how do these packages get tested? How are packages tested currently? You can only test using a particular 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. If a package changes or something happens we would need a new version of tools. Yes, but this area is not really volatile. Its not that we have a new POSIX standard every two months. The old network stack uses about 20 year old header files. I am concerned about the management of the detail here and finding a suitable set of headers for all packages across all architecture may become complicated if there are incompatibilities between architectures and/or packages. With standards based headers we have the standard to fall back on and we can get the package fixed. When we move away from standards based headers we open up a range potential issue. Adding the headers is easy, removing would be hard if not impossible. Once we head down this path will be difficult to turn back. The place of the header file makes no difference here. For the user its the same if you remove the file from Newlib or RTEMS. It is a massive task to get the tools to build for supported architectures _now_ and I hope this path does not increase the work load here. If we add Ada and Go to the standard languages, then it could get more difficult. Do you have limits or boundaries for suitable headers? Who administers these boundaries? What is the procedure for a user to add a header? Like everything else in RTEMS this will be user driven. Someone is not satisfied with the current situation and will work out a fix. If a header is missing does this means the user cannot build a package? In other words can we mix how we currently build packages with this way of building packages? You can still build against a BSP which presents the full set of header files. 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
Re: Draft for moving network headers from RTEMS to newlib
On 26/04/2016 17:31, Sebastian Huber wrote: 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. Hmm multilib, this is what I thought was happening. I see this exploding the libraries if packages are built this way. Do we manage this or not bother and just accept all variants have to be built? 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. Nice. Maybe limiting what is added to just building languages would be a nice first starting point. How do you get the flags for the compiler to build the package? See attached script which builds for example libpng for all multilibs. Multilibs has not had a very successful history with RTEMS (outside of gcc). They are not very user friendly and are a source of questions and issues. I would like to see something more than a script posted before I get excited and accepting of this path. I would like to understand the work flow for the project, the developers and the users? You don't need BSPs installed to do this. The libpng is just an add-on to the tool chain. Sure, I understand this and it is nice. I hope users do not forget to build the BSP. ;) How are any tests present in the package built and linked? Tests are executables, so they need a BSP. Yes, so how do these packages get tested? 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. If a package changes or something happens we would need a new version of tools. I am concerned about the management of the detail here and finding a suitable set of headers for all packages across all architecture may become complicated if there are incompatibilities between architectures and/or packages. With standards based headers we have the standard to fall back on and we can get the package fixed. When we move away from standards based headers we open up a range potential issue. Adding the headers is easy, removing would be hard if not impossible. Once we head down this path will be difficult to turn back. It is a massive task to get the tools to build for supported architectures _now_ and I hope this path does not increase the work load here. Do you have limits or boundaries for suitable headers? Who administers these boundaries? What is the procedure for a user to add a header? If a header is missing does this means the user cannot build a package? In other words can we mix how we currently build packages with this way of building packages? 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. Correct each BSP is independent and that gives me the ability to vary and change things in RTEMS without needing to repeat tools builds or create separate sandboxes at the tools level. The whole point of the cpukit was to multilib build the generic code and avoid the duplication in the BSPs however in the end it became clear a single specific BSP is all most users need and overhead of that specific build and install even with per BSP headers is faster and simpler than the whole multilib path. Having a single tree of headers is fine if they are stable and not changing. I do not use a single prefix and prefer separate prefixes so I can mix and match and play. Having more and more header become part of the tools removes an important part of this process. It comes down to the type of header and how often they change. 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. What about testing? This needs to be resolved. One advantage is that the built-in search
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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. install.sh Description: application/shellscript ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
