Policy for PND maintainers re SuperZaxxon / .next handover

[Rockthesmurf]

I don't know offhand how to make my use of libm.so.6 static, maybe some -static linker flag before the -lm? Maybe something I'll have to look at, I'd certainly be interested to know exactly how big my binary is with everything statically linked. For a lot of reasonable sized games, the executable isn't that much weight compared to the assets; on top of this I do some pretty heavy compile/link optimizations to reduce binary size (probably more than the average build system will kick out).

 

[hmc]

Does anyone know, what Apple .app containers really contain? Are Mac OS binaries statically linked? How are such problems solved there? Maybe we can learn from it.

Btw: If I compile software on the Pandora, how do I make the binare statically linked instead of dynamically linked?

 

[Rockthesmurf]

@hmc a lot of stuff is dynamically linked, generally they ensure things don't break between versions, however I have had cases where a new OS update breaks existing software I have on the App Store meaning I have to compile against the latest SDK, fix any problems and upload a new version.

For your reference (possibly you already know), the .app container is actually just a directory, you can right click, show contents, (or ls -laF from a console) and view the full contents. For work, we do not use Xcode to build our iPhone builds, we do it from a custom build system (based on Jam) so we know exactly what files go into our .app file, and other than a few files for signing/description it really is just a directory list of all our assets and the executable.

 

[_wb_]

The main advantage of dynamic linking, in my opinion, is that if the libraries get bug fixes or improvements, you automatically benefit from that.

The main disadvantage of dynamic linking is of course that if the library becomes backwards-incompatible or gets dropped, you have a problem.

But small improvements happen much more frequently than big backwards-incompatible changes, and even if the latter affects you, you can still just do a quick repack without even having to recompile.

So in my opinion, static linking is only useful in these circumstances:

- You want your binary to run in a wide range of different environments (e.g. because you're doing a closed-source release), so you cannot assume anything about the presence of libraries

- The libraries are "good enough" for your use of them (not likely to improve or contain bugs), and you are releasing something that will not really be updated/maintained, i.e. development has stopped and you're releasing the "final" version.

In the context of the Pandora, I think static linking is only useful for finished closed-source games. Even then, if they rely on libraries like SDL, dynamic linking is probably better because tweaks in such libraries could be beneficial and they're unlikely to break backwards-compatibility.

 

[Rockthesmurf]

@_wb_ everything you say makes sense; the only thing I would throw in, is if you posed this question at any games development studio who put out console titles:

'Do you want to know your game will run exactly as you have tested it in house, or are you happy for it to run against the latest libraries available on the users system with the chance it may run better, but may very occasionally cause problems'

I can't imagine many (any?) studio would say they are happy with the latter. They want the software to ideally run exactly the same way it runs in QA/testing. They really don't want different users having different experiences based on their environment. It loses control plus fragments (if a user has a problem, you can't just check which version of the game you are running, you actually need to know the version of all their dynamic libraries too, what a nightmare).

So it isn't that I am disagreeing, I think given the Pandora community and titles in question, having everything released as large PNDs with everything statically compiled in would potentially be silly/wasteful. But as the amount of resources spent ensuring a title works correctly increases, the more resistance there may be for having that carefully tested experience potentially be different per user. When you throw into the mix titles making money from the repo, where rating has an impact sales, it becomes even more costly to risk having system libraries breaking a release and drawing negative reviews.