shared libs and different distributions
Hi everyone.
I've read the "Shared Libraries Problem" thread and the links leading to more information. So, I know how to create shared objects and how to load them.
Now, I'm in the situation that a) I'm not a Linux guy, b) I don't have much Linux experience and c) I have my SSCXML lib that compiles under Ubuntu.
So far so good... what I wonder now is this: Having compiled my lib under Ubuntu, can I distribute it and it will work on different distributions (Suse, RedHat, ...) ?
I remember that some years ago you'ld have to recompile your application/lib for every distribution in order to work. Is this still the case?
Thanks,
Metron
afaik yes, should work.
You should compile and link using -fpic.
I don't understand the details myself so here's what the manpage says:
A common problem thou is glibc, if glibc has a higher version on the machine on which you compiled, the executable will not work on system which doesn't have this specific version of glibc installed. So if you want to distribute something as a binary don't use a brand new distribution, but something older/more common.
You should compile and link using -fpic.
I don't understand the details myself so here's what the manpage says:
-fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-spe‐ cific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for Sys‐ tem V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. When this flag is set, the macros "__pic__" and "__PIC__" are defined to 1.A common problem thou is glibc, if glibc has a higher version on the machine on which you compiled, the executable will not work on system which doesn't have this specific version of glibc installed. So if you want to distribute something as a binary don't use a brand new distribution, but something older/more common.
Quote:Original post by Metron
I remember that some years ago you'ld have to recompile your application/lib for every distribution in order to work. Is this still the case?
It may still be the case.
You may be able to have your compiled binary work on different distros if it is compiled for the same architecture as the different distro using the same ABI and if all its dependencies are matched by those supplied on the distro.
If you are targetting a 32-bit Intel architectire (i386) and the other distros are compliant to the same LSB version as the version of Ubuntu you used, chances are you will not have problems. Otherwise, you takes your chances.
Any popular Linux distro uses a package manager to make sure installation is painless and straightforward. Package managers make sure that all dependencies must be satisfied before installation will complete, and you need to build your package so that it makes explicit its dependencies. Nobody in their right mind in the Linux world distributes plain libraries or applications.
You probably need only provide a subset of package targets: 32- and 64-bit RPM and DEB packages for the current Debian and Fedora will probably work on the majority of Linux desktops out there (for example, a DEB package targetted at the current i386 Debian will work on the current i386 Ubuntu).
Hi,
thanks for your replies... not quite encouraging... I hoped that Linux had overcome these issues...
The package manager hint sounds good. I'll take a look into this. I'll google for it but you don't have a good introduction link by hand, have you?
Thanks,
Metron
thanks for your replies... not quite encouraging... I hoped that Linux had overcome these issues...
The package manager hint sounds good. I'll take a look into this. I'll google for it but you don't have a good introduction link by hand, have you?
Thanks,
Metron
Quote:Original post by Metron
... you don't have a good introduction link by hand, have you?
This is a good place to start.
I don't know if your library is under an open source license or not. If it is, I would simply offer the .tar.gz and maybe provide binary packages for the most popular distributions. Then have all the packagers of other distros worry about packaging it for all the other distros.
Hi,
nope... no open source or so... It's an implementation for Win32 and WinCE in the origin. I had some requests for a Linux version, so a friend of mine counter checked and adjusted to make it compile for Linux.
Now, I have installed a VM with Ubuntu on it and can compile the .so file. I'll have to pack it up and check, if it works on another distribution. Will take me longer than expected since (as I said) I'm not quite firm with Linux.
Thanks for the suggestion though.
Metron
nope... no open source or so... It's an implementation for Win32 and WinCE in the origin. I had some requests for a Linux version, so a friend of mine counter checked and adjusted to make it compile for Linux.
Now, I have installed a VM with Ubuntu on it and can compile the .so file. I'll have to pack it up and check, if it works on another distribution. Will take me longer than expected since (as I said) I'm not quite firm with Linux.
Thanks for the suggestion though.
Metron
Just a bit of clarification on the PIC (position independent code). PIC is what makes "shared objects" really shared. Windows has no PIC, and most .dlls are not "shared" in memory properly. Each process gets it's own copy of the library in RAM (thus taking more space), whereas .so files are truly shared in RAM. For this to work tho, their pointer code has to be special. It has to be in-direct. This was a cause for alarm in the past because it means it's slower, but with todays CPUs and optimizations they provide (some specific for this) the speed difference is trivial.
As for the linux library problems, they won't get solved. It's how the system is designed. Even with all dependencies met, you can't expect a binary to work when compiled on different versions of Linux. Although backwards compat usually works (so if you compile on old distro it should work on new one, but you might end up having problems with missing libc5 for example).
As for the linux library problems, they won't get solved. It's how the system is designed. Even with all dependencies met, you can't expect a binary to work when compiled on different versions of Linux. Although backwards compat usually works (so if you compile on old distro it should work on new one, but you might end up having problems with missing libc5 for example).
So if I understand correctly, anyone wanting to distribute binaries to Linux distributions has to counter check if it actually works on the different distributions. How does one cope with such much work?!?
Not to sound harsh here, but this makes me really wonder how the Linux-defenders expect the Linux distribution to replace Windows on the common user machine?
I'ld really like to distribute my lib to the Linux users. I'm currently looking into how to do this in the smoothest way. I don't want to compile it on the distribution upon installation because that would make my code public... and I don't want that... believe it or not, I was asked if the Linux distribution does cost anything. When I said that the license costs are the same as for the Windows distribution, I was told (citation) "I did not switch to Linux to pay for a software or a library... can't you give me just the code? I'll compile it myself."
Well... I'll keep trying... thanks for you information. You're really helpful and I understand that I still have some stuff to learn :)
Metron
Not to sound harsh here, but this makes me really wonder how the Linux-defenders expect the Linux distribution to replace Windows on the common user machine?
I'ld really like to distribute my lib to the Linux users. I'm currently looking into how to do this in the smoothest way. I don't want to compile it on the distribution upon installation because that would make my code public... and I don't want that... believe it or not, I was asked if the Linux distribution does cost anything. When I said that the license costs are the same as for the Windows distribution, I was told (citation) "I did not switch to Linux to pay for a software or a library... can't you give me just the code? I'll compile it myself."
Well... I'll keep trying... thanks for you information. You're really helpful and I understand that I still have some stuff to learn :)
Metron
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
