lwjgl & linux & webstart question

OpenGL Development
#1

Hi,

Sooner or later I guess I’ll have to make my game linux compatible too. Now I saw that there are 2 linux versions of the native part of lwjgl; a suse and a redhat. Now I know how to link the windows dll in the webstart launch file, but is there any way to distinguish between the 2 linux varieties in webstart?
Being a linux clewbie, I’m also wondering why there are 2 version for 2 linuxes. What about other linux varieties?

Greetings,
Erik

Hmmm… maybe this is more a webstart question than a lwjgl question after all ::slight_smile: but I couldn’t find the answer from the webstart doc and I’m not using linux (yet).

#2

There are two libs because the glibc major version is different on (at least) those two platforms, and the lwjgl lib depends on that. I don’t know how to specify which lib should be loaded by webstart, though, but I suspect that it possible somehow, because every other native lib will suffer from the same problem.

  • elias
#3

Is it not possible to use a lowest common denominator Elias? ie. are the old versions always present on a particular distro?

Or can you dynamically link against the bits that aren’t common?

Cas :slight_smile:

#4

Dunno.

In fact, I’m not doing anything in different ways depending on the distro, so the only problem is the naming of the standard C lib, because library names include version numbers on linux. And I don’t know if it’s easy to dynamically load standard libc.

One might be able to link to some common name for it, but that’s beyond my current linux C/C++ (linker) knowledge. It might even be impossible, knowing that C uses early linking.

No, the old libc’s are not always present on the distros, e.g. if you’re lucky, redhat only includes one older version than the current.

  • elias
#5

[quote]There are two libs because the glibc major version is different on (at least) those two platforms,
[/quote]
Why not provide a statically linked version?

Another alternative is to have 2 separate JNLP files -
one for RedHat and one for Suse.

#6

[quote]Dunno.

In fact, I’m not doing anything in different ways depending on the distro, so the only problem is the naming of the standard C lib, because library names include version numbers on linux. And I don’t know if it’s easy to dynamically load standard libc.
[/quote]
Maybe I’m whacked in the head here, but I thought that you weren’t supposed to link against version numbers? Instead, there’s supposed to be a symlink to the latest lib file. So libc.so might be linked to libc.so.2 and you can use the -Llibc option in the compiler. I’m probably oversimplifying it, but I do think this is possible.

#7

That’s right, but I’m not linking at all to libc - that’s done automagically by the compiler. So I think it’s doing it right. And besides - the symlink stuff is only to mask minor versions - so libc.6 is linked to, say, libc.6.1 and libc.5 is linked to something else. And that’s okay I think, there’s a reason major versions change…

  • elias
#8

Hmm, major incompatible versions are supposed to change their name like this:

libc.so.1
libc2.so.1
libc3.so.1

The only part I don’t get is, why does libc have a major revision? It is after all supposed to be “the standard C library”. New functions perhaps, but incompatible changes? Sometimes I don’t get these Linux guys.

A week or two ago, I was trying to install the NVidia drivers for Linux. So I went to their download site and was greeted by a bazillion files to choose from. Choose the wrong one and it wouldn't work (nice). Where did all the files come from? Different variations of distro and kernel revision. There wasn't a version for my Redhat kernel, so I downloaded the latest and figured I'd use Red Carpet to update my kernel. And I did. Only problem is, that now my kernel was newer than the patch! ARRRGGGHHH!!! Worse yet, I couldn't find a package for the version I actually needed. Surfice it to say, the damn thing still isn't installed.

Just out of curiousity, I looked at the FreeBSD stuff. Does anyone want to guess how many files there were for the various versions of FreeBSD? Anyone? There was… wait for it… ONE!!! That’s right, ONE frigging file. Pretty quickly here, I’m going to start telling Linus what he can do with his kernel design…

#9

On my system, it’s

[elias@ip172 elias]$ ll /lib/libc.so.6
lrwxrwxrwx 1 root root 14 Oct 5 14:24 /lib/libc.so.6 -> libc-2.2.93.so

the name before .so should only include library name, not version (unless it’s a complete rewrite of api or something, in which case it’s still a completely different library).

  • elias
#10

If I’m reading this thing correctly:

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#SONAMES

That means that it should be compatible with previous releases.

#11

[elias@ip172 elias]$ objdump -p /lib/libc.so.6 | grep SONAME
SONAME libc.so.6

Is what my system says about libc.so.6 - so a libc (so)named libc.so.5 is not compatible according to the link you gave, because the number immediately after .so. is a part of the SONAME. At least that’s how I’m reading it.

  • elias
#12

Hmm… maybe you’re correct. However, this part of the document:

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#UPSTREAMBROKENSONAME

shows the symlinking I was referring to. I don’t know if that’s a viable option, but it’s something to consider.

BTW, to the original poster, you could try having separate JARs for the two versions and setting them to manual download. Once your code is running, it would do a quick check of the system and then tell WebStart (using the webstart APIs) which version to download and use.

#13

[quote]The only part I don’t get is, why does libc have a major revision? It is after all supposed to be “the standard C library”. New functions perhaps, but incompatible changes? Sometimes I don’t get these Linux guys.
[/quote]
Ah, the trick I believe is that while source compatability is usually maintained over major versions, binary compatibility is broken every time. :wink:

#14

[quote]BTW, to the original poster, you could try having separate JARs for the two versions and setting them to manual download. Once your code is running, it would do a quick check of the system and then tell WebStart (using the webstart APIs) which version to download and use.
[/quote]
Smart :slight_smile:

Thanks,
Erik

#15

[quote]Ah, the trick I believe is that while source compatability is usually maintained over major versions, binary compatibility is broken every time.
[/quote]
This (and the other issues mentioned in the thread) is probably a good reason why linux will not ever be a real success on the desktop, isn’t it?
It all seems very awkward to me. (Man, I’ll never complain about a 15Mb driver download again ;))

#16

[quote]This (and the other issues mentioned in the thread) is probably a good reason why linux will not ever be a real success on the desktop, isn’t it?
[/quote]
Well, since you asked, no - in my opinion. ;D

Don’t you remember library hell on Win3.1? “Oh, this application needs vbrun300.dll” etc., and I’m sorry but there are things Windows does on the desktop that are easily as evil as needing a specific C runtime library. :wink:

Due to the way Linux is developed, you can expect the technology to be cutting edge, but the user-friendlyness will usually be behind. But I don’t worry - I believe all problems will be worked out in time. The advantages for me outweigh the disadvantages even now. ;D

#17

Well, everything looks good compared to the vbrun.dll uglyness doesn’t it? ;D
And windows 3.1??? I think most people (well at least me) are unwilling to remember that. :wink:

Other that, you’re probably right.
I’m just terribly lazy. ;D

Anyway bottomline seems to be: there’s no one unified way to install for linux since it is apparently not really one platform.

#18

Yeah, I guess that’s it. If you’re a sufficient wizard with automake/autoconf/libtool you can generate a source tarball that will compile itself using the installation libraries and install itself in the installation’s preferred directory, without the user doing anything more than running ./do_stuff.sh and entering the root password when requested.

Generally people don’t bother, and just provide a SuSE and RedHat binary RPM and a Debian binary DEB, and leave people to customise the build scripts themselves for the source package.

I don’t think it really matters either way, at least for the moment. Most people both running Linux and wanting to install LWJGL will not be fazed. Expect this to change in the future though! I don’t know what the solution will be then - I’m sure something will come along.