Try the dependency list on this page.
https://www.qtpyvcp.com/install/bullseye.html
These instructions are good!
Debian would be the preferred platform I think. I have been using Debian 11
and more or less following directions on that page for quite a while.
Debian 11 is Python3 only which is a good thing for master. Buster gets a
bit mixed up with Python 2 and 3 and Master branch needs Python 3 (and 2.8
needs Python 2)
Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au
On Sat, 12 Feb 2022 at 16:30, Andy Howell <a...@gamubaru.com> wrote:
>
> On 2/11/22 21:29, Jared McLaughlin wrote:
> > Andy,
> >
> > I'm working on compiling in a clean install on a VM of Ubuntu 20.04. I'm
> > going to use clang just to check compiler coverage.
> >
> > I'm noticing a bunch of build deps - which is not unexpected for a system
> > of this size. However, it makes me wonder if something similar to conan
> > would make sense to automate the build more.
> >
> > Or is there something in debian, since we know which packages we need,
> that
> > will auto-install them?
> >
> > I agree that getting a 'clean compile' with no warnings is a noble goal.
> > That said, I am remiss to make a quick fix without really knowing the
> > ramifications. I'm even less happy about silencing warnings. In either
> > case, we are silencing a legitimate warning system and possibly
> introducing
> > silent bugs. Silent bugs are worse than issues we are aware of. I'll dig
> in
> > to it more once I actually get a build.
>
> Jared,
>
> Definitely don't want to introduce silent bugs. Being new here, that
> would be a terrible way to start! That is why I think it would be good
> for us to tag-team. Get two sets of eyes on it before we ask anyone to
> review it.
>
> I didn't have any problems building once I got the dependencies.
> dpkg-checkbuilddeps found most of them, but there were a few it missed.
> I should have written those down.
>
> Andy
>
> > Jared
> >
> > On Fri, Feb 11, 2022 at 4:41 PM Andy Howell <a...@gamubaru.com> wrote:
> >
> >> On 2/11/22 09:10, Jared McLaughlin wrote:
> >>> Andy,
> >>>
> >>> I'm a reasonable C/C++ programmer as well. I'd be willing to be a
> hunting
> >>> partner if you want to go bug hunting together. Did you build on a
> fresh
> >> OS
> >>> install?
> >>>
> >>> Jared
> >> Jared,
> >>
> >> No, I'm just building this on my Ubuntu 21.10 laptop. I'm using gcc
> >> 11.2.0 to compile it. That may spit out more warnings that what Buster
> >> uses. I don't know.
> >>
> >> I'd welcome help on it. I'm open to better ways to handle errors like
> this:
> >>
> >> Compiling hal/user_comps/mb2hal/mb2hal_init.c
> >> In file included from /usr/include/string.h:519,
> >> from hal/user_comps/mb2hal/mb2hal.h:4,
> >> from hal/user_comps/mb2hal/mb2hal_init.c:1:
> >> In function ‘strncpy’,
> >> inlined from ‘init_mb_links’ at
> >> hal/user_comps/mb2hal/mb2hal_init.c:717:17:
> >> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:95:10: warning:
> >> ‘__builtin_strncpy’ output may be truncated copying 16 bytes from a
> >> string of length 16 [-Wstringop-truncation]
> >> 95 | return __builtin___strncpy_chk (__dest, __src, __len,
> >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> 96 | __glibc_objsize (__dest));
> >> | ~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> The code in question, with my 'fix' is:
> >>
> >> else { //tcp
> >> strncpy(this_mb_link->lp_tcp_ip,
> >> this_mb_tx->cfg_tcp_ip, sizeof(this_mb_tx->cfg_tcp_ip)-1);
> >> + this_mb_link->lp_tcp_ip[sizeof(this_mb_tx->cfg_tcp_ip)-1] ='\0';
> >> this_mb_link->lp_tcp_port=this_mb_tx->cfg_tcp_port;
> >>
> >> Terminating the string makes the compiler happy, even though is only
> >> required when the source string is exactly n bytes long.
> >>
> >> That solution works. It does not cope with possible truncation of the
> >> source string. I don't know the code enough to know which areas are time
> >> sensitive, so I wasn't thinking of more CPU intensive fixes like
> >> computing all the lengths and error checking.
> >>
> >> My main aim is to reduce the warnings, so that when new warnings pop up,
> >> they get attention and dwelt with quickly. Even if its only tell the
> >> compiler "don't worry, we know what we're doing."
> >>
> >> Andy
> >>
> >>
> >>> On Thu, Feb 10, 2022, 4:50 PM Andy Howell <a...@gamubaru.com> wrote:
> >>>
> >>>> On 2/10/22 06:10, Steffen Möller wrote:
> >>>>> On 10.02.22 07:28, Phill Carter wrote:
> >>>>>>> On 10 Feb 2022, at 4:14 pm, Andy Howell <a...@gamubaru.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/9/22 14:46, andy pugh wrote:
> >>>>>>>> On Wed, 9 Feb 2022 at 20:21, Andy Howell <a...@gamubaru.com>
> wrote:
> >>>>>>>>
> >>>>>>>>> My background is in c/c++ development under UNIX/Linux. I know
> bit
> >> of
> >>>>>>>>> python. I don't have the experience to work on the low level
> >>>>>>>>> internals.
> >>>>>>>> How about this one?
> >>>>>>>> https://github.com/LinuxCNC/linuxcnc/issues/1438
> >>>>>>>>
> >>>>>>>> A text search on the pin name would find the right part of the
> code,
> >>>>>>>> and would let you find where the associated internal variable is
> >>>>>>>> updated.
> >>>>>>>>
> >>>>>>>> (This is internals, but with code to copy from)
> >>>>>>> Thanks. That sounds like a good problem to start with. I will have
> a
> >>>>>>> look at the code and comment under the issue.
> >>>>>> I do have a PR ready to submit but I am happy to hold off.
> >>>>> That sounds so nice and so wrong at the same time. I suggest to
> submit
> >>>>> the PR and you have already found a reviewer.
> >>>>>
> >>>>> @Andy, I am currently on a mission to render the C/C++ sources
> >>>>> cppcheck-clean. You see a few PRs on this already - and one issue
> that
> >> I
> >>>>> could not solve with a quick patch that I think is a bug. I
> personally
> >>>>> use this to get acquainted with the code base a bit more - have
> started
> >>>>> with src/hal/* and src/emc/* and have just about completed that, I
> >>>>> think. But there is more.
> >>>>>
> >>>>> Many thanks and greetings
> >>>>> Steffen
> >>>>>
> >>>> Steffen,
> >>>>
> >>>> I could certainly work on that. I just compiled LinuxCNC for the first
> >>>> time in a very long time. There were lots of compiler warnings,
> >>>> particularly around strncpy and snprintf. I think those would be worth
> >>>> looking into. It would be nice to fix the code to remove the warnings,
> >>>> or turn warnings off where needed when they are clearly a false
> >>>> positive. For example,
> >>>>
> >>>> hal/user_comps/mb2hal/mb2hal_init.c:187:55: warning: ‘%02d’ directive
> >>>> output may be truncated writing between 2 and 10 bytes into a region
> of
> >>>> size 7 [-Wformat-truncation=]
> >>>> 187 | snprintf(section, sizeof(section)-1,
> "TRANSACTION_%02d",
> >>>> mb_tx_num);
> >>>> | ^~~~
> >>>> hal/user_comps/mb2hal/mb2hal_init.c:187:42: note: directive argument
> in
> >>>> the range [0, 2147483647]
> >>>> 187 | snprintf(section, sizeof(section)-1,
> "TRANSACTION_%02d",
> >>>> mb_tx_num);
> >>>> | ^~~~~~~~~~~~~~~~~~
> >>>>
> >>>> The local 'section' buffer there is 20 bytes. Although it might never
> be
> >>>> an issue in practice, increasing the buffer size will make sure it
> never
> >>>> is and remove the warning. Maybe we can get to a point where we can
> >>>> treat warnings as errors.
> >>>>
> >>>> Does that sound worth pursuing?
> >>>>
> >>>>> _______________________________________________
> >>>>> Emc-developers mailing list
> >>>>> Emc-developers@lists.sourceforge.net
> >>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>>> _______________________________________________
> >>>> Emc-developers mailing list
> >>>> Emc-developers@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>>>
> >>> _______________________________________________
> >>> Emc-developers mailing list
> >>> Emc-developers@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >> _______________________________________________
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> > _______________________________________________
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
