| Thread Previous • Date Previous • Date Next • Thread Next |
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-floatThe 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@xxxxxxxxxxxxxxxxxx PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@xxxxxxxxx http://lists.rtems.org/mailman/listinfo/devel
| Thread Previous • Date Previous • Date Next • Thread Next |
