Time For Dynamic Linking?

[Pickle]

didnt get this during the weekend, actually spent the time on my top project
but i will try to do something with this idea to try and get the ball rolling

 

[Pickle]

didnt get this during the weekend, actually spent the time on my top project
but i will try to do something with this idea to try and get the ball rolling

ok i dont if I have time to divide all of the functions, I dont know how the author would take it either. Id rather devote time to coding my own projects. I havnt even had to use the minlib.

What I woud like to see is all of the exisiting libs as they are be setup to handle being linked statically. Ive never linked statically in linux, so it would be a new thing for me.

 

[Pickle]

I did a little more research and came across the following: Guide
Probally the most important is this page: Example

Looks like we need to set LD_LIBRARY_PATH before runtime
Looks like the correct location should be ' /usr/local/lib', (i think the the NAND would be the logical choice to store them?)
The examples use ldconfig to setup symbolic links, but it may just be better to do it manually with ln
The libraries built by open2x project I think are ready to be linked as shared libraries, since they have the sonames. I think we just need to do the above and this might be doable.
It makes sense in my opinion to control this effort under the open2x project since thats where the libs are coming from.

 

[rlyeh]

I'm sorry to drop in so late here. Life's busy ™.

I'm already coding for a solution that might help someway.

I had a cross-porting library long time ago, named HPL which never saw any light outside my old laptop.
However, I've started migrating this C code to C++ a few days ago.

This new tiny C++ library is designed to standarise main hw (input/video/sound/cache etc) for small programs (like ports) at no slower cost than coding for the real thing ™.

Ie, the video interface supports 0/90/180/270º framebuffers, handles palette/hicolor transparently, vsync, cache, N-buffering, etc. The sound interface handles mono/stereo, sound callbacks / interrupt driven, etc. The input interface is unified and should work great for most systems, etc.

It's mostly based on templates to generate efficent meta-code whereas possible.

The results are promising, although the lib it is only a prototype at the time of writing this.

I had though about using this for my own W32, Wiz, GP32, GP2X and Pandora common unified SDK (for that project which you already know...).

So, if anybody is interested in this library, I'll post more details while I'll be progressing on it.


PS: This won't replace the old minilib though, since that one is too much hw dependant. If anyone is thinking about recompiling the GP2X minilib projects with this lib with no extra effort, I have to say that we would still need another layer to do the recompilation. And that code will be slower than rewritting the program for the new library.

 

[Pickle]

Can you make the it a shared lib so that you compile a version for each device and then the applcation only needs to be compilied once so that when its run it will dynamically link to the lib?

 

[rlyeh]

Can you make the it a shared lib so that you compile a version for each device and then the applcation only needs to be compilied once so that when its run it will dynamically link to the lib?

It won't work that way, since most (if not all) the code of the library is in the headers.
So the generated code is incrusted into your code after preprocessing and before linking.

I doubt my library might help you in this case, as it will need recompilation for every new release.

Notice that the main benefit of using my library is to insert handy lowlevel code transparently on your code, making cross-porting easy and fast.

Making an external library would require invoking the library through functions, and this would include probably some extra penalties which I doubt it might be worth to try.

 

[Svartalf]

Inputs - those are not unified from what I've seen, different for every system (depend on how backed is ported). For GP2X, inputs returned depend even on SDL version being used!

That, my friend, is a problem with the person doing the backend stuff not the lib itself. It's otherwise consistent across the other platforms. I know this because I write to the SDL for all my game dev efforts. Having said this, unifying the efforts on the handheld space probably wouldn't be a bad thing.

QUOTE

While SDL can do some of the tasks, does it have overclocking stuff? Direct control over vsync? Framebuffer cache control? TV-out control functions?



These can be done as an add-on lib, much like SDL_mixer and SMPEG have been done in the past.

QUOTE
What about people who don't like SDL?


There's ClanLib and Allegro as well that accomplish this work. My only concern is now you've got people using SDL on the Pandora (And if you don't use SDL, there's quite a few games out there that would now HAVE to be ported instead of just a simple recompile if you don't have it...) and now you're reimplementing the wheel because you think it's bloated and "don't like it"- adding bloat to the firmware in the process.

The real question is, what don't people like about it and can it be something that can be fixed or is it something that they're just going to be unhappy with even with your reimplementation because you can't do some tasks much differently? I'm not going to tell you "no", but the bulk of this sounds more like edge specific cases rather than real issues that merit a new lib.

Having said this, if Rlyeh has actually done a relatively thin shim that doesn't bloat up an app TOO much, you can offer it as a choice. If he's not doing too much in it, inlining won't be too bad. Just remember, though, it's not the same thing as static linkage- each time you call the "function" it stuffs the code for the function into the code stream, enlarging it by that much. Might not be a bad thing for a small 2D game, but a detailed game or a 3D one may present problems with this method.

 

[notaz]

and now you're reimplementing the wheel

I'm not doing anything, those just were thoughts.

Personally I would not use rlyeh's new lib, because it would force me to use C++ when I don't really need it.

 

[Svartalf]

I'm not doing anything, those just were thoughts.

No biggie. This is a discussion about the very thinking we're all having here anyhow.

QUOTE

Personally I would not use rlyeh's new lib, because it would force me to use C++ when I don't really need it.


Heh. You would only need to use it at edges. You can do almost all pure C within C++- and the beauty of what he's doing, if he's careful, would be that you probably wouldn't need libstdc++ anywhere in the mix.

But, that's what SDL is for as much as anything else. Largely language neutral, platform neutral. We have a few edge cases where we probably need to come up with SDL_handheld or somesuch like it where we cover things like setting the clockspeed gear, etc.

 

[AireTamStorm]

I've already recommended dynamic linking for the Pandora so the support libraries can be updated without having to recompile the main app. If we could start doing it on the gp2x under Open2X it would be excellent. Just need to have an alternative to Rlyeh's MiniSDK (or the SDK in it's own library so compatability layers can be implemented for other platforms).

I thought you were against that.

 

[Squidge]

I thought you were against that.



I am, to some degree. Standard libraries will ship with the Pandora, if you want to use different ones, or a different version, then you need to static-link or include them with your app.

 

[Sphinxter]

A necessary evil. It will reveal itself as the versions of the OS multiply and obsolete library versions are removed and backward incompatibilities emerge. Fixing it needs to be a user function. I would think about cutting up that flash, minimal read only version that just works to update the other user version, My shopping carts would check a store server for flash update files and if newer install them and swap it in at power up. Was a feature of Linus Torvalds midori linux distro at trans-meta. Bet you could do it nicely now with the uh, ah damn it, replaced initrd, built into the kernel, haven't done it in a while, now I have to go look, shit.

 

[yosh64]

hey

Ye, I dunno if it would be such a great idea. As what happens if/when some lib breaks? then everything goes down with it. Hmm, or it becomes incompatible with the version used by the software? bye bye software.

I mean, just go try use some old linux software that uses old dynamic libraries, just a pain I thinks.

cyas

 

[Squidge]

Ye, I dunno if it would be such a great idea. As what happens if/when some lib breaks? then everything goes down with it. Hmm, or it becomes incompatible with the version used by the software? bye bye software.

Old software uses old libraries, new software use newer libraries.

The library version is encoded in the filename, so if library becomes no longer backwards compatible, then the major version is changed and we just have two libraries.

Thats how linux works. It's not like Windows and "wrong version of dll".