Draft for moving network headers from RTEMS to newlib

[Sebastian Huber]

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

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.huber at embedded-brains.de
PGP     : Public key available on request.

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