On Thu, 6 Dec 2018 16:05:21 +0100 Michael Biebl <bi...@debian.org> wrote: > Am 06.12.18 um 15:49 schrieb Luca Boccassi: > > That header has always been a torn in the side, and should have _never_ > > been a public one, but unfortunately it's too late now. > > > > I'm actually wondering how it can work anywhere since it's always > > included and there's no libczmq-dev -> uuid-dev dependency... > > Hm, rsyslog *does* build-depend on uuid-dev. uuid-dev provides > /usr/include/uuid/uuid.h > > The code in czmq_prelude.h seems to include > uuid/uuid.h on Linux, (so the header from uuid-dev is found) and uuid.h > on kfreebsd. > > /usr/lib/$(MULTIARCH)/pkgconfig/libzmq.pc does *not* list uuid as > dependency even though the public headers do require it. > If uuid was list as Requires(.private), -I/usr/include/uuid/ would be > added to CFLAGS and the header would be found. > > So it works only by accident on Linux, since there it uses uuid/uuid.h > which doesn't require CFLAGS to be set properly.
Yes, that's indeed the root cause. I actually think I can get away with removing those includes from the public header - the only usage of those symbols is in the private modules. I struggle to think why or how an external dependency would happen to use libuuid without actually including the headers in the appropriate source files, and how it could get away with having it work by random chance of this other third party header including them. Currently testing this change, will upload soon. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
