Hi,

I have application which use openal.dll / openal.so library.

On windows this is easy and clear. I just put all files into InnoSetup installer and my application find DLL in own directory.

But what with linux? I have installation script which:

- Copy executable to /usr/bin
- Copy icons to /usr/share/icons
- Add application to desktop menu bo copying .destkop file to /usr/share/applications

I also have uninstall script which delete those files.

But don't know what to do with openal.so library. Should I copy it to /usr/lib directory? But what if:

- This library already exists (installed e.g by apt-get install libopenal) and my uninstall script try to delete it?
- This library doesn't exists an my install script copy it to lib directory and then user try to install it by apt-get install libopenal. What will happen?

Can I create some my application dir in /usr/bin where I copy all files with librarys and only my application manage those librarys?

BTW: How linux librarys works? I mean, how portable application works. If I run executable from unzipped folder, this application find .SO library in that folder? (like on windows) Or must I create run.sh script which export this path?

Regards

You should not do it like this. Never every copy files to /usr/lib or so. If the user decides to install openal later, it will conflict with your install.

If your app requires openal/sdl or whatever, make sure that these libraries are installed through the packaging system. Either make a debian/rpm package, and add it to the dependencies.

If you want to create a script that installs it anyway, make sure it installs in to /opt/yourprogram/
with directories
bin
lib

Libraries go into lib.
Then create a startup shell script in /opt/yourprogram/bin that adds /opt/yourprogram/lib
to the
LD_LIBRARY_PATH
environment variable, after which it starts the real binary. (the installer should create this script)

Make a symlink to this shell script in /usr/bin or /usr/local/bin.

It's by far the easiest system.

Michael.

All this is not "installing in Linux" (which is the OS) but rather something like "installing in a desktop Distribution"

Does this work correctly with any distribution ?

-Michael

It would work in nearly any distribution that respects the normal file system layout (there are a few distributions that do their own thing). But it's definitely not a good thing to do it this way (see Michael van Canneyt's mail).

Regards,
Sven

2012/8/7 :

I like this solution with /opt. Must try it. Thanks

Hm, I don't know, works on ubuntu :) . This is script from some HOWTO article

Hi,

You should not do it like this. Never every copy files to /usr/lib or so. If the user decides to install openal later, it will conflict with your install.

Michael van Canneyt is correct. Under Linux, that is a bad idea and can cause all sorts of problems. As he pointed out, there are alternatives.

Or....

Try and use /usr/local/* directory hierarchy. eg; /usr/local/bin and /usr/local/lib
Most apps that install from source (not the packaging system) install to /usr/local/*
Obviously, conflicts could still occur, but maybe your installer could flag if a *.so already exists, and that flag will notify the uninstall script to NOT delete that file.

You could also have a $HOME/bin and $HOME/lib directories, and the .bashrc (or whatever terminal interface is used) adds $HOME/lib to the users LD_LIBRARY_PATH environment variable, and $HOME/bin to the PATH environment variable (the latter is normally done by the distro already). But this means that your installed program will only work for that user, not for the system wide users. But this is sometimes desired anyway.

Extending on the second example above. Some Linux specification (for single user setups) also recommed using the $HOME/.local/ directory hierarchy which contains 'share', 'lib', 'bin', and the *.desktop files go into $HOME/.local/share/applications/