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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2020-09-26, bob prohaska <bp@www.zefox.net> wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> wrote:

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

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.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Jim Jackson <jj@franjam.org.uk> wrote:

On 2020-09-26, bob prohaska <bp@www.zefox.net> wrote:

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

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Computer Nerd Kev <not@telling.you.invalid> wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> writes:

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

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Anssi Saari <as@sci.fi> wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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:
[...]

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> writes:

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]

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 29 Sep 2020 00:27:34 -0000 (UTC), bob prohaska <bp@www.zefox.net> declaimed the following:

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

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
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

On Tue, 29 Sep 2020 00:27:34 -0000 (UTC), bob prohaska <bp@www.zefox.net> declaimed the following:

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

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 29 Sep 2020 20:34:06 +0000, bob prohaska wrote:

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

On Tue, 29 Sep 2020 00:27:34 -0000 (UTC), bob prohaska
<bp@www.zefox.net>
declaimed the following:

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

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

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

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Anssi Saari <as@sci.fi> wrote:

bob prohaska <bp@www.zefox.net> writes:

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]

Yes, I had similar messages. BTW, are you directly connected to the
Raspberry Pi or over network?

On the HDMI console.

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.

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

Thanks for posting!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 30 Sep 2020 06:26:48 +0000, bob prohaska wrote:

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.


--
Martin | martin at
Gregorie | gregorie dot org

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Martin Gregorie <martin@mydomain.invalid> wrote:

On Tue, 29 Sep 2020 20:34:06 +0000, bob prohaska wrote:

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

On Tue, 29 Sep 2020 00:27:34 -0000 (UTC), bob prohaska
<bp@www.zefox.net>
declaimed the following:

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

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

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

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

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, type=CALLOC)
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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 30 Sep 2020 07:13:30 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:

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/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 30 Sep 2020 09:51:27 +0100, Ahem A Rivet's Shot wrote:

On Wed, 30 Sep 2020 07:13:30 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> writes:

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

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> writes:

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.

Using

cmake .. -DBRLCAD_ENABLE_STRICT=OFF -DBRLCAD_ENABLE_COMPILER_WARNINGS=OFF

-DCMAK

E_BUILD_TYPE=Release

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 ${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 ${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")
+

Anssi Saari <as@sci.fi> wrote:

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.

Looks to me like you've got it. With your instructions and some notes in doc/README.Linux, Revision: 77316 compiled, made benchmarks, runs and raytraces. The benchmarks report:


These numbers seem to indicate that this machine is approximately 7234 times faster than the reference machine being used for comparison, a VAX 11/780 running 4.3 BSD named VGR. These results are in fact approximately 3.86
orders of magnitude faster than the reference.

My order of actions was not systematic, so it's not clear exactly
which actions were necessary. The doc/README.Linux notes say:

Ubuntu/Debian
-------------

Users of Ubuntu, Debian, and other similar packaging distributions of
Linux will need to ensure that a few essentials are in place before
you will be able to compile BRL-CAD.

Following the build instructions in the INSTALL file. You will need:

gcc (6+, e.g. 6.0.3)
g++ (6+, e.g. 6.0.3)
make (e.g. gnu make 3.8.0)
cmake (3.0.2 or newer)

All three of those have implicit dependencies on other packages.

You will also want to make sure that you have the X11 development
headers installed:

apt-get install xserver-xorg-dev libx11-dev libxi-dev libxext-dev

Other development packages needed to build on Debian-based platforms:

for building the Tcl/Tk libraries: libfontconfig-dev

for OpenGL: libglu1-mesa-dev

It seems possible at least some of these are redundant, but I can't
tell which..... All installed without any obvious complaints.

There are still no updates/replies to the support request on SourceForge at https://sourceforge.net/p/brlcad/support-requests/123/
A followup from you (since you fixed it) or me (if you don't want to bother) might help things along.

With my thanks!

bob prohaska



: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 ${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 ${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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Fri, 2 Oct 2020 03:38:49 -0000 (UTC), bob prohaska <bp@www.zefox.net> declaimed the following:

Following the build instructions in the INSTALL file. You will need:

gcc (6+, e.g. 6.0.3)
g++ (6+, e.g. 6.0.3)
make (e.g. gnu make 3.8.0)
cmake (3.0.2 or newer)

All three of those have implicit dependencies on other packages.

You will also want to make sure that you have the X11 development
headers installed:

apt-get install xserver-xorg-dev libx11-dev libxi-dev libxext-dev

Other development packages needed to build on Debian-based platforms:

for building the Tcl/Tk libraries: libfontconfig-dev

for OpenGL: libglu1-mesa-dev

It seems possible at least some of these are redundant, but I can't
tell which..... All installed without any obvious complaints.

Off-hand, nothing you least appears to be redundant...

gcc is the plain C compiler
g++ is the C++ compiler
make is the build system
cmake is a system to build makefiles for use by make

The X11 stuff is the low-level core for interfacing to the X-Window protocol.

Tcl/Tk is a framework for developing GUI applications, and uses X-Window at its base

OpenGL is a standard for 2D/3D graphics rendering, often using hardware acceleration.


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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

On Fri, 2 Oct 2020 03:38:49 -0000 (UTC), bob prohaska <bp@www.zefox.net> declaimed the following:

Following the build instructions in the INSTALL file. You will need:

gcc (6+, e.g. 6.0.3)
g++ (6+, e.g. 6.0.3)
make (e.g. gnu make 3.8.0)
cmake (3.0.2 or newer)

All three of those have implicit dependencies on other packages.

You will also want to make sure that you have the X11 development
headers installed:

apt-get install xserver-xorg-dev libx11-dev libxi-dev libxext-dev

Other development packages needed to build on Debian-based platforms:

for building the Tcl/Tk libraries: libfontconfig-dev

for OpenGL: libglu1-mesa-dev

It seems possible at least some of these are redundant, but I can't
tell which..... All installed without any obvious complaints.

Off-hand, nothing you least appears to be redundant...

gcc is the plain C compiler
g++ is the C++ compiler
make is the build system
cmake is a system to build makefiles for use by make

The X11 stuff is the low-level core for interfacing to the X-Window protocol.

Tcl/Tk is a framework for developing GUI applications, and uses X-Window at its base

OpenGL is a standard for 2D/3D graphics rendering, often using

hardware

acceleration.

Perhaps I should have said "already present". I hadn't found these instructions
on the first compile attempt and there were no error messages apart from the pointer-type mismatch. Nothing about missing files or programs. The machine seemed
happy with the existing gcc, g++, make and cmake. I didn't change them.

In any case, I'm simply glad it worked. As a matter of curiosity, does OpenGL on the Pi4 use the GPU? I know there was work to that end, but haven't heard much recently.

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> writes:

There are still no updates/replies to the support request on SourceForge at https://sourceforge.net/p/brlcad/support-requests/123/
A followup from you (since you fixed it) or me (if you don't want to bother) might help things along.

If you want to follow-up, feel free. It seems to me there are a huge
number of bugs and feature requests that have gone unfixed, sometimes
for years. OTOH, the wiki is apparently editable (even anonymously) so
that might a good place to add some Raspberry Pi specific compilation
notes.

The cmake file changes might be best submitted in the patch department
on Sourceforge.

I can try to do these things this weekend.

Funny, I initially tried this compilation just to see if my little 3B+
could even build this project. And to see how long it would take. I
didn't save exact times but it was about two hours.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Anssi Saari <as@sci.fi> wrote:

bob prohaska <bp@www.zefox.net> writes:

There are still no updates/replies to the support request on SourceForge at >> https://sourceforge.net/p/brlcad/support-requests/123/
A followup from you (since you fixed it) or me (if you don't want to bother)
might help things along.

If you want to follow-up, feel free. It seems to me there are a huge
number of bugs and feature requests that have gone unfixed, sometimes
for years. OTOH, the wiki is apparently editable (even anonymously) so
that might a good place to add some Raspberry Pi specific compilation
notes.

The cmake file changes might be best submitted in the patch department
on Sourceforge.

I can try to do these things this weekend.

Funny, I initially tried this compilation just to see if my little 3B+
could even build this project. And to see how long it would take. I
didn't save exact times but it was about two hours.

The Pi4 was faster, but not hugely. I think it took about 90 minutes.

The benchmarks worked on the Pi4, reporting:

-----------quote-----------------
B R L - C A D B E N C H M A R K
=================================
Running /home/bob/brlcad-code/build/bin/benchmark on Thu Oct 1 19:29:42 PDT 2020
Logging output to run-26267-benchmark.log
Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux

Using [/home/bob/brlcad-code/build/bin/rt] for RT
Using [/home/bob/brlcad-code/build/bin/../share/db] for DB
Using [/home/bob/brlcad-code/build/bin/../share/pix] for PIX
Using [/home/bob/brlcad-code/build/bin/../share/pix] for LOG
Using [/home/bob/brlcad-code/build/bin/pixcmp] for CMP
Using [/home/bob/brlcad-code/build/bin/elapsed.sh] for ELP
Using [32] for TIMEFRAME
Using [300] for MAXTIME
Using [2] for DEVIATION
Using [5] for AVERAGE

RT reports the following version information:
BRL-CAD Release 7.32.1 The BRL-CAD Raytracer RT
BRL-CAD Release 7.32.1 The BRL-CAD Ray-Tracing Library
BRL-CAD Release 7.32.1 The BRL-CAD Numerical Computation Library
BRL-CAD Release 7.32.1 The BRL-CAD Utility Library

Minimum run time is 3 minutes, 12 seconds
Maximum run time is 30 minutes
Estimated time is 9 minutes, 36 seconds

Running the BRL-CAD Benchmark tests... please wait ...

+++++ moss
Frame 0: 261660 rays in 0.21 sec = 1219196.54 rays/sec (RTFM) Frame 1: 542220 rays in 0.42 sec = 1286778.91 rays/sec (RTFM) Frame 5: 8390560 rays in 6.44 sec = 1302078.75 rays/sec (RTFM) Frame 7: 34038144 rays in 24.53 sec = 1387612.44 rays/sec (RTFM) Frame 8: 68601600 rays in 48.95 sec = 1401336.68 rays/sec (RTFM) Frame 9: 68698624 rays in 50.69 sec = 1355310.36 rays/sec (RTFM) Frame 10: 69267200 rays in 50.61 sec = 1368731.80 rays/sec (RTFM) Frame 11: 68244224 rays in 51.71 sec = 1319747.12 rays/sec (RTFM) pixcmp pixels: 262144 matching, 0 off by 1, 0 off by many moss.pix: answers are RIGHT
+++++ world
Frame 0: 366988 rays in 0.70 sec = 524399.48 rays/sec (RTFM) Frame 1: 721822 rays in 1.36 sec = 532376.49 rays/sec (RTFM) Frame 4: 5774192 rays in 10.43 sec = 553620.67 rays/sec (RTFM) Frame 5: 11665088 rays in 21.25 sec = 548839.33 rays/sec (RTFM) Frame 6: 23296384 rays in 41.33 sec = 563646.31 rays/sec (RTFM) Frame 7: 23316800 rays in 42.02 sec = 554873.90 rays/sec (RTFM) pixcmp pixels: 262144 matching, 0 off by 1, 0 off by many world.pix: answers are RIGHT
+++++ star
Frame 0: 232467 rays in 0.47 sec = 491700.45 rays/sec (RTFM) Frame 1: 464618 rays in 0.91 sec = 509621.25 rays/sec (RTFM) Frame 5: 7443936 rays in 13.67 sec = 544505.34 rays/sec (RTFM) Frame 6: 14919360 rays in 27.85 sec = 535771.45 rays/sec (RTFM) Frame 7: 14951296 rays in 28.42 sec = 526051.61 rays/sec (RTFM) Frame 8: 15188736 rays in 29.17 sec = 520757.95 rays/sec (RTFM) pixcmp pixels: 262144 matching, 0 off by 1, 0 off by many star.pix: answers are RIGHT
+++++ bldg391
Frame 0: 275155 rays in 0.72 sec = 383359.18 rays/sec (RTFM) Frame 1: 540192 rays in 1.38 sec = 390627.27 rays/sec (RTFM) Frame 4: 4562640 rays in 10.85 sec = 420357.31 rays/sec (RTFM) Frame 5: 8839232 rays in 21.23 sec = 416373.51 rays/sec (RTFM) Frame 6: 17941184 rays in 40.92 sec = 438488.06 rays/sec (RTFM) Frame 7: 17837440 rays in 41.56 sec = 429217.74 rays/sec (RTFM) Frame 8: 18077184 rays in 41.67 sec = 433863.00 rays/sec (RTFM) pixcmp pixels: 262144 matching, 0 off by 1, 0 off by many bldg391.pix: answers are RIGHT
+++++ m35
Frame 0: 483117 rays in 0.95 sec = 511122.15 rays/sec (RTFM) Frame 1: 1010506 rays in 1.82 sec = 555080.19 rays/sec (RTFM) Frame 4: 7834816 rays in 14.04 sec = 557878.91 rays/sec (RTFM) Frame 5: 15588736 rays in 27.58 sec = 565221.71 rays/sec (RTFM) Frame 6: 31179200 rays in 56.33 sec = 553482.90 rays/sec (RTFM) Frame 7: 31441792 rays in 55.38 sec = 567773.08 rays/sec (RTFM) pixcmp pixels: 262070 matching, 74 off by 1, 0 off by many m35.pix: answers are RIGHT
+++++ sphflake
Frame 0: 1397652 rays in 2.14 sec = 653622.38 rays/sec (RTFM) Frame 1: 2781346 rays in 4.07 sec = 683779.98 rays/sec (RTFM) Frame 3: 11483712 rays in 15.98 sec = 718852.35 rays/sec (RTFM) Frame 4: 22896464 rays in 31.45 sec = 728078.31 rays/sec (RTFM) Frame 5: 22204352 rays in 31.93 sec = 695431.11 rays/sec (RTFM) Frame 6: 22355824 rays in 31.87 sec = 701569.01 rays/sec (RTFM) pixcmp pixels: 262144 matching, 0 off by 1, 0 off by many sphflake.pix: answers are RIGHT

... Done.

Total testing time elapsed: 16 minutes, 30 seconds

The following files have been generated and/or modified:
*.log ..... final log files for each individual raytrace test
*.pix ..... final pix image files for each individual raytrace test
*.log.* ... log files for previous frames and raytrace tests
*.pix.* ... pix image files for previous frames and raytrace tests
summary ... performance results summary, 2 lines per run

Run '/home/bob/brlcad-code/build/bin/benchmark clean' to remove generated pix files.

Summary:
Abs raspberrypi
1319747.12 554873.90 520757.95 433863.00 567773.08 701569.01 683097.34 Thu Oct
1 19:46:12 PDT 2020
*vgr raspberrypi 9632.48 8274.29 9287.63 8130.86 8031.87 47.33 7234.07

#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*# Benchmark results indicate an approximate VGR performance metric of 7234 Logarithmic VGR metric is 3.86 (natural logarithm is 8.89) #*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#*#

These numbers seem to indicate that this machine is approximately 7234 times faster than the reference machine being used for comparison, a VAX 11/780 running 4.3 BSD named VGR. These results are in fact approximately 3.86
orders of magnitude faster than the reference.

Here are some other approximated VGR results for perspective:
120 on a 200MHz R5000 running IRIX 6.5
250 on a 500 MHz Pentium III running RedHat 7.1
550 on a dual 450 MHz UltraSPARC II running SunOS 5.8
1000 on a dual 500 MHz G4 PowerPC running Mac OS X 10.2
1500 on a dual 1.66 GHz Athlon MP 2000+ running RedHat 7.3
52000 on a 4x4 CPU 2.93 GHz Xeon running RHEL Server 5.4
65000 on a 512 CPU 400 MHz R12000 Running IRIX 6.5

You are encouraged to submit your benchmark results and system
configuration information to benchmark@brlcad.org
~~~~~~~~~~~~~~~~~~~~
Including additional kernel and hardware information in the log.

Collecting system state information (via /sbin/sysctl)
Collecting system CPU information (via /proc/cpuinfo)
Collecting system CPU information (via /usr/bin/lscpu)

Read the benchmark.tr document for more details on the BRL-CAD Benchmark.
The document should be available in the 'doc' directory of any source
or complete binary distribution of BRL-CAD.

Output was saved to run-26267-benchmark.log from /home/bob/brlcad-code/build/bench
Benchmark testing complete.
-------------end quote-----------------------


It seems best if I simply report that the problem is fixed and perhaps quote the patches you developed. It makes little sense for me to submit them, since
I can't answer any questions that might come up. The connection between the error messages and the fix eludes me completely.

Many thanks!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)