Okay looks like uv.h is in /usr/include - I didn't catch that until reading
the message. So the pkgconfig file is likely correct and not a bug.
Probably then a bug in the makefile for what I'm building (newer cmake -
bootstrap builds, it's post bootstrap that fails)
On Sat, Oct 27, 2018 at 9:48 PM Michael Peters <pipfroschpress@xxxxxxxxx>
wrote:
> EPEL package but I think there's a packaging bug, thought I would ask
> here. Trying to build something that requires libuv-devel - it finds the
> .so but can't determine version.
>
> header files are in /usr/include/uv however the pkgconfig file specifies
> /usr/include as the include directory.
>
> The pkgconfig file also has the version so I'm not sure why the make file
> can't determine version, but maybe it is trying to get version from a
> header and looking in /usr/include instead of /usr/include/uv because the
> pkgconfig file doesn't specify the subdirectory?
>
> Other devel packages with header files in sub directory or /usr/include do
> list the sub directory in the pkgconfig file, so I think there might be a
> bug in that pkgconfig file because it doesn't?
>
> [alice@localhost ~]$ rpm -ql libuv-devel |grep include
> /usr/include/uv
> /usr/include/uv.h
> /usr/include/uv/errno.h
> /usr/include/uv/linux.h
> /usr/include/uv/threadpool.h
> /usr/include/uv/unix.h
> /usr/include/uv/version.h
> [alice@localhost ~]$ grep "include" /usr/lib64/pkgconfig/libuv.pc
> includedir=/usr/include
> Cflags: -I${includedir}
>
> I can file the bug report with EPEL (Fedora I think is where?) but don't
> want to if that isn't really a bug.
>
> Thank you for feedback.
>
> --
> *Notice*: Gmail is owned by Google, a company that made its fortune in
> content indexing and user tracking. It is logical therefore to assume that
> Google and quite possibly the government has access to any correspondence
> made with this account.
>
> Do not use correspondence with this account for sensitive information.
>
--
*Notice*: Gmail is owned by Google, a company that made its fortune in
content indexing and user tracking. It is logical therefore to assume that
Google and quite possibly the government has access to any correspondence
made with this account.
Do not use correspondence with this account for sensitive information.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
