compiling on musl

[macmpi]

Compiling vclog on Alpine (musl 1.2 instead of glibc) fails at:

/vclog/vcdbg.c:10:10: fatal error: bits/types.h: No such file or directory
   10 | #include <bits/types.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.

unsure which definitions to patch with, particularly if timing stuff is involved (musl 1.2 is time64 sensitive).
Thoughts?

[macmpi]

moved on with #include <sys/types.h> but now chokes on 32-bit:

/vclog/vcdbg.c:206:45: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
  206 |                                    dev_mem, (off_t)logs_start);
      |                                             ^

[popcornmix]

Does this compile cleanly for you?

diff --git a/vclog/vcdbg.c b/vclog/vcdbg.c
index b7df0f9..019fb4a 100644
--- a/vclog/vcdbg.c
+++ b/vclog/vcdbg.c
@@ -7,7 +7,7 @@
     Copyright (c) 2022, Joanna Rousseau - Raspberry Pi Ltd All rights reserved.
 *******************************************************************************/
 #include <assert.h>
-#include <bits/types.h>
+#include <sys/types.h>
 #include <ctype.h>
 #include <errno.h>
 #include <fcntl.h>
@@ -203,7 +203,7 @@ int32_t main(int32_t argc, char *argv[]) {
   /* Get a virtual memory ptr so point at the same adress as VC physical
   address (where all logs begin)*/
   char *mmaped_all_logs_hdr = mmap(NULL, all_logs_size, PROT_READ, MAP_PRIVATE,
-                                   dev_mem, (off_t)logs_start);
+                                   dev_mem, (uintptr_t)logs_start);
 
   /* file descriptor can be immediately closed without affecting mmap */
   close(dev_mem);

[macmpi]

Yes it definitely does: thanks!
Will report results in related thread.

Some thoughts on this tools suite as I'm looking to include in Alpine repo:

• clarifying Licenses statements would help (userland stuff seemed BSD-3: any different for these?)
• should all be installed where /usr/bin or in /opt/vc/bin like vcgencmd (userland stuff) ?
• overlaycheck_exclusions.txt file lying in /bin: wouldn't it be more appropriate in some conf related locations ?
• dtmerge/dtoverlay seem duplicated of (older) userland package: would those disappear then?
• raspinfo: relying on plain (busybox) sh only rather than bash would make it more practical on other distros (and not assume /opt/vc/bin is already in path)

[pelwell]

Answering in order:

• Yes - the licence will be BSD 3-clause or similar.
• Install it where you want to.
• The exclusions file is effectively part of the utility - it's not meant to be edited by users.
• The existing dtmerge/dtoverlay apps may eventually be removed from userland.
• @JamesH65 can comment on raspinfo, its shell usage, etc.

[popcornmix]

should all be installed where /usr/bin or in /opt/vc/bin like vcgencmd (userland stuff) ?

I think /opt/vc was only used for legacy code that interfaced with firmware, and wanted to avoid collisions with standard libraries (e.g. the firmware gl drivers vs system mesa gl libraries).

I think /usr/bin is more suitable for new code. I believe RPiOS 64-bit has moved /opt/vc files to /usr/bin.

raspinfo: relying on plain (busybox) sh only rather than bash would make it more practical on other distros (and not assume /opt/vc/bin is already in path)

Pull requests are welcome.

[macmpi]

Thanks again.
Closing now.