Re: Unknown symbol in rtai_math.ko in rtai-5.0
Paolo Mantegazza <[email protected]> Thu, 15 Feb 2018 17:39:01 +0100
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============4805526600274195899==
Content-Type: multipart/alternative;
boundary="------------E66FA822418DD3582B3A0F6C"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------E66FA822418DD3582B3A0F6C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 02/12/2018 11:22 PM, Alec Ari wrote:
> Less maintenance? You cannot use the provided Glibc libm library=20
> shipped with any 64-bit Linux distribution I tried, as-is, without=20
> compiling newlib or another C library yourself to build the RTAI math=20
> module. Having to compile a C library specific to RTAI in my opinion=20
> is considered maintenance, and was not needed at all with the previous=20
> code. It compiled as-is on any Linux distribution, new, old, 32 or=20
> 64-bit with safer CFLAGS and bootstrap/autotools clean-up.
That's your point of view. On my side I have had less work to do since I=20
passed to the actual scheme, apart from reviving the aging uClibc=20
support, with the newer fork uClibc-ng, already in the repository but=20
not released yet.
Recall also that the old way had licenses, of the SUN kind if recall it=20
correctly, that a few users disliked for not being GPL compatible.
So I hope you are embedding some substitutive GPL compatible code=20
versions. On my side I know that uClibc-ng, whose ancestor uClibc was=20
the provider of what you are still likely using, keeps that kind of=20
license. However it is not in RTAI and choosing uClibc is up to its users=
.
> Again, what is with -ffast-math and why did/do you need it? If you=20
> compile GMP, MPFR and MPC with -funsafe-math-optimizations vs=20
> -ffast-math and run make check, you get much fewer errors with=20
> floating point compliance than -ffast-math. Ideally, for the best=20
> compromise between speed and precision/stability, I'd suggest=20
> -funsafe-math-optimizations -ftree-vectorize with -mfpmath=3Dsse -msse=20
> -msse2. Thoughts on this?
>
You may be right, but the problem is that the FPU related options=20
require one is sure that they are well supported in the code. The way=C2=A0=
=20
in which RTAI libm.a is made has a long record of being OK. If you want=20
to provide a newer and as robust RTAI FPU support as the one that is now=20
in RTAI, I'll be glad to review it.
Paolo
> Alec Ari
--------------E66FA822418DD3582B3A0F6C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 02/12/2018 11:22 PM, Alec Ari wrote=
:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:[email protected]">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Du=
tf-8">
<div style=3D"font-family:times new roman, new york, times,
serif;font-size:16px;">
<div>Less maintenance? You cannot use the provided Glibc libm
library shipped with any 64-bit Linux distribution I tried,
as-is, without compiling newlib or another C library yourself
to build the RTAI math module. Having to compile a C library
specific to RTAI in my opinion is considered maintenance, and
was not needed at all with the previous code. It compiled
as-is on any Linux distribution, new, old, 32 or 64-bit with
safer CFLAGS and bootstrap/autotools clean-up.</div>
</div>
</blockquote>
<br>
That's your point of view. On my side I have had less work to do
since I passed to the actual scheme, apart from reviving the aging
uClibc support, with the newer fork uClibc-ng, already in the
repository but not released yet. <br>
Recall also that the old way had licenses, of the SUN kind if recall
it correctly, that a few users disliked for not being GPL
compatible. <br>
So I hope you are embedding some substitutive GPL compatible code
versions. On my side I know that uClibc-ng, whose ancestor uClibc
was the provider of what you are still likely using, keeps that kind
of license. However it is not in RTAI and choosing uClibc is up to
its users.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:[email protected]">
<div style=3D"font-family:times new roman, new york, times,
serif;font-size:16px;">
<div>Again, what is with -ffast-math and why did/do you need it?
If you compile GMP, MPFR and MPC with
-funsafe-math-optimizations vs -ffast-math and run make check,
you get much fewer errors with floating point compliance than
-ffast-math. Ideally, for the best compromise between speed
and precision/stability, I'd suggest
-funsafe-math-optimizations -ftree-vectorize with -mfpmath=3Dss=
e
-msse -msse2. Thoughts on this?<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
You may be right, but the problem is that the FPU related options
require one is sure that they are well supported in the code. The
way=C2=A0 in which RTAI libm.a is made has a long record of being OK.=
If
you want to provide a newer and as robust RTAI FPU support as the
one that is now in RTAI, I'll be glad to review it.<br>
<br>
Paolo<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:[email protected]">
<div style=3D"font-family:times new roman, new york, times,
serif;font-size:16px;">
<div>Alec Ari<br>
</div>
<div id=3D"ydp26438661yahoo_quoted_8667739322"
class=3D"ydp26438661yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial,
sans-serif;font-size:13px;color:#26282a;"> </div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
--------------E66FA822418DD3582B3A0F6C--
--===============4805526600274195899==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
--===============4805526600274195899==--