Whelp, pull request submitted. Just be sure to test the math!
https://github.com/LinuxCNC/linuxcnc/pull/2685
The 2.9 branch will be broken with newer RTAI without this, so if it works in
master I'd cherry-pick it.
Alec
___
Emc-developers mailing
On Sat, 7 Oct 2023 at 00:00, Alec Ari via Emc-developers
wrote:
>
> I don't exactly know why switching to GNU11 causes this issue, maybe the
> GNU11 standard already defines these, but I removed LinuxCNC's definitions of
> the following functions:
>
> atan
> asin
> acos
> fmax
> fmin
That
I can't tell because my C skills are pretty bad but looking at fmax and fmin,
I'm worried that the X and Y axis might be flipped for example:
LinuxCNC from rtapi_math.h:
extern __inline double fmax(double __y, double __x) {
return __y > __x || __builtin_isnan(__x) ? __y : __x;
}
extern
I can make a pull request, I'm pretty sure the appropriate fix is indeed the
correct fix. I think it'd be important to test the implementations of atan,
asin, acos, fmax and fmin to make sure all is well. LinuxCNC will report errors
if any of the math is wrong, yes? Say for example the accuracy
I don't exactly know why switching to GNU11 causes this issue, maybe the GNU11
standard already defines these, but I removed LinuxCNC's definitions of the
following functions:
atan
asin
acos
fmax
fmin
from rtapi_math.h
and had to remove -Werror=frame-larger-than=2560 from LinuxCNC's Makefile
On Mon, 2 Oct 2023 at 00:14, Alec Ari via Emc-developers
wrote:
>
> Oh crap, I'm seeing these too. This might be because of the gnu11 changes but
> I'll have to look into this more. Yes, trig errors everywhere.
I am only seeing them so far in hostmot2. Might be worth commenting
out hostmot2 in
Oh crap, I'm seeing these too. This might be because of the gnu11 changes but
I'll have to look into this more. Yes, trig errors everywhere.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
On Sun, 1 Oct 2023 at 21:25, andy pugh wrote:
> I suspect that this is because you worked musl into rtail_math.ko?
> Though there may be lots of other explanations.
It looks like we have always loaded rtai_math.ko. So I don't actually
know where to look now.
--
atp
"A motorcycle is a bicycle
On Sat, 30 Sept 2023 at 23:27, Alec Ari via Emc-developers
wrote:
>
> Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules
> with the `gnu11` branch. Just be sure to revert the gnu89 commit for
> limit_axis when testing the debs. I'm not sure when I'll exactly get around
>
On Sat, 30 Sept 2023 at 23:45, andy pugh wrote:
> Don't bother with the kernel, I have that done already.
If you have them, then carry on. But I think I am nearly there, other
than RTAI just installing in /usr/realtime (with no kernel suffix)
But, it's time to stop for the day.
--
atp
"A
On Sat, 30 Sept 2023 at 23:27, Alec Ari via Emc-developers
wrote:
>
> Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules
> with the `gnu11` branch. Just be sure to revert the gnu89 commit for
> limit_axis when testing the debs. I'm not sure when I'll exactly get around
>
Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules with
the `gnu11` branch. Just be sure to revert the gnu89 commit for limit_axis when
testing the debs. I'm not sure when I'll exactly get around to this but I got
it.
Alec
On Sat, 30 Sept 2023 at 22:40, Alec Ari via Emc-developers
wrote:
> Then skip to line 92, Creating RTAI Debian packages
>
> That's a really odd problem that I've never before. I was able to build RTAI
> kernel and module packages on Debian 12, forget my exact release.
>
> If it fails again,
I would do a `make mrproper` and follow these steps for the kernel build:
https://github.com/NTULINUX/RTAI/blob/gnu11/README.INSTALL
Then skip to line 92, Creating RTAI Debian packages
That's a really odd problem that I've never before. I was able to build RTAI
kernel and module packages on
On Sat, 30 Sept 2023 at 13:17, andy pugh wrote:
> FATAL: parse error in symbol dump file
Probably due to skipping the "make modules" stage of the kernel build,
as I went straight to the deb build.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial
On Thu, 28 Sept 2023 at 03:28, Alec Ari via Emc-developers
wrote:
>
> Yes, use the gnu11 branch in my RTAI tree and pick either 4.19.294 or or
> 5.4.256
I have switched to Debian 12 and kernel 5.4.256-rtai
I am having trouble compiling RTAI:
Making all in src
make[2]: Entering directory
Yes, use the gnu11 branch in my RTAI tree and pick either 4.19.294 or or 5.4.256
As an additional layer of testing, revert the C89 commit in LinuxCNC to make
sure GNU11 `for` loops actually work as intended:
https://github.com/LinuxCNC/linuxcnc/commit/3d926d87f14ada9dea313c2989ee8f24f0e54e0c
On Thu, 28 Sept 2023 at 00:41, Alec Ari via Emc-developers
wrote:
> Would anyone be able to test LinuxCNC against the changes I'll be making to
> RTAI? I can only test the sims, I don't have any actual CNC hardware
> available.
I can.
Do I need to re-build RTAI? My current git pull is master
Hi all,
Rene said I should switch RTAI to GNU11:
https://github.com/LinuxCNC/linuxcnc/commit/3d926d87f14ada9dea313c2989ee8f24f0e54e0c#commitcomment-128557906
I suppose the above commit could be reverted.
Would anyone be able to test LinuxCNC against the changes I'll be making to
RTAI? I can
Moving forward, I can merge that C11 patch into RTAI so we don't have to worry
about C89/gnu89 anymore and you can just code how you please :-)
I haven't noticed any regressions with the little testing I did but there could
be something down road. I guess it depends on how often/how much C11
On Wed, 20 Sept 2023 at 23:27, Alec Ari via Emc-developers
wrote:
>
> I don't know if this code is right, I just copied and pasted the 32 versions
> and made 64 versions where required.
I have been struggling with raster.comp, or more specifically with its
test. I think I need to reboot into a
I don't know if this code is right, I just copied and pasted the 32 versions
and made 64 versions where required.
https://github.com/LinuxCNC/linuxcnc/pull/2650
Undefined symbols are gone, please review before merging!
Alec
___
Emc-developers
On Wed, 20 Sept 2023 at 18:17, Alec Ari via Emc-developers
wrote:
>
> Since the fix is as simple as moving an, "i" around, I say we just do that.
> Problem solved.
And done, on 2.9. Merged into a local branch of master to be pushed after
> If there is no way to have raster.comp not depend
So, there are two ways of building kernel modules with GNU11 instead of gnu89
or C99.
1.) Do it in RTAI:
https://github.com/NTULINUX/RTAI/commit/a649bbb40fad9299ba31285276d9204df2f222d9
2.) Do it in LinuxCNC:
https://github.com/NTULINUX/linuxcnc/commit/a76b69f7e66f7a3831be655ea3dde4590502a175
On Wed, 20 Sept 2023 at 18:05, Chad Woitas via Emc-developers
wrote:
> For what its worth, I’ve actually stopped running linuxcnc on a realtime
> kernel since 5.14 for most of my development machines, and they’re running
> better than expected with sub 1ms cycle times on an i5-6600.
Not
Since the fix is as simple as moving an, "i" around, I say we just do that.
Problem solved.
Even with a Xenomai 4/Dovetail/EVL port, you can't mix C library userspace
headers with kernel space. The musl C library port I did with RTAI's current
infrastructure is special because without it, you
ebster<mailto:r...@vehiclemods.net.au>
Sent: September 20, 2023 3:48 AM
To: EMC developers<mailto:emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't see why limit_axis.comp can't be revised to declare the int i; at
the top of the p
I don't see why limit_axis.comp can't be revised to declare the int i; at
the top of the procedure which I was taught was best practice anyway. That
would solve the C11/C89 issue.
raster.comp needs stdlib.h for some of the conversion functions. It also
should include string.h for strchr() so it's
On Wed, 20 Sept 2023 at 01:17, Alec Ari wrote:
> Seriously though, the proper way to fix this is to not use c11/gnu11 with
> 4.19 or 5.4 kernel sources.
I think that the problem is that folk writing HAL components for
LinuxCNC don't realise that they are writing "Kernel sources for
kernel
See the links I posted, they link to the lines in the kernel Makefile, that's
where the gnu89 is coming from.
Seriously though, the proper way to fix this is to not use c11/gnu11 with 4.19
or 5.4 kernel sources. It probably won't even work and shouldn't be tried. 4.19
and 5.4 use gnu89.
On Tue, 19 Sept 2023 at 23:12, Alec Ari via Emc-developers
wrote:
> LinuxCNC may set -std=gnu11 however that covers userspace only (i.e.
> PREEMPT_RT builds.)
>
> All kernel modules are still gnu89.
Do you know where that is configured? And can it be changed?
According to
The kernel switched to GNU11 with 5.18. RTAI is still 4.19 and 5.4, meaning all
kernel space needs to be gnu89:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-4.19.y=dd5638bc06a6bf3f5ca1a134960911dc49484386#n375
On Mon, 18 Sept 2023 at 13:40, Rene Hopf via Emc-developers
wrote:
> linux kernel uses gnu11, and so should we.
> https://www.kernel.org/doc/html/latest/process/programming-language.html
Everywhere I can find std= on github it is gnu11.
But I sometimes see that error message above, and think
On 18.09.23 13:14, andy pugh wrote:
On Sun, 17 Sept 2023 at 02:48, Alec Ari via Emc-developers
wrote:
hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations are
only allowed in C99 or C11 mode
Is there a good reason for the RTAI config to force C90 (?) mode? I
looked
On Sun, 17 Sept 2023 at 02:48, Alec Ari via Emc-developers
wrote:
> hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations
> are only allowed in C99 or C11 mode
Is there a good reason for the RTAI config to force C90 (?) mode? I
looked for where this happens a bit ago and
Meant to say, if you set CONFIG_FRAME_WARN to 0, the last error I posted should
go away.
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
What's really odd is that src/objects/hal/components/raster.c:14:10: fatal
error: stdlib.h: No such file or directory
stdlib.h is part of the C library, it shouldn't be looking for stdlib.h in
kernel space, at all, ever.
Alec
___
Emc-developers
37 matches
Mail list logo
