Draft for moving network headers from RTEMS to newlib

Wed Apr 27 05:58:10 UTC 2016

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 at 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 at march=armv6-m
> thumb/armv7-a;@mthumb at march=armv7-a
> thumb/armv7-r;@mthumb at march=armv7-r
> thumb/armv7-m;@mthumb at march=armv7-m
> thumb/armv7-a/neon/hard;@mthumb at march=armv7-a at mfpu=neon at mfloat-abi=hard
> thumb/armv7-r/vfpv3-d16/hard;@mthumb at march=armv7-r at mfpu=vfpv3-d16 at mfloat-abi=hard 
>
> thumb/armv7-m/fpv4-sp-d16/hard;@mthumb at march=armv7-m at mfpu=fpv4-sp-d16 at mfloat-abi=hard 
>
> eb/thumb/armv7-r;@mbig-endian at mthumb@march=armv7-r
> eb/thumb/armv7-r/vfpv3-d16/hard;@mbig-endian at mthumb@march=armv7-r at mfpu=vfpv3-d16 at 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:

https://docs.rtems.org/doc-current/share/rtems/html/cpu_supplement/Port-Specific-Information-Multilibs.html#Port-Specific-Information-Multilibs

https://docs.rtems.org/doc-current/share/rtems/html/cpu_supplement/ARM-Specific-Information-Multilibs.html#ARM-Specific-Information-Multilibs

However, not all architectures have this section or an up to date content.

[...]
>> I don't understand why you need these libraries per BSP if they have
>> absolutely no BSP dependency. I use these multilib based libraries for
>> several years and it works quite well.
>
> Great to hear and I am sure these changes will make your private 
> efforts simpler.

I am pretty sure it will not only make my private efforts simpler.

>
> I am attempting to understand what effect this has on the RTEMS 
> project and our users. If you are able to build the existing 3rd party 
> packages in the RSB before and after the changes then I am happy. Some 
> may not build completely so if you can achieve the same level of build 
> that would be fine. I would also like to see some documentation about 
> multilibing and how users are able to use it and do this themselves.
>
> Chris

If you build the package against a particular BSP, then nothing will 
change, except that you see standard network headers even if the BSP is 
built without a network stack.

We should come to a conclusion if we want the standard network headers 
in Newlib or not.

-- 
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.