[Libwebsockets] latest commit breaks DomTerm's http serving
per at bothner.com
Thu Oct 12 07:32:45 CEST 2017
On 10/11/2017 09:03 PM, Per Bothner wrote:
> On 10/11/2017 08:16 PM, Andy Green wrote:
>> On 10/12/2017 09:03 AM, Per Bothner wrote:
>>> ./configure --with-libwebsockets=/path/to/libwebsockets/build --without-qtwebengine --without-java
>> I tried this, but I met a couple of problems.
>> - lws wants libcap if it exists on your system but the link line
>> gcc -I/usr/include/json-c -I./lws-term -I/projects/libwebsockets/build/include -DRESOURCE_DIR='"../share/domterm"' -g -O2 -o ldomterm ldomterm-server.o ldomterm-utils.o ldomterm-protocol.o ldomterm-http.o ldomterm-whereami.o ldomterm-junzip.o /projects/libwebsockets/build/lib/libwebsockets.a -lssl -lcrypto -ljson-c -lpthread -lutil -lz
>> didn't include it.
> I'm working on a patch for this, but I need to test it more.
I checked in a patch for this. Configure now adds -lcap if libcap is
installed (as determined by pkgconf).
It does seem like this is a problem anyone trying to "package" libwebsockets
for Fedora or Debian: Should the libwebsockets package require libcap or not?
There seem to be two choices:
(1) the libwebsockets package requires the libcap package; or
(2) the libwebsockets package cannot use the libcap features.
A package maintainer has to choose between those options.
(It looks like the choice on Fedora was (1).)
More flexible would be two .so files and two packages:
(1) the libwebsockets package installs libwebsockets.so,
which does not depend on libcap.
(2) the libwebsockets-cap package installs libwebsockets-cap.so,
and depends on both the libwebsockets and libcap packages.
I don't know if this actually makes sense - just pointing out an
issue to be aware of.
per at bothner.com http://per.bothner.com/
More information about the Libwebsockets