Please, don't start a fight about where to install my stuff.

I'll still have to decide on that taking into consideration how I want to distribute my lib. It's basically a developer lib to include the scxml standard into their application. Mainly, what I supply is an SDK. I could consider this as a hint to leave it to the ones who distribute their application where to put the .so file after all. So, please no fights about this issue.

I think I got my reply after I'd posted my dependencies. It should work on all major distributions.

Thanks,
Metron

Quote: Original post by Metron
I'll still have to decide on that taking into consideration how I want to distribute my lib. It's basically a developer lib to include the scxml standard into their application. Mainly, what I supply is an SDK. I could consider this as a hint to leave it to the ones who distribute their application where to put the .so file after all.

As so much in the world of closed versus open source, this is an almost religious issue (as you could notice ;). So the best thing is to develop your SDK in a way that will enable a developer to deploy the library wherever he deems best for his particular application and target audience.

Quote: Original post by Metron
I think I got my reply after I'd posted my dependencies. It should work on all major distributions.

Yep.

Quote: Original post by Yann L
In my opinion, putting a library into /usr/lib or similar is the same bad practice as copying your DLLs into Windows\system32. You just don't do that, unless there is a very good reason to (drivers, system libs, etc).

There is a substantial difference between two. In Windows you *blindly* copy the library, without any package management at all - there is no version keeping, nothing keeps the track of it. That is what was creating the dependency hell. The same situation just doesn't apply to GNU/Linux world. That's why you need to create these three different packages for different distributions - to integrate your library with the system, so that it does not create such dependency hell.

If you would look at virtually any package for any modern GNU/Linux you would see that absolutely *none* ship external dependencies with the package. This is the difference. In Windows you install a program and, if you are missing a dependency, it just doesn't work. (So, every application has to ship with their own libraries.) On a modern GNU/Linux the package management system, while installing the application, says to you „this package cannot be installed since you do not meet the dependencies; do you want to download them?”.

Yes, putting your library *manually* in /usr/lib is a very bad practice, but putting it there using a package management system is not.

Well, anyway. This won't really lead anywhere, so let's just settle this here. To each his philosophy.

Metron, if you have any more questions, this thread is yours again ;)

Thanks :)

Quote: Original post by Metron
Please, don't start a fight about where to install my stuff.

I'll still have to decide on that taking into consideration how I want to distribute my lib. It's basically a developer lib to include the scxml standard into their application. Mainly, what I supply is an SDK. I could consider this as a hint to leave it to the ones who distribute their application where to put the .so file after all. So, please no fights about this issue.

I think I got my reply after I'd posted my dependencies. It should work on all major distributions.

Simple, you should start forgetting about distributions and start considering just compiler (GCC) versions and standard library issues.

If your library is made completely in C, the only issue would be the version of glibc that your library is linked against, such as glibc 2.2, 2.3, etc. Providing a compiled version linked against each version of glibc would be awkward, but it shouldn't break on system updates, as most distributions provide old versions of standard libraries to run binary applications.

GCC issues were more of a pain in C++, as in GCC 2.x/3.x the C++ ABI changed a lot, stabilizing in 4.x, bringing the stability you should need.

Lots of distros also include old gcc runtime files to run applications compiled to gcc versions older than the currently installed.

Just provide documentation to developers as what GCC/glibc/stdc++ versions you used to compile, so they'll be aware of pointing out old library (in the future of course) dependencies in their documentations.

The problem here is that people think "Linux" is some sort of windows. It's not, it's just a kernel.

Ubuntu is it's own OS, so is Fedora or Arch.

If you pack a .deb for Ubuntu don't expect it to work on Fedora. I don't expect my Vista specific apps to work on win95 either.

Lately the situation is improving tho, LSB 3.1 ensures about 6 years of ABI backwards compat. Packaging is still a bit of PITA but that's mostly a philosophy difference.

You see in Linux distroes, packaging is usually not done by the devs. The devs release source, and people who are interested in the program package it for their distributions.

In case of closed source programs tho, you're pretty much on your own. But even that's slowly getting better, RPM and DEB will probably get more or less "unified" (they will remain on the bottom but the upper part won't mind which).

However for games and applications a tar.gz or say one of the installers can't do wrong (make sure you use an installer which knows how to put shortcuts to menus according to freedesktop.org and can install/uninstall to local dirs). Pack your own libaries with the game (except for basics like libc of course) and use a .sh with LD_LIBRARY_PATH to start the thing.

As for compat, the biggest issue nowadays is GLIBC and usage of too new lib versions (or specifically depending on them). The glibc spec. version dependence can be fixed by turning off some stuff when compiling with gcc (-fnostack-check or somesuch).

Best bet to get a proper binary redistributable to multiple distroes is to get an older distribution (gcc 3.x era, not 2.x) and compile on that (say in vmware or such).

As for glibc: If you link against an old version of glibc, your program should work flawlessly with a newer version of glibc. The glibc maintainers are very thorough when it comes to compatibility in this area.

The only real world problem with linking against glibc I've ever encountered is the gcc stack protector. The stack protector is a security measure intended to make stack overflow exploits less likely. It requires support by glibc which was introduced in 2.3 or 2.4. Some extremely conservative distributions (aka Debian) still ship an ancient glibc which doesn't support that [1], so you'll have to compile with -fno-stack-protector to make them happy.

As for other libraries, you'll have to check on a case-by-case basis which functions you're using and when they were introduced in the library.

cu,
Prefect

[1] Last I checked, this was still the case in April 2008. Who knows, maybe they've fixed it since then, but somehow I doubt it.