Rockbox Development > New Ports
Need help compiling rockbox using devkitARM toolchain.
gama:
Hello there.
I want to try to build rockbox as an sdl application using the devkitARM toolchain,
My goal is to port it to the Nintendo 3DS.
But for now I am wondering how does rockbox dynamically load codecs? Are codecs shared libraries?
Does it uses dlopen?
If so, is there another way to load codecs? Can I link them statically?
Best regards.
speachy:
--- Quote from: gama on May 01, 2025, 11:07:30 PM ---I want to try to build rockbox as an sdl application using the devkitARM toolchain,
My goal is to port it to the Nintendo 3DS.
But for now I am wondering how does rockbox dynamically load codecs? Are codecs shared libraries?
Does it uses dlopen?
If so, is there another way to load codecs? Can I link them statically?
--- End quote ---
Codecs (and indeed, Plugins in general) are loaded via dlopen().
It's _possible_ (in the sense that it's all malleable code) to statically link everything in but it's going to bump the total binary (and code in RAM) size by ~5x and you'll need to implement an internal directory/lookup table so the playback engine knows how to look up any given codec. (There are other technical issues, such as the near-inevitable symbol collisions between 40-ish separate codecs that were never intended to coexist in a single executable)
Oh -- for an idea of the level of effort involved of a hosted SDL-based port, look at the Maemo or Pandora ports for inspiration.
gama:
Thanks speachy.
--- Quote ---It's _possible_ (in the sense that it's all malleable code) to statically link everything in but it's going to bump the total binary (and code in RAM) size by ~5x and you'll need to implement an internal directory/lookup table so the playback engine knows how to look up any given codec. (There are other technical issues, such as the near-inevitable symbol collisions between 40-ish separate codecs that were never intended to coexist in a single executable)
--- End quote ---
Actually I did that in the past when porting an obscure music player from the gp32 era to another obscure device. And indeed renaming functions to avoid symbol collisions was a pain in the ass and I just felt it was not the right thing to do.
I will ask at the devkitpro forums about it, hope dlopen can be implemented with the current toolchain.
Best.
speachy:
--- Quote from: gama on May 02, 2025, 05:21:25 PM ---I will ask at the devkitpro forums about it, hope dlopen can be implemented with the current toolchain.
--- End quote ---
You don't _have_ to use or implement dlopen(); you can implement it the same way that our native targets do things -- effectively, you'd produce a flattened binary file, load that into a buffer, then manually jump into its init/start function. Codecs (and plugins) aren't supposed to depend on anything other than what rockbox provides, and everything they need is provided in a table supplied to that init/start function.
On hosted platforms, codecs/plugins are already compiled with -fPIC so they are compltely relocatable. (We don't on hosted platforms as we run bare-metal with a fixed RAM layout. Not using -fPIC gives us a smidge more performance too, which really makes a difference on 25-year-old microcontrollers..)
gama:
I found an implementation to load dynamic libraries written for the Nintendo DS. It works in a similar way to that used for native targets as you described.
I will give it a try.
Thanks again man!
Navigation
[0] Message Index
[#] Next page
Go to full version