Hello,
I recently discovered that libraw under Unix builds to an archive file of .o's. This means Shotwell (the program we're developing here at Yorba) is statically linking with libraw.
Is there any work being done to make libraw build to a shared library, i.e. libraw.so? This would be a huge help, as it means we can tell users to upgrade their version of libraw without the need to recompile Shotwell.
-- Jim
Unfortunately, LibRaw is
Unfortunately, LibRaw is binary incompatible between major versions (i.e. 0.13 vs 0.12), so binary upgrade is really not possible.
Compatibility is ensured only within stable versions of one release (0.12.3 should be compatible with 0.12.99).
This is other side of active development....
-- Alex Tutubalin @LibRaw LLC
That's fine, I understand
That's fine, I understand that when the API/ABI changes this isn't so simple. But that doesn't mean each version can't be a shared library (i.e. libraw.so). That way if a user upgrades from 0.12.2 to 0.12.3, they get all the benefits of bug fixes without having to recompile all the software that uses libraw.
But another problem raise: -
But another problem raise:
- imagine someone installed, say, Program1 0.AA.BB with LibRaw 0.11 (shared)
- then he/she wants to try, say, Program2. Progam 2 requires LibRaw 0.13-Beta (shared) because it uses exposure correction feature.
So, user SHOULD rebuild/reinstall Program1 with LibRaw 0.13. But he wanted only to play 5 minutes with Program2, nothing more.....
The shared library are very good idea if
- API/ABI is very stable (but frozen API stops development of new features)
- API is made via non-virtual function calls instead of direct access to parameters structure. This way produces zillions of getters/setters with no idea behind. Also, it is harder to make C++ derived classes, because virtual methods table is fixed too, so no way to add/change function calls.
- there are good .SO/DLL version management, so each program uses own version of LibRaw.so/dll. But this broke the idea of quick 'security/bug fixes'.
You may be *stable* (in terms of API/ABI) but it will slow progress because programmer will need to do tricks (to stabilize APIs and so) instead of doing things.
I hope, after verisions 0.14 or 0.17 LibRaw will be stabilized: we need plugin registration interface, so all extensions will run with stable internals. But not now.
-- Alex Tutubalin @LibRaw LLC
This is an old, old debate
This is an old, old debate that goes back to when shared libraries were first developed. Your examples are fine, but consider the common case of wanting to take advantage of the bugs fixed in 0.12.3. Users of 0.12.2 need to rebuild all software that depends on libraw. For many users, this is unacceptable.
One common way to deal with the API/ABI problem is to say that the API won't change for a given release number, say, 0.12. In 0.13, the API might change (or it might not). Software writers can deal with this as they like.
I would encourage you to examine how other open-source projects deal with this problem. Almost all open-source libraries out there with unstable APIs release their software as shared libraries.
Some people would say there is no such thing as a stable API; even mature libraries, like GTK, are still undergoing revision.
Finally, note that packaging libraw into a .so does *not* force everyone to use it as such. Application writers may statically link in the .o's if they want.
Again, if I have software-1
Again, if I have software-1 compiled with 0.12 and then install software-2 which requires 0.13, I need to rebuild software-1. For many users this is unacceptable too.
There is a very good solution: shared library versioning. It works well for near-stable products/libraries, not for new versions every 2-4 weeks (current LibRaw).
When LibRaw becomes more stable in terms of API, we'll definitely switch to shared libraries with versioning.
-- Alex Tutubalin @LibRaw LLC
I'll say it again: Look at
I'll say it again: Look at the UNIX world and see how it's done. LibRaw is not so unique. Plenty of other software libraries have encountered these issues, and yet they distribute as shared libraries right from the start.
Believe it or not, it can work. What's more -- and I hope you take this to heart -- library versioning is not a problem you need to solve. It's been solved elsewhere. Please investigate before you go down that path.
You're right. But from *my*
You're right.
But from *my* point of view, it is too early to go shared, because too many things will change in LibRaw in near future. We definitely will switch to .so, but not now.
So, if you wish to make .so package for Unix/Linux systems, you'll do it on your own risk.
-- Alex Tutubalin @LibRaw LLC
Shared libraries and Ubuntu
Shared libraries help distributors, even if the interface is constantly changing. Currently with static libraries, we have to keep rebuilding shotwell manually when we update libraw.
If you generated a shared library, we would make a binary package for this, e.g. libraw13 containing /usr/lib/libraw.so.13.0.0. Shotwell would be linked against this. If you release a new libraw with API changes, then we would make a new binary package libraw14 containing /usr/lib/libraw.so.14.0.0.
This is much the same as the statically linked case, but the advantages are:
- We can easily detect that shotwell is using the old libraw version as we would no longer be able to build libraw13. So we can automatically mark shotwell as needing a recompile.
- If you make a point release and don't change the major version number then no recompilation is required
- If we patch libraw then no recompilation of shotwell is required.
From a distributors point of view we don't mind how often you change the library version number (so if you don't want to make ABI guarantees then just keep increasing the version). libraw.so.999.0.0 is fine with us.
Because LibRaw is so widely
Because LibRaw is so widely used, I agree that shared libs looks comfortable. I wanted to delay sharedlibs until LibRaw 1.0, but you're so impatient.
If you can provide patches for configure.ac/Makefile.am, these patches are welcome.
The only question is right shared library versioning.
LibRaw API/ABI does not change within major *stable* release (i.e. 0.12.0-Release and 0.12.5-Release have same API and same control structures layout).
API usually changes within Alpha development cycle (from Alpha1 to Beta1) and may change during Beta cycle (between Beta1 and .0-Release).
Is it better to have permanently incrementing library version (i.e. 0.14.Alpha1 ->so.5.0, Alpha2->so.6.0 and so), or version numbers should be incremented only for -Release libraries?
-- Alex Tutubalin @LibRaw LLC
I need to compile LibRaw as a
I need to compile LibRaw as a .so (to use on Android) I'm going to try my hand at making these patches, but I have no idea what I'm doing. If you could provide some help, I'd very much appreciate it lexa! ;)
Starting with version 0.13.2,
Starting with version 0.13.2, LibRaw supports shared libraries.
Just use ./configure (then make && make install) and you'll get libraw.so.2 in your /usr/local/lib
-- Alex Tutubalin @LibRaw LLC
Got this to work, cross
Got this to work, cross compiling for android. So I want libraw.so.2? I have libraw.a, libraw.so, libraw.so.2, libraw.so.2.0.5 (all exact same size)
libraw.so (generic), and so.2
libraw.so (generic), and so.2 (generic version 2) should be symlinks to so.2.0.5 (exact version).
You need to specify -lraw to linker command line and linker will do all magic.
-- Alex Tutubalin @LibRaw LLC
Instructions for Android?
Any chance someone can point to a guide to compile this for Android?