Draft for moving network headers from RTEMS to newlib

Wed Apr 27 06:20:40 UTC 2016

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

Ah ok, yes I did not know this existed. Thank you.

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

Maybe this can be addressed in the new web site Amar is working on.

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

Great.

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

Chris