Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Motsognirson]

This may reveal my ignorance of the dynamic library linking paradigm, but is it possible to compile a Dwarf Fortress binary for Linux that doesn't need any .so files?

I am trying to run Dwarf Fortress on a 64 bit machine that I don't have admin privileges on, so there are lots of multilib (?) shared object files that aren't installed.  I have been copying some over from my own 64 bit laptop and just dropping them into the libs/ directory.  To be specific, I am running Arch and I've been copying .so files from my own /usr/lib32/ directory.

This process seemed to get me closer to running the executable, but then I ran into a big wall because that machine didn't have a new enough glibc version (I assume I am missing some updated header files).

I figure if I could make an un-linked executable, I should be able to right it no problem.  Would such an executable be prohibitively large?

Thanks for any input.

[wierd]

static linking is a thing, yes.

However, Toady owns the source, has said he will never release the source, and without that source  we  cant build a statically linked binary.

Most try to avoid static linking, because it includes all the bugs of the libraries, permanently, inside the executable.  when they are linked externally, updating the library can fix problems with the libaray's bugs without having to recompile the software using it. (usually).

[lethosor]

The OS X and Windows builds also distribute several libraries (although Linux is the only platform where libgraphics, DF's graphics code, is also a dynamically linked library).

[Kamamura]

static linking is a thing, yes.

However, Toady owns the source, has said he will never release the source, and without that source  we  cant build a statically linked binary.

Most try to avoid static linking, because it includes all the bugs of the libraries, permanently, inside the executable.  when they are linked externally, updating the library can fix problems with the libaray's bugs without having to recompile the software using it. (usually).

That depends solely on how well the code in question is maintained. Libraries evolve constantly, some functions change behavior, some are deprecated, then removed completely. If a code is not maintained and uses dynamic libraries, one day it usually stops working. Static linking freezes the versions of the libraries in time, so the statically linked binary usually works the same way often years after the support was dropped. Also, for critical stuff like shell, it's often better to have a static library so that you won't deny yourself a remote access to a machine by a poorly planed upgrade.

[Motsognirson]

Thank you for the replies!

However, Toady owns the source, has said he will never release the source, and without that source  we  cant build a statically linked binary.

This seems to be quite a hack, in fact the author admits as much, but this program does seem to attempt to take dynamically linked binary + .so files and create one (giant) bundled static executable, no?

http://statifier.sourceforge.net/

I tried this and got an error because (as far as I could tell), the program didn't want to create a 32bit binary on my 64bit laptop.

[Max™]

Wait, it won't run from inside of your home folder, or did you mean you can't get stuff installed under your /usr section?

[Shashu]

Personally I just download the Windows version and run it in Wine. I find it runs at least as well, or better.

[Motsognirson]

Wait, it won't run from inside of your home folder, or did you mean you can't get stuff installed under your /usr section?

It won't run from inside my home folder (missing libraries) and I can't get anything installed into /usr.  I also don't have privileges to use a package manager.  I am essentially wondering if, in this age of dynamically linked libraries, it is possible to have a stand alone version of Dwarf Fortress run from one's own $HOME.

[Max™]

Down that way lies all sorts of screwed up file trees.

I suppose you could try something like putting a /usr folder inside /home with the library in there and symlink to it, I used to know stuff for doing that off the top of my head, but oddly enough after switching to arch I haven't needed to do it since. It's generally not the best idea though, where is the person with the admin privileges?

[draeath]

Note you can put the libraries anywhere you want and set the variable LD_LIBRARY_PATH to include the normal paths plus your new paths.

This will make the linker search your custom directories for .so files, so you can use your own local libs

EG:

Code: [Select]

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/whoever/lib
./dwarf-fortress-super-happy-funtime-go


[Max™]

THAT'S WHAT IT WAS, thanks on their behalf! I was trying to remember how I did that before to fix df before I moved to arch which happily has really good df support.

[Motsognirson]

where is the person with the admin privileges?

So you sniffed me out.  I was trying to use the nice computers at my work to run df, at least for world gen

I did get a (long history) world generated eventually, so for now my interest in this question is purely academic.