GP2X Open2x Libs: Commercial Games And Licenses

[efegea]

I'm developing a game that will be shown a demo to GPH to see the viability of making it commercial.

But I'm wondering about the license of open2x and the libs used in it. I know that with gcc, binutils, glibc, etc..I can make commercial games, but..and the libs? SDL is LGPL, but mikmod is GPL, should I recompile SDL_mixer without mikmod? And what about freetype, it's using the freetype license and the GPL, as I see on the gentoo packages website, but I don't understand at all the freetype license, can I use freetype on commercial projects, and so SDL_ttf? And what about the rest of libraries? Can I link them against a commercial game?

 

[Tony Hoyle]

I'm developing a game that will be shown a demo to GPH to see the viability of making it commercial.

But I'm wondering about the license of open2x and the libs used in it. I know that with gcc, binutils, glibc, etc..I can make commercial games, but..and the libs? SDL is LGPL, but mikmod is GPL, should I recompile SDL_mixer without mikmod? And what about freetype, it's using the freetype license and the GPL, as I see on the gentoo packages website, but I don't understand at all the freetype license, can I use freetype on commercial projects, and so SDL_ttf? And what about the rest of libraries? Can I link them against a commercial game?

With the LGPL you have to dynamically link not statically link (not normally a problem but you end up mucking with library paths). GPL code (directly or indirectly) is obviously a complete non starter.

libmikmod is LGPL so is fine.

Modern versions of freetype are dual licensed GPL/BSD+advertising clause, so you can use it in your commercial app (under BSD) provided you put credits in the documentation mentioning it (see http://www.freetype.org/freetype2/index.html)

Normally the only 'messy' license is the GPL... avoid that and you'll be fine.

 

[efegea]

So..I can't statically link LGPL libraries...

I have to statically link it because my toolchain is glibc 2.3 and the GP2X is glibc 2.2, so they are incompatible. How can I link it dinamically? Including all the .so files in the game dir and setting LD_LIBRARY_PATH?

 

[Tony Hoyle]

Obvious answer is to rebuild the toolchain with glibc 2.2...

Pretty much yes you'd just set LD_LIBRARY_PATH. Rename your application eg mygame.bin, then make the game itself into a shell script that works out the library path and sets it (on linux proper mozilla works like that).

To be extra safe rename the libraries you're linking to eg mygame-libsdl0.so so here's no chance of colission.

There may be a shortcut to doing this on the gp2x, because it's likely a common problem with commercial applications - I haven't (yet) done anything with the gp2x specifically so haven't really looked at it.

 

[Shikaku]

You can create an installer with source for those libraries.

 

[efegea]

But I still have the problem with glibc 2.2, the problem is in /lib/ld-linux.so.2, how can I make my game to use my own ld-linux.so.2?

 

[Tony Hoyle]

You don't.. that's the thing that loads the application in the first place. It will always work, unless your binaries are somehow broken.

(It's actually executable - it's valid to run an application as '/lib/ld-linux.so.2 /bin/ls' for example. In the days of old it was a cheap way to get around noexec settings on NFS drives..)

 

[efegea]

This is the error I'm getting:

[root@gp2x kurayagi]$./kurayagiLD.gpe
./kurayagi.gpe: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./lib/libdl.so.2)
./kurayagi.gpe: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./lib/libpthread.so.0)
./kurayagi.gpe: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./lib/libc.so.6)

 

[Tony Hoyle]

This is the error I'm getting:

[root@gp2x kurayagi]$./kurayagiLD.gpe
./kurayagi.gpe: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./lib/libdl.so.2)
./kurayagi.gpe: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./lib/libpthread.so.0)
./kurayagi.gpe: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./lib/libc.so.6)

Check your dependencies with ldd. It does sound like you're linking with dodgy versions of the libraries though.. have you had anything work with that toolchain?

Alternative is to *carefully* copy the libdl, libpthread and libc to your app directory and fiddle with LD_LIBRARY_PATH (I say carefully because if you overwrite the ones already there you'll bork the installation).

Ideally the toolchain should use exactly the same libraries as on the target device (give or take a couple of minor versions). That can be difficult to do arrange, but since compiling toolchains is a fairly involved process anyway it's not that much harder to fiddle with the build process..

 

[efegea]

Check your dependencies with ldd. It does sound like you're linking with dodgy versions of the libraries though.. have you had anything work with that toolchain?

I'm using open2x toolchain. I got statically linked apps working, but never a dinamically linked app

Alternative is to *carefully* copy the libdl, libpthread and libc to your app directory and fiddle with LD_LIBRARY_PATH (I say carefully because if you overwrite the ones already there you'll bork the installation).

I'm already doing that

 

[Tony Hoyle]

I'm using open2x toolchain. I got statically linked apps working, but never a dinamically linked app

Best to take it up with them then... maybe they just made a mistake & used the wrong glibc.

Does the standard toolchain work?

It's a really odd error to be getting... I've successfully run apps across multiple versions of glibc with no issues. It implies you're using something in the GLIBC_PRIVATE namespace (which is an error, because it causes exactly the problem you're seeing)..

 

[Mudi]

I've gotten dynamically linked stuff working, I remember having to work around some weird glibc errors though. It is possible using a glibc 2.3.5 toolchain though.

 

[efegea]

Best to take it up with them then... maybe they just made a mistake & used the wrong glibc.

Does the standard toolchain work?

It's a really odd error to be getting... I've successfully run apps across multiple versions of glibc with no issues. It implies you're using something in the GLIBC_PRIVATE namespace (which is an error, because it causes exactly the problem you're seeing)..

About the glibc..I tried to compile a gstreamer app but it segfaulted at something about pthreads, and a gstreamer devel suggest me about checking my glibc, because it was an odd problem. Perhaps it's an open2x toolchain problem, as you said.

 

[Tony Hoyle]

One workaround I've found via google is to create your own private lib, set LD_LIBRARY_PATH and bootstrap your application through the other copy of ld-linux.so.2 as in:

export LD_LIBRARY_PATH=/myapp/lib
/myapp/lib/ld-linux.so /myapp/bin/myapp

That is at best a hack though..


edit: Or, if you can fix the path to your glibc (eg. /lib-2.3.5):

Link with:

-Wl,-dynamic-linker,/lib-2.3.5/ld-linux.so.2 -Wl,-rpath,/lib-2.3.5/lib

Which sounds more like what you're after.. it does need a fixed location though...

 

[Tony Hoyle]

About the glibc..I tried to compile a gstreamer app but it segfaulted at something about pthreads, and a gstreamer devel suggest me about checking my glibc, because it was an odd problem. Perhaps it's an open2x toolchain problem, as you said.

Yeah one of the hardest things when you're building a cross compiler is matching the target libraries to be the exact same ones already on the device. glibc isn't too bad in this respect.. you can get away with quite a bit of difference in versions. With uclibc you even have to get the patchlevel correct (coped with that hell more than once!).

If you fail to match the versions you get odd failures where APIs behave slightly differently or an internal structure has changed. That can be 'fun' to track down..

 

[efegea]

One workaround I've found via google is to create your own private lib, set LD_LIBRARY_PATH and bootstrap your application through the other copy of ld-linux.so.2 as in:

export LD_LIBRARY_PATH=/myapp/lib
/myapp/lib/ld-linux.so /myapp/bin/myapp

That is at best a hack though..

That works!

Anyway, I'm going to try the official SDK

 

[skeezix]

You can also specify in the linker/gcc the path to the libs.. ie: 'stamp' the patch into the binary, so it looks there, without setting env; usually its easier to just ut a wrapper shellscript in place that does the env setup and anything else you need to do, but using the -Xlinker.... type notation to gcc works well. too.

BTW, fromthe above.. you can't just have an installer include source; thats moot -- you don't even need to provide it immediately, you can just provide it on demand at the web. However, they couldn't recompile it, which is the issue, which is why GPL stuff must be isolated from closed apps.. either in a sub-executable you call, or through other means.

For LGPL, check the license.. it is fairly forgiving.

jeff

 

[Tony Hoyle]

I don't think anyone would care if it was an opensource app - people mix different libraries in this way without checking the licenses all the time.. it's a technical violation but is rarely if ever picked up upon (and not something I would bother about myself).

Once you get into commercial territory you have to stick to the letter of the license. LGPL Section 6 states you either have to (a) ship the entire machine readable source code of the library that you used *and* provide the means to re-link your executable, or (B) use it as a shared library.

(a) is pretty hard to fulfill, since you have to ship more than the source - you need to provide (or at least give a bona-fide offer of) some means of relinking your application.
(B) is the easiest, but does require that you use shared libraries.

Commercial development is a pain because of this kind of stuff, but the lawyers tend to insist...

 

[Redeeman]

yeah, so just bundle the objects before you link it.

 

[BradN]

yeah, so just bundle the objects before you link it.

Seconded... if it's not an open source component, just include the object to allow relinking, and all is right in the universe.