Static Or Dynamic Linking Of Libraries

[AireTamStorm]

An interesting topic that came up in this poll really kinda took off, but never came to a decisive conclusion: How developers should be encouraged to link libraries into their applications.

The result is the same, an application gets onto the Pandora and runs. There are a few key differences, however, that will affect the user in one way or another. The first is obviously, how the application and its libraries will get onto the device.


For Static Linking of libraries:

Ease of use
Like the GP2X before it, one would be able to copy an app onto an SD card, pop it in, find and run it. This is the familiar way.
Library Compatibility
Statically linked apps were developed with the library version they use, so library incompatibility is a not-gonna-happen.
No Risk of breaking applications by accidentally deleting a library on the system.
Since there less libraries to remove, theres less of a chance of a user inadvertently breaking their apps.

For dynamic Linking of libraries

The OS would be able to be incrementally updated more easily.
All of the software on the system "grows up together", and is updated along with other libraries.
Dynamic linking avoids alot of potential OS bloat, and removes the need for a daunting monolithic firmware update to fix stuff.
Dynamic linking of all libraries allows for every library to be independently updated.
Statically linking all libraries is almost considered alien by most Linux users.
A good portion of the community here runs Linux and consider the Pandora more as a gaming-oriented Linux computer rather than a console.

Ultimately there are more considerations than these to make, and I can't list them all.

 

[TaG]

This poll needs a fence - so I can sit on it.

I read the other post but kept agreeing with each post that makes sense. Does this again boil down to whether Pandora is a linux computer with gaming controls or a games machine with computing capability?

I thought I wanted dynamic, but then I want to ensure that the games just work. In the other post Squidge and Tobriand seemed to be agruing that it is best to download the app with libraries. I definitely agreed with that, but am not sure where that leaves the ability to use linux ARM apps.

I think I want both.... So I'll vote later if I ever get to truly understand the implications.

 

[parag0n]

If an application uses a LGPL library, and statically links it, the application needs to be LGPL/GPL too ( this is one of the stipulations of the LGPL, which allows dynamic linking but not static ).

If the library is dynamically linked, there is no problem.

 

[Squidge]

Depends on the app.

Eg. A frame buffer game that used one or two non-standard libraries, then it should be statically linked. Your not going to that get many other apps using the same libs.

However, an app that depends on KDE, X, etc that a lot of other apps would use too, then it should be dynamically linked.

So I'm not going to vote, as you didn't provide enough options.

 

[TaG]

Depends on the app.

Eg. A frame buffer game that used one or two non-standard libraries, then it should be statically linked. Your not going to that get many other apps using the same libs.

However, an app that depends on KDE, X, etc that a lot of other apps would use too, then it should be dynamically linked.

So I'm not going to vote, as you didn't provide enough options.

+1

That sums it up nicely for me : both. Then devs decide what is appropriate presumably?

 

[sindbad]

Couldn't an app simply include the libraries it needs and dynamically link those?

The biggest issue is memory usage. If two instances of the same dynamically linked app get started at once, there will only be one version of the libraries in memory, not two as it would be with statical linking.

This seems a no-brainer to me.

 

[DJWillis]

The Static/Dynamic thing is something that keeps coming up and it really is a case by case answer.
Not to mention the preference of the developer. Unitask or multitask apps etc.

For most simple apps there will be a rich set of dynamic libs in the firmware (and some ways to install extra libs) but there are snags.

The main one that jumps to mind is there is not an infinite amount of fixed NAND and if your dynamicly linking in lots of extra libs you will have to make arrangements for them to be available (on the SD card?). They will also need to be available on most of your SD cards if you use apps that need them from card to card.

Still, it is something that is the subject of some very active discussion on #PandoraDev and something that has several very workable solutions. It's a case of trying a few ideas and seeing what works well at this stage. I also have some ideas of my own I am playing with.

 

[PokeParadox]

I think it would be great if the Pandora had a set of dynamically linked libs that are automatically updated if improvements are made. Bases that should probably be covered are things like SDL, OGLES2, SDL_mixer, OpenAL?
Basically the most commonly used and useful libs. Anything other than that would be statically linked...

That's just how I see it in any case.

 

[AireTamStorm]

Depends on the app.

Eg. A frame buffer game that used one or two non-standard libraries, then it should be statically linked. Your not going to that get many other apps using the same libs.

However, an app that depends on KDE, X, etc that a lot of other apps would use too, then it should be dynamically linked.

So I'm not going to vote, as you didn't provide enough options.

Ah, I knew I was forgetting something. Of course, many applications would benefit from one or the other specifically, so if you would like, you could separate it into three categories:
"Generally" (the current poll results)
"For Games"
"For Applications"

Or something similar.

 

[Arialia]

I think it would be great if the Pandora had a set of dynamically linked libs that are automatically updated if improvements are made. Bases that should probably be covered are things like SDL, OGLES2, SDL_mixer, OpenAL?
Basically the most commonly used and useful libs. Anything other than that would be statically linked...

That's just how I see it in any case.

I agree with you , i want add SFML because this lib could use OpenVG and OGLES2 in future, so all games/apps made with it could benefit of optimizations of using OpenVG without recompiling ( if modifications are good and new interface are compatible with older versions of course .... )