Just for fun I tried to compile brl-cad (a constructive solid geometry modeling system) on my Pi4. To my surprise, it came close(ish) to working, I think.
The configure stage ran to completion, and make got to the ~90% mark before reporting:
[ 89%] Linking C shared library ../../../libexec/ged/libged-otranslate.so /home/bob/brlcad-code/src/libged/overlay/overlay.c: In function ?ged_overlay_core?: /home/bob/brlcad-code/src/libged/overlay/overlay.c:245:63: error: passing argument 5 of ?icv_image_size ? from incompatible pointer type [-Wincompatible-pointer-types] if (!icv_image_size(NULL, 0, (size_t)sbuf.st_size, type, &lwidth, &lheight)) {
Has anybody else tried this, and gotten past? It looks as if maybe the c compiler is being more strict than absolutely necessary (or maybe expected by the developers).
It's probably a sign that you're building against a different version of libged than has been tested/supported. Otherwise perhaps it's a newer gcc version treating a parameter such as "-pedantic-errors" with more pedantry, in which case you might just be able to remove that option from the Makefile and it might run alright.
Causes all compilation warnings for C code to be treated as errors. This is now the default for BRL-CAD source code, and developers should address issues discovered by these flags whenever possible rather than disabling strict mode.
so at least some checking is relaxed already. Tinkering with the makefiles manually is exceedingly unlikely to work without detailed guidance from the experts. I'm not even an amateur.....
I tried and had the same error on my 3B+. I tried a couple of things to pass -Wno-incompatible-pointer-types but didn't get it right but then just tried passing -DBRLCAD_ENABLE_COMPILER_WARNINGS=OFF to cmake and that made it pass. That option removed at least -pedantic and
-pedantic-errors from CFLAGS and/or CXXFLAGS and that warning was then just a warning.
Tests pass except for two in the regress suite and they fail due to timeout. However, mged just crashes when I try to start it.
bu_semaphore_free(): pthread_mutex_destroy() failed on [6] of [10]
At this point I've updated sources and am starting over with make clean. There were a few updates in libspr, perhaps that'll help. Then again, maybe it'll make things worse 8-)
Given, how old BRL CAD already is, it is always amazing how good that stuff is, and it is very much worth spending an hour or two figuring out ow to make it work on all sorts of machines.
On the Mac Homebrew has it, and perhaps it may be worthwhile looking into how they compile it now?
el
On 29/09/2020 02:27, bob prohaska wrote: [...]
--
If you want to email me, replace nospam with el
Yes, I had similar messages. BTW, are you directly connected to the Raspberry Pi or over network? I tried the build on a remote Debian 10 shell machine too. Mged doesn't run there either but the errors are about OpenGL which makes sense, OpenGL doesn't really work over the network. I thought maybe that's the problem with Raspberry Pi too but haven't tried.
So if you're not directly connected, it's worth reporting this as a bug. I may try that too later.
I have for many many years, kept Gary Perlman's |stat
formatting link
on every computer I use and it only ever required a tiny bit of work a few years back to make it work on the mac, but it is equally awesome how robust that stuff is...
Compiled on a fully up-to-date raspbian buster 4GB and it didn't even blink...
el
[...]
--
If you want to email me, replace nospam with el
On Tue, 29 Sep 2020 00:27:34 -0000 (UTC), bob prohaska declaimed the following:
That looks like some significant code error... Attempt to allocate a chunk of memory of SIZE 0!
It might be worth studying that log to see if you can determine where in the code this call occurs, and from there track down whatever computation is being used to determine the size to be allocated. (Note: that error message actually comes from a level below bu_malloc -- both bu_malloc and bu_calloc use the same alloc() function, with a parameter identifying which m/c mode to run in --
formatting link
).
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
The only things I can recgonize as errors in the logfile are a couple of "permission denied" errors apparently caused by the backtrace generation process. I don't think that's relevant, but perhaps I should point out that the build and run were done as a regular user, with only the install using root credentials.
There's already a support request in to the brlcad project, to which I've added my $.02 so hopefully somebody will take note. Someday.....
Its easy enough to see where malloc is called with a zero pointer, evidently because calloc, which called it wants zero 4 byte items, but I lose it at that point thanks to so much stuff being
So all I'd suggest are: can you turn off crash dump optimisation and is it possible this is connected with a screwed up configuration file? There seem to be a lot of zero values in what looks like system parameters.
Couldn't find any obvious hints for turning off crash dump optimization.
I did try starting gdb and running mged manually:
(gdb) file mged Reading symbols from mged...done. (gdb) run Starting program: /usr/local/bin/mged mged [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". BRL-CAD Release 7.32.1 Geometry Editor (MGED) Mon, 28 Sep 2020 17:06:52 -0700, Compilation 3 bob@raspberrypi
Create new database (y|n)[n]? y ERROR: alloc size=0 (cnt=0, sz=4) dm name array
ERROR: bu_malloc(0)
ERROR: bu_malloc(0)
Saving stack trace to mged-20404-bomb.log [Detaching after fork from child process 20407]
Program received signal SIGINT, Interrupt.
0xb4589664 in __GI___select (nfds=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0xbeffeeb8) at ../sysdeps/unix/sysv/linux/select.c:41
41 ../sysdeps/unix/sysv/linux/select.c: No such file or directory. (gdb) bu_semaphore_free(): pthread_mutex_destroy() failed on [6] of [12]
(gdb) bt #0 0xb4589664 in __GI___select (nfds=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0xbeffeeb8) at ../sysdeps/unix/sysv/linux/select.c:41 #1 0xb4686da8 in bu_snooze (useconds=) at /home/bob/brlcad-code/src/libbu/snooze.c:45 #2 0xb46c6a78 in bu_backtrace (fp=0x3a80f0) at /home/bob/brlcad-code/src/libbu/backtrace.c:502 #3 0xb46c7b20 in bu_crashreport ( filename=filename@entry=0xb5e1a474 "mged-20404-bomb.log") at /home/bob/brlcad-code/src/libbu/crashreport.c:101 #4 0xb46c80cc in bu_bomb (str=) at /home/bob/brlcad-code/src/libbu/bomb.c:180 #5 0xb46bdfd8 in alloc (str=0xacbec "dm name array", sz=4, cnt=0, type=CALLOC) at /home/bob/brlcad-code/src/libbu/malloc.c:108 #6 bu_calloc (nelem=0, elsize=4, str=) at /home/bob/brlcad-code/src/libbu/malloc.c:174 #7 0x0001cf74 in get_attached () at /home/bob/brlcad-code/src/mged/attach.c:507 #8 main (argc=1, argv=0xbefff3e8) at /home/bob/brlcad-code/src/mged/mged.c:1554 (gdb)
It's not even Greek to me, if it makes sense to somebody else any hints appreciated!
Having so much stuff 'optimised out' isn't good, but even with the more readable Java stack dumps, all I ever do with them is to look at the top few entries to see which class in my program contained the error.
I much prefer using a tracing system, i.e. I put trace events in my code that are enabled from the command line, because often the triggering event is a few steps back along the timeline from the code that crashed. A trace log shows you that clearly while a stack dump often can't.
The last time I used Java heavily for work I was seriously considering using aspect weaving to hook a call trace log into the code dumping into a circular buffer.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Been there, done that as well. It words equally well in COBOL, C and Java.
FWIW the first time I saw a circular buffer in use was when I was sysadmin for George 3, the ICL mainframe OS. Its design philosophy was to throw a GEOERR, dump diagnostics and quit if it hit a major problem. It used two circular buffers: one very fine-grained to show exactly what happened, the other coarse enough to show how the system had arrived at the GEOERR. IOW the fine-grained buffer covered the last 3-4 entries in the coarse buffer. Made trouble-shooting a breeze, so I've tended to leave switchable tracing statements in live systems ever since. Its paid off: diagnosing faults in production code becomes much easier. I make using a circular buffer configurable too, mainly because I've found its most useful for diagnosing rare errors in long-running non-interactive processes without drowning people in megabytes if trace log.
IME a good approach in interactive processes is to make tracing controllable by more experienced users. If they have a problem they can talk to support and, if that doesn't resolve the problem, switch tracing on, repeat what they did and turn it off again. That keeps everybody happy: users because they know the support team will be on the case once they've retrieved the log and support because they've got an accurate record of what happened and why.
Anyways, I noticed something that kind of explains the issue. When cmake finishes it prints out this:
X11 support (optional) .............: OFF
So, it doesn't find X11 which would be needed for a GUI and mged is a GUI app... I tried to fix this by editing FindX11.cmake wherein X11 finding for Linux is handled in a very PC-centric way and now it says it found X11. I'll see if that helps any once the build completes.
Looks like I managed to build something that at least starts up. Not everything seems to work, I tried a simple tutorial but when it came time to ray trace some simple objects I got error messages only. My cmake options were:
set(32BIT_DIRS "/usr/lib32/X11;/usr/lib32;/usr/lib/i386-linux-gnu;/usr/lib/arm-linux-gnueabihf") if(EXISTS "/usr/lib64" OR NOT EXISTS "/usr/lib32") set(32BIT_DIRS ${32BIT_DIRS} /usr/lib/X11 /usr/lib) endif(EXISTS "/usr/lib64" OR NOT EXISTS "/usr/lib32")
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.