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
