Bug 105366 - 2.13.0 erroneously requires libuuid on macOS
Summary: 2.13.0 erroneously requires libuuid on macOS
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-06 12:03 UTC by ilovezfs
Modified: 2018-03-12 12:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch (1.22 KB, patch)
2018-03-08 09:20 UTC, Akira TAGOH
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description ilovezfs 2018-03-06 12:03:47 UTC
The uuid headers and functions are provided by macOS via

/usr/include/uuid/uuid.h
/usr/lib/libSystem.B.dylib
/usr/lib/system/libsystem_c.dylib

not via libuuid. So requiring libuuid on macOS, as is now what's happening with 2.13.0, is unnecessary.

I can work around it by setting

UUID_CFLAGS = " "
UUID_LIBS = " "

and removing uuid from PKGCONFIG_REQUIRES_PRIVATELY.
Comment 1 Akira TAGOH 2018-03-06 12:10:31 UTC
Hm, is it API-compatible with libuuid's?
Comment 2 ilovezfs 2018-03-06 12:22:12 UTC
This is uuid/uuid.h https://gist.github.com/ilovezfs/df61c1e98109cf557ae33e37ce552884
Comment 3 Akira TAGOH 2018-03-06 12:34:26 UTC
Aha. thanks.
hmm, the prototypes of uuid_parse/unparse seems a bit different. just wonder if we should have compat functions for them.
Comment 4 Akira TAGOH 2018-03-08 09:20:43 UTC
Created attachment 137886 [details] [review]
patch

How about this?
Comment 5 ilovezfs 2018-03-08 09:43:41 UTC
It works but will opportunistically use ossp-uuid if it's installed. Is that desirable? And how would you tell it to use system uuid even if ossp-uuid is installed?
Comment 6 Akira TAGOH 2018-03-08 09:58:37 UTC
(In reply to ilovezfs from comment #5)
> It works but will opportunistically use ossp-uuid if it's installed. Is that
> desirable? And how would you tell it to use system uuid even if ossp-uuid is
> installed?

In theory, you could simply set empty values to both UUID_CFLAGS and UUID_LIBS as you initially worked around. essentially speaking, this isn't to give one an option to choose what impl one prefer for uuid but is to avoid the build failure on checking the availability of uuid.pc even though it can be built without the external library.

I may add an option to configure if there are any platforms that have the external uuid library installed on the non-standard directory and without .pc. but is there any platforms like that?
Comment 7 ilovezfs 2018-03-08 10:02:20 UTC
Right, but the .pc still ended up claiming it needed uuid despite setting those to " ".
Comment 8 Akira TAGOH 2018-03-08 10:16:40 UTC
Sure. we should stop adding uuid to PKGCONFIG_REQUIRES_PRIVATELY if both UUID_CFLAGS and UUID_LIBS is set empty. then everything should be fine.
Comment 9 ilovezfs 2018-03-08 10:25:47 UTC
>if there are any platforms that have the external uuid library installed on the non-standard directory

I think it's /usr/include/uuid.h on FreeBSD. See https://github.com/firehol/netdata/issues/1644
Comment 10 ilovezfs 2018-03-08 10:42:12 UTC
That one may have a different API, though.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221293
Comment 11 Akira TAGOH 2018-03-08 10:46:30 UTC
Aha. thanks. but that can be fixed as it suggested there. so I'm assuming they could build it with this fix (+ replacing #include <uuid/uuid.h> to <uuid.h>) if uuid functions is in the standard C library.
Comment 12 ilovezfs 2018-03-08 10:48:29 UTC
Yup. So this is probably fine as-is.
Comment 13 Akira TAGOH 2018-03-12 12:56:01 UTC
should be better in git now. will fix further more when one found another issue around this. anyway, as defining _CFLAGS and _LIBS are the standard way to stop looking at .pc in pkgconfig, we will follow it up that way.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.