did you download the amd64 version of the binary by any chance and not the arm64?

also what kind of a CPU does that device have?

@U7ERLH6JX I just used bb installation script, it installed the aarch64 binary. No error output during installation. Couldn't execute bb after install. CPU is Qualcomm Snapdragon 660

could you tell me the output of uname -a and file <path-to-bb> in your system?

Sure.

~ $ uname -a
Linux localhost 4.4.302-lineageos-g91a081bcae19 #1 SMP PREEMPT Sun Sep 11 10:00:51 JST 2022 aarch64 Android
~ $ file $PREFIX/bin/bb
/data/data/com.termux/files/usr/bin/bb: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=118cdc1ac9a17f39c1f110ab73e28b82b7677233, for GNU/Linux 3.7.0, with debug_info, not stripped

could you try the install script with --static=true?

i think one of the deps in the dynamic bin is missing on your system

~/tmp $ ./install-bb --static
Downloading  to /data/data/com.termux/files/usr/tmp/tmp.kYkVVl6jb8
Moving /usr/bin/bb to /usr/bin/bb.old
Successfully installed bb in /usr/bin
~/tmp $ bb
bash: /data/data/com.termux/files/usr/bin/bb: cannot execute: required file not found
~/tmp $

Doesn't seem to work :(

what does ldd <path-to-bb> say?

~ $ ldd $PREFIX/bin/bb
libdl.so.2
libpthread.so.0
libc.so.6
ld-linux-aarch64.so.1

ah i see it, the static binary on arm isnt fully static as graalvm doesnt support musl builds on arm yet. and it seems one of the dynamic libs is missing on your OS

one or more of • libdl.so.2 • libpthread.so.0 • libc.so.6 is missing.

this is a limitation of the GraalVM unfortunately 😕

cc @U04V15CAJ

https://github.com/oracle/graal/issues/3737

@U7ERLH6JX Thanks for checking that for me. So nothing I can do about it, right?

dont think so as of now, we'll have a look again if something has changed and report back here

Thanks! I understand

if you could try installing/make sure they are there, the 3 deps i mentioned before could help too

my suspicion is libdl.so.2

also could be a lineageos thing of whats included and not

Have you tried: https://github.com/babashka/babashka/releases/download/v0.10.163/babashka-0.10.163-linux-aarch64-static.tar.gz That is the static executable for linux aarch64 which is compiled with H:+StaticExecutableWithDynamicLibC

Ah yes, you tried that one. Well that should work iff you have libc.so

yes, libc.so is located at both /system/lib and /system/lib64

could you maybe try symlinking libc.so to libc.so.6? it may get picked up then?

is 6 the version number? what could possibly go wrong? :)

well cant be worse than what it is now 😛

or maybe try finding the package that provides it, not sure what lineage uses

> The libc.so.6 file is present in the libc6 package.

depends on the package manager and the distro i think

yeah

symlink might work

yeah its one of the dirty tricks ive used to get by 😅

tried that already, symlink didn't work :( I need to find a package which contains libc.so.6 for termux

ah we do have a brave person to experiment with then 😛

I googled and found this :P https://github.com/MasterDevX/Termux-Java/blob/master/openjdk/lib/arm/libc.so.6

seems to be The One 😎

I have just tried that one, doesn't work either :(

Normally ldd will say which files it found right? It seems it didn't find any of the requires libraries?

Output of ldd is different now

$ ldd $PREFIX/bin/bb
libstdc++.so.6
libz.so.1
libdl.so.2
libpthread.so.0
libc.so.6
ld-linux-aarch64.so.1

its interesting that with the mostly static binary it still needs so many things. graalvm said it should only need libc

also interesting is that ldd here doesn't print after each library the full path of what it found.

@U5SB58RLZ can you show us what ldd --version prints? And what ld --version prints aswell while we are at it.

also /etc/ld.so.conf would be useful, and whats in /etc/ld.so.conf.d directory if it exists. There is something strange about this termux platform...

There appears to be a tool ndk-depends on android that may help here. Do you have ndk-depends on your system? https://android.googlesource.com/platform/ndk/+/426f4ee8a8c3be97122c1a6bf5f58dbd9486bbc9/docs/text/NDK-DEPENDS.text

@U1QQJJK89 Only ld --version is available.

GNU ld (GNU Binutils) 2.39
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

It's interesting that the linker is a quite up to date version of GNU ld, but ldd (which is actually a wrapper script) is not your standard binutils ldd. I'm trying to ascertain why the list of linked files doesn't show their resolved paths. Can you see if running the following gives you the same output as your ldd invocation: LD_TRACE_LOADED_OBJECTS=1 ld /path/to/bb

hmm..that doesn't work

~ $ LD_TRACE_LOADED_OBJECTS=1 ld $PREFIX/bin/bb
ld: cannot use executable file '/data/data/com.termux/files/usr/bin/bb' as input to a link

so the OS on your xiaomi is MUI or lineage? I saw lispyclouds mention lineage but I don't see you mention it.

@U1QQJJK89 here: https://clojurians.slack.com/archives/CLX41ASCS/p1665370734369699?thread_ts=1665369370.715609&cid=CLX41ASCS

ah gotcha. I have an old mobile device with lineage on it. I will dig it out an have a try

on a side note, getting bb to run in such devices would be cool too!

We do have reports here of people having bb work on their tablet: https://github.com/babashka/babashka/issues/241

https://github.com/babashka/babashka/issues/241#issuecomment-804721420

i guess we switched to mostly static for ARM after that?

I converted that issue into a discussion: https://github.com/babashka/babashka/discussions/1392?converting=1 If you have any new info that is useful in the future, please put it there too

You could try re-compiling without the mostly static option, or compile bb on the device itself

Will try again later. Thank you all!

There is a #C03EC4DD26S channel where you can post these questions, but let's continue here for now

Yeah, I wasn't sure if this was an issue with quickdoc or just me not understanding how to work with babashka file paths yet

ok yeah, that makes sense

let me see

ie. if this were Bash, I'd cd to the cloned dir, run there, then cd back. But that didn't obviously track to how fs/`process` work

process supports this via the :dir option, but that doesn't really help you here, I think.

I'm not sure how to solve this without e.g. adding an explicit :dir argument to quickdoc which then strips off that dir part

I'm going to bed now, but feel free to play around with this and submit an issue and/or PR

Yeah, it seems like quickdoc would need to be able to be told an explicit root dir to invoke itself from.

OK, I will take a look and see if I can come up with anything tomorrow.

quickdoc can't invoke itself from another dir, but it can rewrite some stuff before emitting markdown

@U03TPPC0R0T I think this might be a good solution: https://github.com/borkdude/quickdoc/blob/a94ab9d46b0e5f787096b49a653b39e9ed3fd47a/bb/tasks.clj#L11 So using :filename-fn you can transform the filename, e.g. strip the root, before it's rendered to markdown.

Ahh, yeah, that could work. I presume this function applies before it's turned into a URL?

yes

Hah! This worked great, thank you!

:filename-fn #(str/replace % (re-pattern (str name "/")) "")

You might want to throw this in:

user=> (clojure.string/re-quote-replacement "$foo")
"\\$foo"

no sorry, that didn't make sense

nice to hear that it worked :)