My apologies, but i do not see anything out of the ordinary here i mean... there are programs out there which are building
1. A .so shared library
2. A .a static library
3. An executable as 'example' . Those are link against the .a.
Did i miss something?
Thomas
Paul Wise < [email protected]> hat am 26. Januar 2020 um 03:14 geschrieben:
On Sat, Jan 25, 2020 at 11:13 PM Sanford Rockowitz wrote:
What's unusual is that the command line version does not depend on theshared library. Both versions are built from the same source package...Is this design just atypical, or does it violate Debian practice in someway?It is hard to say without reviewing a lot libraries, but think thepractices of different upstreams vary widely, some tools solely wrapshared libraries, some have an additional "private" shared library,some use your approach.
I don't think it violates any Debian practice that I can think of.
One downside in the case of ddcutil is that the command-line toolswill have a different set of capabilities to any tools built on theshared library (GUIs etc).
BTW, are you aware of any effort to support DDC in the Linux kernel?It would be useful to be able to control monitor brightness etc fromstandard graphical interfaces that can currently only control laptopscreen brightness.
--bye,pabs
