After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 771505 - souphttpsrc can't open with official macOS / Windows build
souphttpsrc can't open with official macOS ...
Product: GStreamer
Classification: Platform
Component: cerbero
git master
Other Mac OS
: Normal blocker
: 1.10.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2016-09-15 21:38 UTC by Olivier Crête
Modified: 2016-11-01 19:52 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch to read the SSL libraries from a relative patch (11.00 KB, patch)
2016-10-24 18:44 UTC, Olivier Crête
none Details | Review
Updated patch (5.25 KB, patch)
2016-10-26 19:36 UTC, Olivier Crête
committed Details | Review

Description Olivier Crête 2016-09-15 21:38:44 UTC
This is on OSX 10.11, if I try to do a simple playbin uri= I get an "Unacceptable TLS certificate" error from libsoup, so I assume it can't find the system certificates, it seems like a build problem.
Comment 1 Sebastian Dröge (slomo) 2016-09-16 09:41:40 UTC
Comment 2 Tim-Philipp Müller 2016-09-28 19:33:28 UTC
<slomo> ca-certificates are shipped now with the packages
<__tim> someone needs to check if the certificates are going to be picked up now
<ocrete> also need to set the cert location in glib-networking*.recipe instead of --without-ca-certificates
<slomo> yes
<slomo> and it should ideally be relative to or something
Comment 3 Sebastian Dröge (slomo) 2016-10-24 11:40:04 UTC
Comment 4 Olivier Crête 2016-10-24 18:44:44 UTC
Created attachment 338366 [details] [review]
Patch to read the SSL libraries from a relative patch

This is one potential approach. The other possiblity is to just set the static path (although that won't work if you bundle GStreamer into the app bundle instead of installing the framework for everyone).
Comment 5 Sebastian Dröge (slomo) 2016-10-25 09:53:14 UTC
Review of attachment 338366 [details] [review]:

This is rather complicated though, but I guess makes sense. We should also do something similar for Windows, which needs different API (see gstregistry.c e.g. which checks the plugin directory relative to libgstreamer-1.0-0.dll).

Maybe we should check relative to the library, and if it's not there always check the environment variable?
Comment 6 Matthew Waters (ystreet00) 2016-10-26 04:41:01 UTC
Review of attachment 338366 [details] [review]:

::: recipes/glib-networking/0003-gnutls-Use-db-relative-to-libglib-2.0-if-needed.patch
@@ +44,3 @@
++#ifdef HAVE_DLADDR
++  gchar *free_me = NULL;
++  GTlsDatabase *db;

db needs to be outside the #ifdef as it's used outside any #ifdef's.
Comment 7 Olivier Crête 2016-10-26 19:36:45 UTC
Created attachment 338543 [details] [review]
Updated patch

Fixed the little problem that Matthew found, I also removed the bit that pointlessly updated the existing patches.

I'd like to propose this patch for 1.10 as otherwise the tutorial 4 doesn't work on macOS.
Comment 8 Sebastian Dröge (slomo) 2016-10-30 14:49:32 UTC
Review of attachment 338543 [details] [review]:

::: recipes/glib-networking/0003-gnutls-Use-db-relative-to-libglib-2.0-if-needed.patch
@@ +74,3 @@
+   anchor_file = g_getenv ("CA_CERTIFICATES");

This is broken: if both variables are set, you ignore the result of dladdr() and override it here. Also need to do the same for Windows still.

Otherwise good to go I guess
Comment 9 Sebastian Dröge (slomo) 2016-11-01 19:52:21 UTC
commit a05feb005ff3bc56beb704c0b1ed435219ca5876
Author: Sebastian Dröge <>
Date:   Tue Nov 1 21:51:12 2016 +0200

    glib-networking: Use a relative path for the SSL CA certs on Windows too

commit 660178471d36c4762dc2f70e1cdbcf7c2ddf4c15
Author: Olivier Crete <>
Date:   Thu Oct 6 16:05:44 2016 -0400

    glib-networking: Use a relative path for the SSL CA certs