Remove build time constraint on glib 2.80 on windows

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I've started rerendering the recipe as instructed in #125.

If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!

Here's a checklist to do before merging.

• [ ] Bump the build number if needed.

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[hmaarrfk]

did this before i forgot.

[hmaarrfk]

@conda-forge-admin please rerender

[github-actions[bot]]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/gstreamer-feedstock/actions/runs/8590082655.

[hmaarrfk]

seems like we need to wait a little. https://github.com/conda-forge/glib-feedstock/pull/172

[hmaarrfk]

@conda-forge-admin please rerender

[hmaarrfk]

@xhochy do you htink it is an issue with the gstreamer build system?

[90/258] "link" @gst/gstreamer-1.0-0.dll.rsp
FAILED: gst/gstreamer-1.0-0.dll 
"link" @gst/gstreamer-1.0-0.dll.rsp
   Creating library gst\gstreamer-1.0.lib and object gst\gstreamer-1.0.exp

gst.c.obj : error LNK2019: unresolved external symbol libintl_bindtextdomain referenced in function init_pre

gst.c.obj : error LNK2019: unresolved external symbol libintl_bind_textdomain_codeset referenced in function init_pre

gst\gstreamer-1.0-0.dll : fatal error LNK1120: 2 unresolved externals

[91/258] "cl.exe" "-Ilibs\gst\base\gstbase-1.0-0.dll.p" "-Ilibs\gst\base" "-I..\libs\gst\base" "-I." "-I.." "-Ilibs" "-I..\libs" "-Igst" "-ID:/bld/gstreamer_and_plugins_1713441659415/_h_env/Library/include/glib-2.0" "-ID:/bld/gstreamer_and_plugins_1713441659415/_h_env/Library/lib/glib-2.0/include" "-ID:/bld/gstreamer_and_plugins_1713441659415/_h_env/Library/include" "/MD" "/nologo" "/showIncludes" "/utf-8" "/W2" "/O2" "/Gw" "/wd4018" "/wd4146" "/wd4244" "/wd4305" "/utf-8" "-DG_DISABLE_CAST_CHECKS" "-DHAVE_CONFIG_H" "-DBUILDING_GST_BASE" "-DG_LOG_DOMAIN=\"GStreamer-Base\"" "/Fdlibs\gst\base\gstbase-1.0-0.dll.p\gstbaseparse.c.pdb" /Folibs/gst/base/gstbase-1.0-0.dll.p/gstbaseparse.c.obj "/c" ../libs/gst/base/gstbaseparse.c
ninja: build stopped: subcommand failed.

[xhochy]

This doesn't include intl.lib in the libraries to link. This previously worked as those symbols were also statically linked on glib.lib.

Otherwise, this recipe will need an update on using the right gettext outputs but that is not required to make it work.

[hmaarrfk]

Got it thanks.

I'll look into patching and upstreaming a patch for the build system.

[xhochy]

I'm confused, though, as to why it does work on osx, as there, one would also need to link against libintl.dylib. This has been dynamic since years. Only Windows changed.

[hmaarrfk]

well your help is obviously welcome in tracking this down ;) i just didn't want to to ask of you to do too much ^_^

[ryanvolz]

FYI, I'm tracking a similar problem down with atk over at https://github.com/conda-forge/atk-feedstock/pull/22. @xhochy Does it make sense that we should be adding explicit linking to libintl on Windows in these various downstream packages? It seems lots of things are implicitly relying on it coming from glib, but I haven't followed what prompted the recent glib changes to know if this is really what was intended.

[xhochy]

Does it make sense that we should be adding explicit linking to libintl on Windows in these various downstream packages?

Yes, it does.

This could partly be down to glib but also party down to their mingw-support. There, you don't need to explicitly link libintl but the necessary functions are already part of the C runtime.

[xhochy]

Windows builds have passed, so this will soon be ready for merge.