Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » Library 101

This thread is locked; no one can reply to it. rss feed Print
Library 101
AceBlkwell
Member #13,038
July 2011
avatar

Edgar, (or anyone else with the answer),

A continuation from "back to our story" thread. I think I may have found another glitch in my static link saga. I am still getting errors. Some are different but I've played with the command line so much and/or have messed with Eclipse set up for this project, that it's not unexpected. As a result I decided to at least get back to where I was. So I went back to manually finding each file the linker is telling me isn't there.

/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lSM
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lICE
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lX11
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lXext
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lXcursor
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lXpm
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lXxf86vm

I found them all in /usr/lib64.

So I started reading up on g++ commands thinking maybe there is a specific order or something I'm over looking. Then I see where static libs in Linux ends in .a not .so. .SO are shared libraries as I read it. So I only have a liballeg.a the copies I find of the lib files listed above are all .so files. So I guess it's possible it is looking for .a files and they really aren't there.

Whats your take on it? Also if you remember when I tried to install each of the programs above, Slackware said they already existed. (I was using upgrade and SlackBuilds) Would I need to compile from scratch to get the .a versions to be created?

thanks for the help and patience.
Ace

bamccaig
Member #7,536
July 2006
avatar

I think that to get a true static build you'll need static builds of the dependencies too. Which means you probably can't use the system's package manager, and instead need to fetch the sources for all of it. That will be a lot of work of course, and involve a lot of research and guesswork. Somebody correct me if I'm wrong.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

The sad truth is on Linux you can't static link everything. You can static link some or maybe even most of it, but you're going to run into shared dependencies on system libraries. You need your users to install the same packages you did to build allegro.

Also, just link to the 64 bit shared versions. Most of those should be included or installed easily.

Ha.

I'm thinking all of this would be better provided by a build script for allegro and all the packages you need. Set a shell var for Linux flavor and package manager and then just run it once to install. Forget all this static linking garbage and just do it the way Linus Torvalds meant you to.

AceBlkwell
Member #13,038
July 2011
avatar

Edgar,

I think I'm with you. I'm going to forget the static link for Linux. Now i have a few questions to see if I understood properly.

All the needed Linux files will be included in Linux already. So when someone compiles the game, files like libX11.so etc will already be a part of the OS like it is with mine.

If that's the case they will need to install Allegro 4.4.2. Is it possible to just include the liballeg.so with the game so when compiling g++ will pick up on it?

Or even better, just include the needed allegro file so the precompiled file will work with out the need to compile?

My goal was to make the program independent so it would work without multiple compiles trying to figure out what missing. I mean the game isn't Doom or Wolfenstein Colossus. It would take a lot for a person to say "to heck with going through all this.";D

Thanks
Ace

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

All the needed Linux files will be included in Linux already. So when someone compiles the game, files like libX11.so etc will already be a part of the OS like it is with mine.

No, only the ones they also have installed. That means you need to provide a shell script or README_INSTALL file that tells them which packages they need to install with their package manager.

Ideally, you will only have to distribute allegro_monolith-5.2.so alongside your game. They should install everything else using their package manager.

See bamccaig's comment here : https://www.allegro.cc/forums/thread/617483/1038275#target

Use ldd to list the dependencies, and then distribute the ones you need alongside your game. Use the shell script to set LD_LIBRARY_PATH and run your exe.

bamccaig
Member #7,536
July 2006
avatar

All the needed Linux files will be included in Linux already. So when someone compiles the game, files like libX11.so etc will already be a part of the OS like it is with mine.

The various dependencies for Allegro will only be there in rare cases where the user has installed a similar library that needs all of the same things already. Some packages, like X11, are likely to be installed, but others like OpenGL graphics drivers and audio libraries that Allegro depends on will not. You will need to instruct your users how to install the missing pieces. The easiest way is by providing platform-specific installation instructions: a package manager command to execute is easiest. Giving them a script that does this automatically is even easier.

If that's the case they will need to install Allegro 4.4.2. Is it possible to just include the liballeg.so with the game so when compiling g++ will pick up on it?

Or even better, just include the needed allegro file so the precompiled file will work with out the need to compile?

As I said here, this likely won't work due to incompatibilities with the user's C runtime (i.e., libc.so). I think you'll need to bundle every shared object all the way back to the system core. And then when users run your game on their platform, they'll ignore their system files and execute with yours instead (you'll need to wrap your game in a shell script that sets up an environment so that this happens; it won't magically happen).

I think that this is sort of how Steam for Linux is distributed. At least, how it used to be before it was integrated into package repositories. For example, here's a community developed port of Steam for Debian Wheezy (before it was integrated into the repos): https://github.com/GhostSquad57/Steam-Installer-for-Wheezy. If you look in https://github.com/GhostSquad57/Steam-Installer-for-Wheezy/tree/master/steam-debian_source/usr/lib/steam/x86_64-linux-gnu you'll find it shipped libc, as well as ld and ld-linux (those are the dynamic library linking/loading code).

Basically if you want to distribute a binary package that will work across modern Linux distributions you need to ship everything. That is sort of the same technique that is used in Windows BTW. Most of the time an installer in Windows will include everything, or else will download or bundle installers for other dependencies. That's why it's such a mess in Windows. Linux still requires that mess if you eliminate the package repositories and system libraries.

So it seems your options are:

  • Full, static build. Super time consuming because you'll have to fetch and build all dependencies from source as static builds (some of which might not support it out of the box so you'll have to hack on them).

  • Dynamic build, needs to bundle all dependencies right down to the core system libraries.

  • Source release, which can be built against a particular system's packages. The system either needs to have Allegro packages already (fortunately, for Allegro 4, most Linux systems do), or you'll need to include instructions or build scripts to install Allegro or bundle Allegro sources with your project and build them at compile-time alongside your game.

  • Separate package targeting each supported Linux distro and version.

My goal was to make the program independent so it would work without multiple compiles trying to figure out what missing. I mean the game isn't Doom or Wolfenstein Colossus. It would take a lot for a person to say "to heck with going through all this.";D

If you do the hard work for them you can script it all up so that it happens automatically for them. Here I suggested wrapping your game in a launcher script that detects if it has been built yet, and installs the dependencies from the system repositories, and then builds the game. It could report to the user "first time setup..." I've seen this before in Windows software even so it shouldn't come as a complete surprise to the user. On the second run, it could skip the build-phase by detecting that the game executable exists, and immediately launch the game.

Basically, there is no easy button for you, but you can build one for your users.

Go to: