Would be possible to build RT linked to external libraw instead of bundle own code of dcraw?
I’ve found this old ticket which was mainly focused on speed improvements, but it was briefly discussed also about security.
Having RT linked to external libraw can avoid backporting dcraw security patches which are already fixed in libraw.
There are discussions about using rawspeed. But that won’t happen shortly.
I mean that will make it easier with the shared library for rawspeed. Oh wait there is none 
1 Like
Of course if you can help convincing rawspeed upstream to provide a proper shared library … I am all for that.
It’s not so much about convincing. There are real technical issues that we have no idea how to overcome. So it’s not really worth the effort and hassles, just for the sake of having a shared library that people can replace on the fly.
Any problem that any other library is not facing as well?
I know that understanding if your broke your API/ABI is a bit harder with C++. The libzypp team just bumps the soversion with every release for that reason.
Anything else?
Because intree code copies are a maintenance nightmare. A minor one for you as a RS/DT/RT dev … a major one for every distribution.
The problem isn’t API/ABI. The problem is that camera support is a feature of the program, not the used library. So at any given time there is more or less a single version of rawspeed that has the right feature set: all cameras it’s supposed to support are supported, but none else. And that might very well be different for different programs using rawspeed. So having it as a shared library is basically not possible. I’d go as far as saying that librawspeed.so shouldn’t be a thing but only librawspeed.a should be built and linked.
2 Likes