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@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@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
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
