YTuner not working on OpenWRT

[rkerschn]

Dear Greg,

I've just tried to get YTuner running on my R7800 running OpenWRT.

First I made the ytuner executable with chmod +x

Nevertheless, executing YTuner always leads to:
-bash: ./ytuner not found

i digged a bit deeper and I think its an issue with the loader.

According to the OpenWRT HDDB the R7800 has the following Architecture:
ARMv7 Processor rev 0 (v7l), arm_cortex-a15_neon-vfpv4

Regards, Reinhard

[coffeegreg]

Hi Reinhard,
I just found libraries for Linux_ARM_OpenWrt_2203. I've never used OpenWRT based devices and never tried to cross-compile from Win64/x64_86 or Linux64/x64_86 to OpenWRT/ARMv7. 🤔 I can try. Why not, but I will need your help to test the compiled binaries and in case of missing some OpenWRT libraries to attach them. Ready to help ❓ I can't guarantee 100% success but I think it's worth a try. What do you think ❓ 🤔

[rkerschn]

Hi Greg,

All in all, sounds awesome, I help where I can 😊

To be honest, I never manually ran an application on OpenWRT, but only used the packaging tool opkg. But it should work as with any other Linux Distro.

May I ask, where have you found the libraries for Linux_ARM_OpenWrt_2203? I would need 2305.

router:/etc/ytuner# chmod +x ytuner
router:/etc/ytuner# ./ytuner
-ash: ./ytuner: not found
router:/etc/ytuner# ldd ytuner
/lib/ld-linux-armhf.so.3 (0xb6f25000)
libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
libdl.so.2 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
librt.so.1 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
libc.so.6 => /lib/ld-linux-armhf.so.3 (0xb6f25000)

So I had a look at /lib and only found the ld-musl-armhf.so.1 library and libc.so
no ld-linux-armhf.so found
also no libpthread.so, libdl.so or librt.so are found. It's a bit strange, since ldd does not mention that those libs are missing. I will check that. Could be that I need those libs.

[rkerschn]

I have tried to manually install libpthread, libdl and librt but
it looks like the library libdl is missing in the repository

I will check on that and will let you know

[TheBossME]

One question: which version of openwrt is running ?
Is 2305 the version you need ?

I do have Proxmox running on arm64 and amd64. So I can do the tests also and can check it out.

https://downloads.openwrt.org/releases/22.03.5/targets/armvirt/64/

regard's Beatrice

[rkerschn]

Dear Beatrice,

yep, I am running 2305.
That would be great if you could check it as well, thank you :)

[TheBossME]

Dear Beatrice,

yep, I am running 2305.

That would be great if you could check it as well, thank you :)

https://downloads.openwrt.org/releases/22.03.5/targets/armvirt/64/

or

https://downloads.openwrt.org/releases/22.03.7/targets/armvirt/64/

This is the one I can actually checkout.
If this this to much different, it wouldn't help.

[rkerschn]

you could use this, armsr replaces armvirt, according to 23.05 releasenotes
https://downloads.openwrt.org/releases/23.05.5/targets/armsr/armv7/

Release notes of 23.05 (https://openwrt.org/releases/23.05/notes-23.05.0):

Highlights of device support
Added Arm SystemReady (EFI) compliant target armsr replacing the armvirt target

[TheBossME]

Okay.. I do love Proxmox ..

https://downloads.openwrt.org/releases/23.05.5/targets/armsr/armv8/openwrt-23.05.5-armsr-armv8-generic-ext4-combined.img.gz

Is running.. I will go forward to configure..

[rkerschn]

Great work, looks good!

Are you running arm v8 or v7?

The link in your last posting is arm v8,
The router I am running is arm v7

[TheBossME]

Great work, looks good!

Are you running arm v8 or v7?

The link in your last posting is arm v8,

The router I am running is arm v7

I can use both.

[rkerschn]

I see, thanks

[TheBossME]

I see, thanks

I have issues while Opkg cannot update. Operation not permitted.

I wasn't firm with openwrt.

Other question:

Which package of ytuner have you used ?. There is dir arm v32 a separated package. I think you used wrong package

[rkerschn]

this is the package that I used:
ytuner-1.2.3-arm-linux.zip

[TheBossME]

this is the package that I used:

ytuner-1.2.3-arm-linux.zip

What operating system is behind openwrt ?
If based on alpine Linux, the See my prior postings about installing missed compatibility libraries.

Greg: I informed in my last postings regarding alpine Linux.
Please put this information into documentation. Thanks.

[rkerschn]

It's not based on Alpine but like Alpine, it uses BusyBox and musl.

About missing libraries, yep, that's what I thought about yesterday.

I have tried to manually install libpthread, libdl and librt but it looks like the library libdl is missing in the repository

I will check on that and will let you know

@coffeegreg
Would it be possible to compile it for OpenWRT as well, maybe create an OpenWRT package?
It would make a lot of sense to have ytuner running on the home router, that needs to run anyway. So no other hardware needs to run in addition.

[TheBossME]

Question: why using openwrt ?. It's so easy running on all platforms

I didn't know if gcompat Library is available. This will fix your issue similar alpine.

[rkerschn]

Instead of explaining why, I think it is best to cite from Wikipedia:
OpenWrt (from open wireless router) is an open-source project for embedded operating systems based on Linux, primarily used on embedded devices to route network traffic. The main components are Linux, util-linux, musl,[4] and BusyBox. All components have been optimized to be small enough to fit into the limited storage and memory available in home routers.

OpenWrt is configured using a command-line interface (ash shell) or a web interface (LuCI). There are about 8000 optional software packages available for installation via the opkg package management system.

Installing OpenWRT is aseasy as upgrading the Vendors Firmware via the Routers Webinterface. That does not work with alpine. Not to speak of LUCI, that is not available on alpine.

[TheBossME]

Have you installed bash for starting ytuner ? And what about the missed c-libs ?. There is no compile for openwrt needed.

If you are using such exotic hardware, support will end here.

[rkerschn]

Thanks for your effort giving it a try.
Could you try OpenWRT x86 with ytuner i386 linux with Proxmox?
https://downloads.openwrt.org/releases/23.05.5/targets/x86/generic/

I would say ARM is ARM, no matter in wihch device it is soldered - so I think the issue is not necessarily the hardware rather than the software (OS).
Compiling for OpenWRT would take care of such dependencies.

[TheBossME]

Nope.

You can install free pascal on your openwrt system and compile yourself, or using supported distros.

Greg told you: He has not all hardware available to test.

Proxmox is designed for 64 bit systems only.

[rkerschn]

@TheBossME
If you are not able to contribute anymore, thats fine with me.
Thank your effort and time so far!

I think it is perfectly legitimate to ask for support for a further distribution.
Especially because it makes a lot of sense to have ytuner running on the home router, that needs to run anyway. So no other hardware that acts as a server is needed to run in addition.

[TheBossME]

@TheBossME

If you are not able to contribute anymore, thats fine with me.

Thank your effort and time so far!

I think it is perfectly legitimate to ask for support for a further distribution.

Especially because it makes a lot of sense to have ytuner running on the home router, that needs to run anyway. So no other hardware that acts as a server is needed to run in addition.

Agreed 👍
Keep in mind. Greg has not the ability (not all hardware available) and time to compile on different platforms.

Again: Feel free to install Free Pascal on your hardware and start compile. I have no Pascal knowledge.

Installing I386 OS'SES is possible to install. But this will not help you as I understand right ?.

My other plan is, installing ytuner cluster instances for everybody with a default configuration. Will this be helpful for ya ?

[rkerschn]

Keep in mind. Greg has not the ability (not all hardware available) and time to compile on different platforms.

I think that's up to Greg. As I understood in his reply here, he suggested to give it a try, but he needs my help for testing. I am looking forward to help where I can :)

Again: Feel free to install Free Pascal on your hardware and start compile. I have no Pascal knowledge.

me neither, I also have no Pascal knowledge

Installing I386 OS'SES is possible to install. But this will not help you as I understand right ?.

It would help to see if it is a hardware or software related issue.
I've just tested it via kvm qemu i386 OpenWRT --> same issue as with arm7

Conclusion: one or some libraries are missing.
Would be great to consider library dependencies for OpenWRT :)

My other plan is, installing ytuner cluster instances for everybody with a default configuration. Will this be helpful for ya ?

I don't know but I would expect some difficulties regarding copyright due to the vtuner API. I would prefer a solution running privately on my own hardware. Nevertheless, I appreciate your offer, thank you!

[TheBossME]

Finally: It is library issue.

If free pascal has no compile option for the needed library, it will not run.

Schönen Nachmittag
Gruß Beatrice

[rkerschn]

it's weird, because ldd does not give any hint about a missing library ;)

ldd returns for i386:
router:/etc/ytuner# ldd ytuner-i386
linux-gate.so.1 (0xf7edc000)
libc.so.6 => /lib/libc.so.6 (0xf7cbb000)
/lib/ld-linux.so.2 (0xf7ede000)

ldd returns for arm:
router:/etc/ytuner# ldd ytuner-arm
/lib/ld-linux-armhf.so.3 (0xb6f25000)
libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
libdl.so.2 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
librt.so.1 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
libc.so.6 => /lib/ld-linux-armhf.so.3 (0xb6f25000)

[TheBossME]

It is not, the libraries needed to run the application (e.g. gcompat) are definitely missing. Please try to add the alpine repository, maybe you can install it from there.

scanelf -i ~/vtuner

[rkerschn]

Dear Beatrice,

I have tried as you suggested, for testing purpose, but I get an UNTRUSTED signature error.
Nevertheless, adding a non OpenWRT repository is not an option on a productive system, especially edge systems like routers. That would break the whole upgrade process. The only clean solution would be to build ytuner considering OpenWRT requirements.

As I said, I think it is perfectly legitimate to ask for support for a further distribution.
It is fine for me that you use alpine linux, but please respect that alpine is not the ultimate solution for everyone. Other purposes, other requirements, other demands, etc...

I appreciate your effort, but I am counting on @coffeegreg Greg and that I am going to support him in any way possible for me.

[coffeegreg]

I wrote a message here yesterday and went to sleep. This morning I went to work and just got back and I see ... 25 new messages. 👀 You have not been idle ... 👍
I will not reply to each one of them .. it would probably take me the whole rest of the day. 😉

@rkerschn :

Would it be possible to compile it for OpenWRT as well ...

Yes, This is what I'm going to try. 👍

It would make a lot of sense to have ytuner running on the home router, that needs to run anyway. So no other hardware needs to run in addition.

Yes, it is.

I think it is perfectly legitimate to ask for support for a further distribution.

Agree.

Especially because it makes a lot of sense to have ytuner running on the home router, that needs to run anyway. So no other hardware that acts as a server is needed to run in addition.

Agree ... but 🤔 ... some functionality that requires or will require more CPU computing power may not work properly.

I would say ARM is ARM, no matter in wihch device it is soldered ...

That's not entirely true ...

I think that's up to Greg. As I understood in his reply here, he suggested to give it a try, but he needs my help for testing. I am looking forward to help where I can :)

Great ❗ 🚀

I don't know but I would expect some difficulties regarding copyright due to the vtuner API.

In the case of YTuner, there can be no question of violating any copyrights. No one stole anything from anyone and did no reverse engineering on it. The implemented YTuner functionality is based on the analysis of network traffic to/from AVR. That's all, everything in accordance with the law.

It is fine for me that you use alpine linux, but please respect that alpine is not the ultimate solution for everyone. Other purposes, other requirements, other demands, etc...

Agree.

@TheBossME :

You can install free pascal on your openwrt system and compile yourself, or using supported distros.

I'm afraid that wouldn't be easy if at all possible. That's why freepascal can compile for other OSs and CPU arch.

Keep in mind. Greg has not the ability (not all hardware available) and time to compile on different platforms.

Compiling is not the problem, just testing it on a real platform.

Greg told you: He has not all hardware available to test.

True. 😞

My other plan is, installing ytuner cluster instances for everybody with a default configuration.

ABSOLUTELY FANTASTIC IDEA ❗ ❗ 🚀 👏
This would require additional changes on YTuner's part. For example, moving some options to the avr.ini equivalent so that everyone has their own settings and adding a web management panel and ... some other things ... 🤔
Who will pay for maintaining the service? 😉

I have to go now... I'll add the rest when I get back. Why does a day only have 24 hours? 🤔 😉

[rkerschn]

the other way round did the trick:
ln -s /lib/ld-musl-armhf.so.1 /lib/ld-linux-armhf.so.3
which makes sense, since /lib/ld-musl-armhf.so.1 is the one present

so it looks like that the compiled ytuner does link to the wrong library.
Could this be changes in fpc?

[coffeegreg]

I wrote about :

/lib/ld-linux-armhf.so.3 (0xb6f25000)
        libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
        libdl.so.2 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
        librt.so.1 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
        libc.so.6 => /lib/ld-linux-armhf.so.3 (0xb6f25000)

We can see ld-linux-armhf.so.3
I've to go right now.

[coffeegreg]

There is already some service listening on TCP port 80
I've to go ..............

[rkerschn]

router:/etc/ytuner# ldd ytuner
        /lib/ld-linux-armhf.so.3 (0xb6f25000)
        libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
        libdl.so.2 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
        librt.so.1 => /lib/ld-linux-armhf.so.3 (0xb6f25000)
        libc.so.6 => /lib/ld-linux-armhf.so.3 (0xb6f25000)

Yep, I also thought that if it is not present, than ldd should say missing. Looks like that it is the other way round 🤪
so ldd sees that ytuner is expecting /lib/ld-linux-armhf.so.3
But in /lib/ there is only ld-musl-armhf.so.1

Nevertheless, this does the trick, so I assume for openwrt fpc should link to /lib/ld-musl-armhf.so.1 instead of /lib/ld-linux-armhf.so.3
So thanks for the hint with the symbolic link ☺️

I've to go ..............

No worries, have a nice evening

[rkerschn]

@coffeegreg
I just checked the same with alpine linux x86_64

I took this image:
https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-standard-3.20.3-x86_64.iso
and booted it with KVM Qemu.

I downloaded this YTuner release: /~https://github.com/coffeegreg/YTuner/releases/download/1.2.3/ytuner-1.2.3-x86_64-linux.zip

It's not possible to run YTuner, I do get the exact same
not found-error when trying to execute ./tuner

So I've checked with ldd ytuner to see where ytuner expects the libs and created a symbolic link accordingly:
mkdir /lib64
ln -s /lib/ld-musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

and now YTuner is starting normally as expected.

In Alpine Linux (musl), to run an application created in Free Pascal, we need the libc6-compat or gcompat library >(Beatrice mentioned about this) and YTuner works on Alpine Linux (at least on the x86 platform that I tested and >probably aarch64 (arm64) that Batrice tested)

So from the above mentioned findings, and depending on the depth of YTuner links into glibc, it could be that YTuner will run flawlessly with musl libc and we do not need these libraries: libc6-compat or gcompat, the already existing (in Alpine as well as in OpenWrt) libc is enough.

It looks like a general problem with the linux images (no matter if arm, i386 or x86_64).
So it is not really about missing libraries, as expected earlier. All the libraries are in place, but they're falsely linked.
I assume that FPC sets non or a wrong path and/or filename where ytuner expects the libraries.
Could you check this with FPC?

[rkerschn]

I think I could identify the underlying issue:

runtime linker.
ytuner is an ELF binary, meaning that it needs to be linked to dependent shared libraries. And now the question is, how is this done? The answer is rather simple, by a runtime linker that is specified in the ELF header .interp

running readelf -l ytuner on my Fedora machine gives:

readelf -l ytuner
Elf file type is EXEC (Executable file)
Entry point 0x401340
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x0000000000000230 0x0000000000000230  R      0x8
  INTERP         0x0000000000000270 0x0000000000400270 0x0000000000400270
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000c60 0x0000000000000c60  R      0x1000
  LOAD           0x0000000000001000 0x0000000000401000 0x0000000000401000
                 0x0000000000196c6d 0x0000000000196c6d  R E    0x1000
  LOAD           0x0000000000198000 0x0000000000598000 0x0000000000598000
                 0x0000000000035164 0x0000000000035164  R      0x1000
  LOAD           0x00000000001cdd40 0x00000000005ced40 0x00000000005ced40
                 0x000000000007a6a0 0x0000000000080360  RW     0x1000
  DYNAMIC        0x00000000001cdd50 0x00000000005ced50 0x00000000005ced50
                 0x00000000000001e0 0x00000000000001e0  RW     0x8
  NOTE           0x000000000000028c 0x000000000040028c 0x000000000040028c
                 0x0000000000000020 0x0000000000000020  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x00000000001cdd40 0x00000000005ced40 0x00000000005ced40
                 0x00000000000002c0 0x00000000000002c0  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03     .init .plt .plt.got .text .fini 
   04     .rodata .eh_frame 
   05     .init_array .fini_array .dynamic .got .got.plt .data fpc.resources .fpcdata .bss fpc.reshandles 
   06     .dynamic 
   07     .note.ABI-tag 
   08     
   09     .init_array .fini_array .dynamic .got 

doing the same on my OpenWrt machine (after installing package binutils) gives:

So the .interp header field gives
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] on my Fedora machine
[Requesting program interpreter: /lib/ld-linux-armhf.so.3] on my OpenWrt machine

So ld-linux-armhf.so.3, that is shown by ldd, is the runtime linker in the ELF .interp header.
The problem is, that this runtime linker is not available on Alpine Linux or OpenWrt. Those two distributions use a different runtime linker called ld-musl-armhf.so.1

And that's the reason why ytuner starts, when we create a symbolic link for the expected runtime linker /lib/ld-linux-armhf.so.3 to the available runtime linker /lib/ld-musl-armhf.so.1

So I think there should be a setting in FPC to change the runtime linker to musl on Alpine/Openwrt.

[coffeegreg]

So from the above mentioned findings, we do not need these libraries: libc6-compat or gcompat, the already existing (in Alpine as well as in OpenWrt) libc is enough.

I disagree. Look at my docker tutorial based on Alpine Linux image.

I assume that FPC sets non or a wrong path and/or filename where ytuner expects the libraries.

No. FPC is based on a set of libraries (Linux distr., Solaris, FreeBSD, OpenBSD, MacOS etc) provided to it. In my case, from Fedora or Ubuntu, Solaris, FreeBSD .... As I wrote earlier ... FPC

....check their entries and dependencies...

and builds binaries for selected OSs based on this knowledge. Most Linux distributions are compatible with default libraries but musl Linux distributions based on busybox are different (Alpine Linux, OpenWRT). In such cases, however, it is enough to make a valid link to dynamic linker and be sure to have libc6-compat or gcompat or just libc in your case because OpenWRT, is a linux distribution that uses musl as their standard C library, not libc expected to run FPC binaries.

If I understood correctly, in your case the following link helped:
ln -s /lib/ld-musl-armhf.so.1 /lib/ld-linux-armhf.so.3
Are you sure ?
There is a code :

{$IFDEF UNIX}
// At this moment I have no better idea how to detect Alpine Linux Busybox ?
// ! In this case, enter the YTuner directory first and then run it with ./ytuner !
  if ParamStr(0).Contains('ld-musl-') then
    Result:='./'
  else
{$ENDIF}
    Result:=ProgramDirectory;

Maybe in case of OpenWRT I need to add also 'ld-linux-' ... 🤔 Without the correct result of the above function, the YTuner may not work properly.

Finally, I'm glad to know that YTuner start on OpenWRT 👍 but ... as you can see ... You have to take care about correct YTuner configuration (grant access to TCP port 80 (web service) and UDP port 53 (DNS service - optional) or run on another interface)
One piece of good advice : Please read very carefully the ENTIRE ytuner.ini and avr.ini files included with the binaries. There are many options that will help you configure the YTuner to work the way you want it to.

[coffeegreg]

The problem is, that this runtime linker is not available on Alpine Linux or OpenWrt. Those two distributions use a different runtime linker called ld-musl-armhf.so.1

Correct. I thought you had so.3 file. (runtime linker = dynamic linker)

Please try to run another test program :
test1.zip

This will tell me if any changes to the code are needed.

Once you have placed in your file system all the required files provided with the YTuner 1.2.3 zip archive and configure all settings you can try the new YTuner 1.2.4 beta 1 : #32 (comment)

[rkerschn]

So from the above mentioned findings, we do not need these libraries: libc6-compat or gcompat, the already existing (in >>Alpine as well as in OpenWrt) libc is enough.

I disagree. Look at my docker tutorial based on >Alpine Linux image.

the gcompat library works, because it provides glibc compatibility (as the name gcompat suggests) for musl libc systems.
Fact is, because I have verified it with Alpine Linux and OpenWrt, you can achieve the same thing with a symbolic link to the correct runtime linker.

Why the symbolic link does work is explained in my previous post. its because of the .interp ELF header.
gcompat does the same thing.

I assume, would YTuner be compiled for musl libc instead of glibc, the .interp would change to the correct runtime linker ld-musl-armhf.so.1

If you have an Alpine machine running, even on a KVM Qemu VM, you could verify it yourself by adding a symbolic link.
Adding a symbolic link to ld-musl-armhf.so.1 was your own idea and you where right with it 😉

[rkerschn]

There is already some service listening on TCP port 80 I've to go ..............

The picture in my posting above( #37 (comment))
I wanted to show that YTuner works on OpenWrt as expected.
Just ignore the port 80 error, that's LUCI (OpenWrt Web Interface) listening on Port 80.
The important thing is that it works on OpenWrt when linked to the correct musl runtime linker via the symbolic link.

NO additional libraries like gcompat, etc... are required, i've confirmed it on OpenWrt and Alpine Linux.

ld-musl-armhf.so.1 is also nothing else than a symbolic link to /lib/libc.so

[coffeegreg]

I assume, would YTuner be compiled for musl libc instead of glibc ....

I'm not sure if that's even possible... I don't know FPC that well.

If you have an Alpine machine running, even on a KVM Qemu VM, you could verify it yourself by adding a symbolic link.

I don't have it ... and not much free time either. 😉 I prefer to spend it coding new features in YTuner. A few more interesting ideas to implement... 👍

[coffeegreg]

NO additional libraries like gcompat, etc... are required, i've confirmed it on OpenWrt and Alpine Linux.

🤔 ... Beatrice @TheBossME ... What do you think about this? 😉

[rkerschn]

The problem is, that this runtime linker is not available on Alpine Linux or OpenWrt. Those two distributions use a different runtime linker called ld-musl-armhf.so.1

Correct. I thought you had so.3 file. (runtime linker = dynamic linker)

Please try to run another test program : test1.zip

This will tell me if any changes to the code are needed.

Once you have placed in your file system all the required files provided with the YTuner 1.2.3 zip archive and configure all settings you can try the new YTuner 1.2.4 beta 1 : #32 (comment)

I have just tested your test1.zip

ELF .interp header is again /lib64/ld-linux-x86-64.so.2
Meaning, it gives the same not found error

Only when adding the symbolic link as follows:
ln -s /lib/ld-musl-armhf.so.1 /lib64/ld-linux-armhf.so.3
it works

[coffeegreg]

I have just tested your test1.zip

I need to know what it printed on the console... 😉

[rkerschn]

NO additional libraries like gcompat, etc... are required, i've confirmed it on OpenWrt and Alpine Linux.

🤔 ... Beatrice @TheBossME ... What do you think about this? 😉

This screenshot (quoted from above) is the proof that you do not need the libraries.

first line:
running ytuner
Second line:
not found error
third line:
checking the expected runtime linker which is ld-linux-x86-64.so.2
seventh line: creating the symbolic link for ld-linux-x86-64.so.2 to ld-musl-x86_64.so.1
eighth line ff:
running ytuner again
ytuner starts as expected

[rkerschn]

I have just tested your test1.zip

I need to know what it printed on the console... 😉

I would say the important information is this:
ELF .interp header is again /lib64/ld-linux-x86-64.so.2
Meaning, it gives the same not found error

Only when adding the symbolic link as follows:
ln -s /lib/ld-musl-armhf.so.1 /lib64/ld-linux-armhf.so.3
it works

Here is the output with the symbolic link to the ld-musl-armhf.so.1:

Test 1...
/etc/test1
Test 2...
/etc/
Done.

[coffeegreg]

I understand that the test1 is in /etc and you ran it while in /etc (./test1) . The result is ok. 👍
Please try again from another directory, providing the full path. What is the result ?

[rkerschn]

May I ask what do you expect from the test1 program?
It does not run without the symbolic link. I have to create the symbolic link to get test1 run

May I ask, don't you trust my findings?

Test 1...
/root/test1
Test 2...
/root/
Done.

[coffeegreg]

No. I want to know if any additional code should be added to support OpenWRT so that YTuner can locate itself when it starts.
Alpine Linux need something like this :

{$IFDEF UNIX}
// At this moment I have no better idea how to detect Alpine Linux Busybox ?
// ! In this case, enter the YTuner directory first and then run it with ./ytuner !
  if ParamStr(0).Contains('ld-musl-') then
    Result:='./'

I suspect that OpenWRT doesn't have this problem but I would like to make sure.

[rkerschn]

Since Alpine and OpenWrt are both based on musl and busybox, it should be fine, i guess.

I will check if FPC can compile against musl instead of glibc

[coffeegreg]

Let's summarize. We did a good job and thanks to one link we managed to run Ytuner on OpenWRT. 👏 In the process we discovered some interesting things and are wiser for new experiences. 👍
I hope YTuner will work well on your router. May the sound by with you... 🔈 🎶

[rkerschn]

To be honest, I would say that it requires workarounds. Either symbolic link or gcompat library, as with Alpine Linux.
Depending on the depth of glibc, it could be that YTuner will run flawlessly with musl libc.

I think the goal should be to compile against musl for Alpine Linux/OpenWrt

[TheBossME]

Let's implement into the lovely AVM device FRITZ!Box 🤣🙏🙋‍♀️

[coffeegreg]

Let's implement into the lovely AVM device FRITZ!Box 🤣🙏🙋‍♀️

Yeah .... and my old Huawei EchoLife GPON too 😆
Although I actually wanted to get around to running it on Android someday...

[coffeegreg]

I think I can close this record 68-comments issue. 👀

[rkerschn]

Let's implement into the lovely AVM device FRITZ!Box 🤣🙏🙋‍♀️

@TheBossME
OpenWrt is available for AVM Fritz!Box
You can filter for AVM
https://openwrt.org/toh/views/toh_fwdownload?dataflt%5B0%5D=supported%20current%20rel_%3D23.05.5