Support for ARM-Linux

[Opcode]

is iOS not the OS the Apple notebooks work with?
I thought they managed to put it together.

But anyway - I am not part of the Apple-hype group.

iOS is the mobile OS that Apple uses on their iPhones. iPadOS is what they use on their tablets. MacOS is what they use on their laptops to desktops. Support of ARM may eventually become mandatory at some point to support Apples ecosystem. As Apple is clearly set on using their own silicon to power their devices. ARM is and will continue to grow across the ecosystem from Apple to Linux to Windows PCs. As long as if Nvidia doesn't ruin the licensing model if they are cleared to aquire ARM.

Freds focus should be to bring the C backend up to snuff with the current before implementing support for new instruction sets. Though I will agree when the time comes, ARM support would bring PB flexibility to the next level.

[macros]

As I wrote before, i am willing to donate 150€ for ARM Support.
100€ as price seems a bit harsh however. I was very happy to buy Purebasic myself back in school, 100€ would be even more than the usual license.
I think 50€ would be more appropriate.

I would however prefer if it just joins the other platforms under the usual license, maybe after donations for ARM support have reached a threshold?

Well it took quite a while, but my dreams have come true.

Here is PureBasic running on my N900, a phone from 2009 with a Linux based OS, € Coin for size.


It even integrates nicely with the system UI!



I will gladly stand by my word and send a well deserved donation!

(If only I could somehow fit the full preferences window on the 800x480 screen!)

[Fred]

That's interesting, did you recompile the IDE or did it worked out of the box from the raspberry version ?

[macros]

For now I took the easy way and placed the Raspberry Pi OS into a directory and chrooted to it.

The pbcompiler is linked against GLIBC_2.29 and the distribution on the device still ships 2.28 (it is based on debian Buster). Seeing this I did not try running the IDE. I eagerly await an update of the OS so I can run PB directly.

[User_Russian]

The pbcompiler is linked against GLIBC_2.29 and the distribution on the device still ships 2.28

Yes, need to support version 2.28.
About this many times write on the forum. I hope Fred will add support GLIBC 2.28 or the previous version.

[Fred]

Do you know if the binaries compiled for 2.28 will run on 2.29 ?

[macros]

Yes they will. You can lower the version till you hit missing features your software requires. Newer versions will stay compatible.

If you compile a Purebasic program on Ubuntu 18.04 it will run on 21.10.
(unless you use a library which was completely replaced, but this happens rarely)
If you compile it on 21.10 it will not run on any older version of ubuntu because it is linked against the current versions of libraries.

So if you could compile a ARM version of PureBasic on an old version of Raspi OS it should work on all newer ones.

Edit: You can also modify the source to specifically link against older versions.
https://stackoverflow.com/questions/403 ... n-coverage

[User_Russian]

I can't check because PB compiles only for 2.29.
Is it possible to add to the PB IDE to the compiler option window, the ability to select version GLIBC?

[macros]

I just ran the steps described in the Stackoverflow post.

objdump -p raspios/home/macros/Programmieren/purebasic/compilers/pbcompiler

Code: Select all

[...]
Version References:
  required from libm.so.6:
    0x06969189 0x00 03 GLIBC_2.29
  required from libc.so.6:
    0x0d696917 0x00 04 GLIBC_2.7
    0x0d696914 0x00 02 GLIBC_2.4

objdump -T raspios/home/macros/Programmieren/purebasic/compilers/pbcompiler | fgrep GLIBC_2.29

Code: Select all

00000000      DF *UND*  00000000  GLIBC_2.29  pow

So the culprit is the pow library linked in libm.so.6
objdump -T raspios/usr/lib/arm-linux-gnueabihf/libm.so.6 | grep -w pow

Code: Select all

0000a1f0 g    DF .text  00000178 (GLIBC_2.4)  pow
000172f8 g    DF .text  000008b0  GLIBC_2.29  pow

And there is the solution.

So something like

Code: Select all

__asm__(".symver pow,pow@GLIBC_2.4");

Should allow to compile pb on newer systems and still allow everybody to run it on older ones.
The sacrifice are some speed optimizations in the pow library. I can't find benchmarks showing the exact difference. But I guess pow would not be called often in the compiler and it would only make a very small difference.

The newest other reference is against glibc 2.7. That means, that with this small change the compiler itself should run on any Linux release since 2008!

[idle]

That's good sleuthing.

[Fred]

I just pushed a new Raspberry 6.00 beta 4 package which links the libm statically to avoid the 2.29 dependency, could you give it a try ? I tried the asm symbols redirect, but it didn't worked here. Did you succeded on your tests ?

[User_Russian]

In OS 2020-08-20-raspios-buster-armhf (GLIBC 2.28) works great.
Many thanks Fred!

IDE and compiler work, but examples with 3D are not started. Maybe engine3d.so use LIBC_2.29?

[macros]

Indeed it does, thanks so much!

Now Sound.pb works (Sound is difficult to get working in chroot)
and even the IDE runs just fine.



Also the Menus work which they didn't in the chroot due to the different style.


I am very happy. Now I can run my soundboard app with effects for childrens musicals directly on the phone.
Previously I had a laptop stashed away and used a remote connection, always worried that the connection drops in a crucial moment.
And I can free 3GB of space by removing the Raspberry PI OS

Its surprising usable for a 13 year old device with 256MB RAM and a 600MHz processor.
Finally I have PB ready whenever and wherever I want!

[idle]

That's great

[Cyllceaux]

@macros: this... this is the most beautiful thing I ever saw...