- [gst-plugins-good] 1.19.1

[SSE4]

Specify library name and version: gst-plugins-good/1.19.1

This is also a good place to share with all of us why you are submitting this PR (specially if it is a new addition to ConanCenter): is it a dependency of other libraries you want to package? Are you the author of the library? Thanks!

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[SSE4]

seems like cairo-gobject.dll is missing:

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[daravi]

@SSE4 Hi just wondering if this fell of the radar by accident or if it is blocked by something else?

[SSE4]

@SSE4 Hi just wondering if this fell of the radar by accident or if it is blocked by something else?

yes, it's definitely on my Radar. I had long x-mas holidays, but I hope tomorrow I'll take an another look.

[SSE4]

@SSE4 Hi just wondering if this fell of the radar by accident or if it is blocked by something else?

for the record, PRs to follow up: #8378 and #8800

[SSE4]

weird, I cannot reproduce failure locally with the same profile 🤔 perhaps, I'll try adding some additional logging. @daravi or maybe you can take a look if you have a time.

P.S. one more thing to be fixed, I'll open a PR:

WARN: pango/1.49.1: requirement glib/2.70.1 overridden by gst-plugins-base/1.19.1 to glib/2.70.0 
WARN: cairo/1.17.4: requirement glib/2.70.1 overridden by pango/1.49.1 to glib/2.70.0 
WARN: harfbuzz/3.2.0: requirement glib/2.70.1 overridden by pango/1.49.1 to glib/2.70.0 

[SSE4]

don't see much useful info...

23118:23f10 @ 818593484 - LdrpFindDllActivationContext - INFO: Probing for the manifest of DLL "C:\J\w\BuildSingleReference@2\.conan\data\gst-plugins-good\1.19.1\_\_\package\3bf60f0613e70e2876c6a5db6e066327b5b39e9c\lib\gstreamer-1.0\gstwavparse.dll" failed with status 0xc0000089
...
23118:23f10 @ 818593484 - LdrpInitializeNode - INFO: Calling init routine 00007FF941908CE4 for DLL "C:\J\w\BuildSingleReference@2\.conan\data\gst-plugins-good\1.19.1\_\_\package\3bf60f0613e70e2876c6a5db6e066327b5b39e9c\lib\gstreamer-1.0\gstwavparse.dll"
...
23118:23f10 @ 818593484 - LdrpInitializeNode - ERROR: Init routine 00007FF941908CE4 for DLL "C:\J\w\BuildSingleReference@2\.conan\data\gst-plugins-good\1.19.1\_\_\package\3bf60f0613e70e2876c6a5db6e066327b5b39e9c\lib\gstreamer-1.0\gstwavparse.dll" failed during DLL_PROCESS_ATTACH
23118:23f10 @ 818593484 - LdrpProcessDetachNode - INFO: Uninitializing DLL "C:\J\w\BuildSingleReference@2\.conan\data\gst-plugins-good\1.19.1\_\_\package\3bf60f0613e70e2876c6a5db6e066327b5b39e9c\lib\gstreamer-1.0\gstwavparse.dll" (Init routine: 00007FF941908CE4)
23118:23f10 @ 818593484 - LdrpUnloadNode - INFO: Unmapping DLL "C:\J\w\BuildSingleReference@2\.conan\data\gst-plugins-good\1.19.1\_\_\package\3bf60f0613e70e2876c6a5db6e066327b5b39e9c\lib\gstreamer-1.0\gstwavparse.dll"
23118:23f10 @ 818593484 - LdrpLoadDllInternal - RETURN: Status: 0xc0000142
23118:23f10 @ 818593484 - LdrLoadDll - RETURN: Status: 0xc0000142

0xc0000089 is STATUS_RESOURCE_DATA_NOT_FOUND
0xc0000142 is STATUS_DLL_INIT_FAILED

maybe something with manifest? UPD: it doesn't have a manifest, and it should be fine

[SSE4]

as it happens only with MT builds, this explanation appears to be logical:

FlsAlloc returned FLS_OUT_OF_INDEXES, which in turned failed the CRT initialization.
A little research shows that Fiber Local Storage has 128 slots per process;
each DLL statically linked to CRT will take a slot during CRT initialization.
There is possibility that if process has loaded too many DLLs and exhausted FLS slots,
then new DLL statically linked to CRT will fail to load, and that is exactly what we ran into.

as GStreamer for sure has lots of DLLs, and we could have easily loaded 128 DLLs linked with static runtime.
I am not sure, is it worth to provide this configuration at all in this case (shared + static CRT?)
some reading:
https://stevedower.id.au/blog/building-for-python-3-5-part-two
https://devblogs.microsoft.com/windows-music-dev/effectively-removing-the-fls-slot-allocation-limit-in-windows-10/

and difference with CI could be explained by FLS Slot Limit Increase in some Windows 10 build...

UPD: confirmed CI has FlsAlloc: 122 (mine limit is 4000+)

[conan-center-bot]

All green in build 13 (7ba69697ca84b23acabc092ffc4374183e570da3):

• gst-plugins-good/1.19.1@:
  All packages built successfully! (All logs)