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