brl-cad on a Pi4?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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).  

Thanks for reading, and any thoughts....

bob prohaska


Re: brl-cad on a Pi4?
Quoted text here. Click to load it

On the brl-wiki they ask for any failures to be reported to them. They  
might be able to help you :-)  

Re: brl-cad on a Pi4?
Quoted text here. Click to load it

Already done. It turns out I'm second to pose the question, with no replies yet.
https://sourceforge.net/p/brlcad/support-requests/123/

It's fairly unlikely the brlcad folks pay much attention to the Pi.  

Thanks for reading,

bob prohaska



Re: brl-cad on a Pi4?
Quoted text here. Click to load it

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.

--  
__          __
#_ < |\| |< _#

Re: brl-cad on a Pi4?
Quoted text here. Click to load it

There's a Cmake switch named  
--- BRLCAD_ENABLE_STRICT ---

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.

Aliases:  ENABLE_STRICT, ENABLE_STRICT_COMPILE, ENABLE_STRICT_COMPILE_FLAGS

but  cmake is invoked with  
-DBRLCAD_ENABLE_STRICT=OFF  

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.....

Thanks for reading,

bob prohaska




Re: brl-cad on a Pi4?

Quoted text here. Click to load it

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.

Re: brl-cad on a Pi4?
Quoted text here. Click to load it

Using  

cmake .. -DBRLCAD_ENABLE_STRICT=OFF -DBRLCAD_ENABLE_COMPILER_WARNINGS=OFF -DCMAK
E_BUILD_TYPE=Release

and re-running make seems to have let the compile finish, but as you observe
mged won't run:

bob@raspberrypi:~/brlcad-code/build $ mged
BRL-CAD Release 7.32.1  Geometry Editor (MGED)
    Mon, 28 Sep 2020 16:16:25 -0700, Compilation 2
    bob@raspberrypi

ERROR: alloc size=0 (cnt=0, sz=4) dm name array

ERROR: bu_malloc(0)

ERROR: bu_malloc(0)

Saving stack trace to mged-5459-bomb.log

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-)

Thanks very much for posting!

bob prohaska


Re: brl-cad on a Pi4?
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:
[...]
Quoted text here. Click to load it


--  
If you want to email me, replace nospam with el


Pipe State (was was brl-cad on a Pi4?)
And to follow myself :-)-O

I have for many many years, kept Gary Perlman's |stat

     https://garyperlman.com/stat/

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


Re: brl-cad on a Pi4?

Quoted text here. Click to load it

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.


Re: brl-cad on a Pi4?
Quoted text here. Click to load it

On the HDMI console.  

Quoted text here. Click to load it

Sorry, but not following here: Over the network _is_ a bug?  

Thanks for posting!

bob prohaska



  

Re: brl-cad on a Pi4?

Quoted text here. Click to load it

No, connected directly.

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.


Re: brl-cad on a Pi4?
declaimed the following:

Quoted text here. Click to load it

    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 --
https://brlcad.org/docs/doxygen-r64112/d6/dcd/malloc_8c_source.xhtml ).



--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: brl-cad on a Pi4?
Quoted text here. Click to load it

I've put the backtrace at
http://www.zefox.net/~fbsd/rpi4/mged-9973-bomb.log
if anybody wants to take a look.  

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.....

Thanks to everyone for reading and replying!

bob prohaska


Re: brl-cad on a Pi4?
On Tue, 29 Sep 2020 20:34:06 +0000, bob prohaska wrote:

Quoted text here. Click to load it
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 <optimised out>

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.

HTH


--  
Martin    | martin at
Gregorie  | gregorie dot org


Re: brl-cad on a Pi4?
Quoted text here. Click to load it
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=<optimized out>) 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 <tracefile> "mged-20404-bomb.log")
    at /home/bob/brlcad-code/src/libbu/crashreport.c:101
#4  0xb46c80cc in bu_bomb (str=<optimized out>) at /home/bob/brlcad-code/src/libbu/bomb.c:180
#5  0xb46bdfd8 in alloc (str=0xacbec "dm name array", sz=4, cnt=0, typeCA%LLOC)
    at /home/bob/brlcad-code/src/libbu/malloc.c:108
#6  bu_calloc (nelem=0, elsize=4, str=<optimized out>) 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!

Thanks for reading,

bob prohaska


Re: brl-cad on a Pi4?
On Wed, 30 Sep 2020 06:26:48 +0000, bob prohaska wrote:

Quoted text here. Click to load it
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.
    

--  
Martin    | martin at
Gregorie  | gregorie dot org


Re: brl-cad on a Pi4?
On Wed, 30 Sep 2020 07:13:30 -0000 (UTC)

Quoted text here. Click to load it

    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
We've slightly trimmed the long signature. Click to see the full one.
Re: brl-cad on a Pi4?
On Wed, 30 Sep 2020 09:51:27 +0100, Ahem A Rivet's Shot wrote:

Quoted text here. Click to load it

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.


--  
Martin    | martin at
Gregorie  | gregorie dot org


Re: brl-cad on a Pi4?

Quoted text here. Click to load it

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:

cmake <src dir> -DBRLCAD_ENABLE_STRICT=NO -DBRLCAD_ENABLE_COMPILER_WARNINGS=NO -DBRLCAD_BUNDLED_LIBS=AUTO -DCMAKE_BUILD_TYPE=Release

To make it detect X11 and OpenGL I had to add
/usr/lib/arm-linux-gnueabihf in two files, FindX11.cmake and
FindGL.cmake. Here's the diffs:

$ diff -u FindX11.cmake.org FindX11.cmake    
--- FindX11.cmake.org   2020-09-30 17:12:37.550501468 +0300
+++ FindX11.cmake       2020-09-30 21:43:24.734950303 +0300
@@ -169,7 +169,7 @@
       set(64BIT_DIRS $ /usr/lib/X11 /usr/lib)
     endif(EXISTS "/usr/lib32" OR NOT EXISTS "/usr/lib64")
   else(SEARCH_64BIT)
-    set(32BIT_DIRS "/usr/lib32/X11;/usr/lib32;/usr/lib/i386-linux-gnu")
+    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 $ /usr/lib/X11 /usr/lib)
     endif(EXISTS "/usr/lib64" OR NOT EXISTS "/usr/lib32")

$ diff -u FindGL.cmake.org FindGL.cmake  
--- FindGL.cmake.org    2020-09-30 17:18:55.059802235 +0300
+++ FindGL.cmake        2020-09-30 21:42:35.315081010 +0300
@@ -172,7 +172,7 @@
   if(SEARCH_64BIT)
     set(64BIT_DIRS "/usr/lib64/X11;/usr/lib64;/usr/lib/x86_64-linux-gnu")
   else(SEARCH_64BIT)
-    set(32BIT_DIRS "/usr/lib/X11;/usr/lib;/usr/lib/i386-linux-gnu")
+    set(32BIT_DIRS "/usr/lib/X11;/usr/lib;/usr/lib/i386-linux-gnu;/usr/lib/arm-linux-gnueabihf")
   endif(SEARCH_64BIT)
  
   set(OPENGL_LIB_SEARCH_PATH

Site Timeline