Walt Mankowski via plug on 3 Jan 2022 14:58:50 -0800 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [PLUG] Very weird error with make (constant segfaulting) |
The only person who's posted a main function is me, and that will have absolutely no effect on make. It's not a syntax error, and if some compiler setting flags it as a warning that's exactly the sort of thing that make is supposed to catch. On Mon, Jan 03, 2022 at 02:41:14PM -0800, Charles Hathaway via plug wrote: > Small nit; there's no return on your main function. What happens if you add > one? > > Does this happen with other programs? > > Charles > > On Mon, Jan 3, 2022, 14:26 Mark Bergman via plug <plug@lists.phillylinux.org> > wrote: > > > In the message dated: Mon, 03 Jan 2022 09:11:29 -0500, > > The pithy ruminations from Lynn Bradshaw via plug on > > [[PLUG] Very weird error with make (constant segfaulting)] were: > > => So I was about to start compiling some software project and make > > => segfaulted. I thought it might have been a fluke, so I tried again, > > > > Was it truely the "make" executable that segfaulted, or was it part of > > the compile chain called by Make (lex, yacc, gcc, ld) that segfaulted? > > > > Was it actually during compilation (indicating a likely hardware error > > or corrupt tool or library), or was it after compilation, ie., if the > > Makefile ran tests of the executable, indicating that the binaries > > produced aren't compatible with the hardware & OS? > > > > => same thing, repeatedly. Tried backing out of the shell or tmux > > > > Repeatedly? At the same step in compilation each time? Does the problem > > happen when compiling other software packages? > > > > I've seen compilation fail with very odd errors (in old versions of > > cc/gcc) when the source code had non-ASCII characters or was corrupt. > > > > Get another copy of the package & be sure that the code is valid (not > > a corrupted download, UTF-8 issue, etc). > > > > I'd verify the installed packages ("make" and other parts of the build > > chain, the libraries used for compilation, etc) and possibly reinstall. > > > > => altogether, restarting the terminal emulator, using bash (normal > > => choice is zsh on this one) and ultimately only restarting the entire > > => machine fixed it. > > > > Changing your shell will have almost no affect on this ("almost", except > > for unlikely instances where a interactive setting -- shell variable, > > usually -- caused the issue, and that setting isn't enabled in a shell > > startup file). > > > > => > > => I don't think it's dodgy hardware because a) only make has ever done > > => this (I think it's the second or third time now) and b) the hardware > > => in question is reasonably new and also c) the uptime that of course > > => got wiped out was nearly three weeks. The one hardware possibility > > => that comes to mind is that it's a Raspberry Pi (four cores, ARMv7 > > => Processor rev 3 (v7l)) and something just slipped under the radar that > > => maybe wouldn't have if it had been an Intel or Intel-like processor. > > > > > > Compilation is a pretty stressful operation -- to the point where kernel > > compilation was often used as part of a system burn-in or acceptance > > test. It will often expose problems in marginal RAM or CPUs, issues > > that only appear when an component is at high temperature, or a marginal > > powersupply (a frequent RPI issue). > > > > Are you using an SD card for storage? I've see with my 5 (6?) PIs that > > the SD card is the weakest link -- with frequent corruption. I don't > > care much, as the PIs are easily reimaged and reconfigured and I don't do > > compilation there, but you may find that a better class of SD card helps. > > > > If you're using external storage (SSD via USB, for example), carefully > > check the RPI power supply, cooling, and use a separate power source > > for the storage device if possible. > > > > However, if it is a hardware problem, you can probably cause it through > > other CPU/RAM intensive operations, and processes other than just "make" > > are likely to show faults as well. > > > > > > -- > > Mark Bergman Biker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1 > > Stagehand > > '94 Yamaha GTS1000A^1 2015 Aprilia > > Caponord > > https://www.flickr.com/photos/rmsppu > > > > ___________________________________________________________________________ > > Philadelphia Linux Users Group -- > > http://www.phillylinux.org > > Announcements - > > http://lists.phillylinux.org/mailman/listinfo/plug-announce > > General Discussion -- > > http://lists.phillylinux.org/mailman/listinfo/plug > > > ___________________________________________________________________________ > Philadelphia Linux Users Group -- http://www.phillylinux.org > Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce > General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
Attachment:
signature.asc
Description: PGP signature
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug