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 720778 - gst-uninstalled requires building with libtool
gst-uninstalled requires building with libtool
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-12-19 21:50 UTC by Brendan Long
Modified: 2016-02-18 18:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove libtool from uninstalled environment (137 bytes, application/x-shellscript)
2015-01-20 15:21 UTC, Heinrich Fink
  Details
I was not aware a bug was already open with a script too, so I made a patch by hand. It keeps .la though. (4.24 KB, patch)
2015-10-11 08:56 UTC, Julien Isorce
none Details | Review
uninstalled.pc: add support for non libtool build systems (1.05 KB, patch)
2016-02-05 09:06 UTC, Julien Isorce
none Details | Review
gst-core: uninstalled.pc: add support for non libtool build systems (3.74 KB, patch)
2016-02-05 09:06 UTC, Julien Isorce
none Details | Review
gst-plugins-bqse: uninstalled.pc: add support for non libtool build systems (11.33 KB, patch)
2016-02-05 09:07 UTC, Julien Isorce
none Details | Review
gst-plugins-bqd: uninstalled.pc: add support for non libtool build systems (5.62 KB, patch)
2016-02-05 09:07 UTC, Julien Isorce
none Details | Review
orc: uninstalled.pc: add support for non libtool build systems (1.46 KB, patch)
2016-02-18 07:55 UTC, Julien Isorce
committed Details | Review
gst-core: uninstalled.pc: add support for non libtool build systems (5.54 KB, patch)
2016-02-18 07:55 UTC, Julien Isorce
committed Details | Review
gst-plugins-base: uninstalled.pc: add support for non libtool build systems (13.29 KB, patch)
2016-02-18 07:56 UTC, Julien Isorce
committed Details | Review
gst-plugins-bad: uninstalled.pc: add support for non libtool build systems (9.83 KB, patch)
2016-02-18 07:56 UTC, Julien Isorce
committed Details | Review
gst-rtsp-server: uninstalled.pc: add support for non libtool build systems (1.72 KB, patch)
2016-02-18 15:58 UTC, Julien Isorce
committed Details | Review
gst-editing-services: uninstalled.pc: add support for non libtool build systems (1.77 KB, patch)
2016-02-18 15:59 UTC, Julien Isorce
committed Details | Review

Description Brendan Long 2013-12-19 21:50:27 UTC
When you use gst-uninstalled, the -uninstalled.pc files are used, which directly install .la files. This is annoying when working with Qt, because qmake's "compile_libtool" option is broken, and they seem to have no interest in fixing it:

https://bugreports.qt-project.org/browse/QTBUG-35745

For me this is particularly annoying since WebKitGTK won't let me link against .so files and QtWebKit won't link against .la files. I think I found a solution though.

I'm using this sed script on our gst-uninstalled environment:

    find . -name '*-uninstalled.pc' -exec sed -i -e 's/Libs: \(-L${libdir} \)\?\(.*\)\/lib\(.*\)\.la/Libs: -L\2 -l\3/' {} \;

Which, written in English means that any line that looks like this:

    Libs: /home/blong/gst/git/gstreamer/gst/libgstreamer-1.0.la

Turns into:

    Libs: -L/home/blong/gst/git/gstreamer/gst -lgstreamer-1.0

And any line that looks like this:

    Libs: -L${libdir} ${libdir}/libgstmpegts-1.0.la

Turns into this:

    Libs: -L${libdir} -lgstmpegts-1.0

With that change, QtWebKit and WebKitGTK both build, but I don't understand libtool well enough to know if this is actually correct. If it is, I could make this change in the .in files.

Does this make sense? Does this cause problems on non-Linux platforms?
Comment 1 Sebastian Dröge (slomo) 2014-01-03 08:59:16 UTC
You could replace CC/LD/etc with "libtool --mode=link gcc" too to fix this btw :)

I'm not sure why we need the .la files at all here, I currently can't think of a reason. And would like to change it like you mentioned.

Tim, do you remember anything? The only thing .la provides on top of what we have is the dependency_libs, but those should always be explicitly linked in anyway.
Comment 2 Brendan Long 2014-01-03 23:30:07 UTC
(In reply to comment #1)
> You could replace CC/LD/etc with "libtool --mode=link gcc" too to fix this btw
> :)

I'd like to, but qmake's libtool support is broken and they don't seem interesting in fixing it:

https://bugreports.qt-project.org/browse/QTBUG-35745
Comment 3 Brendan Long 2014-01-03 23:34:40 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > You could replace CC/LD/etc with "libtool --mode=link gcc" too to fix this btw
> > :)
> 
> I'd like to, but qmake's libtool support is broken and they don't seem
> interesting in fixing it:
> 
> https://bugreports.qt-project.org/browse/QTBUG-35745

Oh and I can't directly set CC and LD, since libtool throws away the -shared flag that qmake gives it, and there's no reasonable way to force that. I could add -Wc,-shared, but then it would *always* pass that flag, which also breaks things... :(
Comment 4 Heinrich Fink 2015-01-15 16:07:27 UTC
I would also be interested in gst-uninstalled loosing the libtool dependency, since we are using cmake (using the pkg_search_module command), and that doesn't work well with gst-uninstalled today.

I tried your script with our CMake setup, but I had to modify it a bit (append "/.libs" to the -L paths):

find . -name '*-uninstalled.pc' -exec sed -i -e 's/Libs: \(-L${libdir}\)\?\(.*\)\/lib\(.*\)\.la/Libs: -L\2\/.libs -l\3/' {} \;

This turns

Libs: ${libdir}/libgstrtspserver-1.0.la

into

Libs: -L${libdir}/.libs -lgstrtspserver-1.0

That seems to work quite well with CMake.
Comment 5 Heinrich Fink 2015-01-20 15:21:55 UTC
Created attachment 295002 [details]
Remove libtool from uninstalled environment
Comment 6 Heinrich Fink 2015-01-20 15:24:05 UTC
Comment on attachment 295002 [details]
Remove libtool from uninstalled environment

Line-breaking swallowed a space in my previous comment, which made the find command unusable. I have therefore attached the command in this file.
Comment 7 Julien Isorce 2015-10-11 08:53:18 UTC
+1, our usecase is chromium and it does not use libtool.
Comment 8 Julien Isorce 2015-10-11 08:56:38 UTC
Created attachment 313050 [details] [review]
I was not aware a bug was already open with a script too, so I made a patch by hand. It keeps .la though.

No need to review this patch, I think someone would just need to run the other command line and make a patch for core, base, good etc...
Comment 9 Sebastian Dröge (slomo) 2015-10-11 09:35:36 UTC
Having both .la and the normal library in there is not really great. Other compilers/linkers could (rightfully) fail as the .la file is something they don't understand.
Comment 10 Julien Isorce 2015-10-11 10:04:36 UTC
> compilers/linkers could (rightfully) fail as the .la file is something they
> don't understand.
This is currently the case in upstream and with the classic gcc and on linux. (.la are in pc uninstalled). Also I am confused since you said in other bug that .la are required for proper link/runtime.

How to move forward then ? :)

With current gst upstream I cannot compile chromium within gst-uninstalled. I really need whatever fix (mine or Heinrich's script) which fixes the problem. (so that with the fixes I can link and run Chromium within gst-uninstalled)

To avoid .la errors:

gcc $(pkg-config --cflags --libs-only-L gstreamer-1.0) test.c \
    -o test $(pkg-config --libs-only-l gstreamer-1.0)

Chromium was already using these options --libs-only-L and --libs-only-l for glib for example.
See: https://chromium.googlesource.com/chromium/src/+/master/build/linux/system.gyp#923

So I suggest to have both (-L, -l and .la) in the pc uninstalled. Apps that do not use libtool will have to use --libs-only-L and --libs-only-l. Which provide a way to compile against gstreamer, what it is not possible with current upstream.

I am open to any suggestion :)
Comment 11 Philip Withnall 2016-01-16 14:57:40 UTC
(In reply to Julien Isorce from comment #10)
> > compilers/linkers could (rightfully) fail as the .la file is something they
> > don't understand.
> This is currently the case in upstream and with the classic gcc and on
> linux. (.la are in pc uninstalled). Also I am confused since you said in
> other bug that .la are required for proper link/runtime.
> 
> How to move forward then ? :)
> 
> With current gst upstream I cannot compile chromium within gst-uninstalled.
> I really need whatever fix (mine or Heinrich's script) which fixes the
> problem. (so that with the fixes I can link and run Chromium within
> gst-uninstalled)
> 
> To avoid .la errors:
> 
> gcc $(pkg-config --cflags --libs-only-L gstreamer-1.0) test.c \
>     -o test $(pkg-config --libs-only-l gstreamer-1.0)
> 
> Chromium was already using these options --libs-only-L and --libs-only-l for
> glib for example.
> See:
> https://chromium.googlesource.com/chromium/src/+/master/build/linux/system.
> gyp#923
> 
> So I suggest to have both (-L, -l and .la) in the pc uninstalled. Apps that
> do not use libtool will have to use --libs-only-L and --libs-only-l. Which
> provide a way to compile against gstreamer, what it is not possible with
> current upstream.
> 
> I am open to any suggestion :)

As Sebastian says, I don't think it's a good idea to have both .la files and -L/-l flags in the *-uninstalled.pc file.

Note that your use of the .libs directory in -L flags implies that libtool is being used //somewhere//, because that's a libtool-specific output directory.

For Linux, I think a patch based on applying the script by Heinrich seems reasonable. Basically, I can't see why the *-uninstalled.pc file has to look any different to the normal *.pc file in structure; it just needs the uninstalled -L paths rather than the installed ones.

However, the problems will probably start to appear when building against GStreamer on other (non-Linux) platforms. I don't really know what libtool does here, except that its main purpose is to abstract the differences between platforms. That said, are the .pc files actually used for non-Linux builds? If not, there's no problem.
Comment 12 Julien Isorce 2016-01-18 10:12:49 UTC
(In reply to Philip Withnall from comment #11)
> For Linux, I think a patch based on applying the script by Heinrich seems
> reasonable. Basically, I can't see why the *-uninstalled.pc file has to look
> any different to the normal *.pc file in structure; it just needs the
> uninstalled -L paths rather than the installed ones.
> 

Thx Philip for confirming. I'll make the patches, I will just copy past Libs: fields from "*.pc.in" to corresponding "*.uninstalled.pc.in".

> However, the problems will probably start to appear when building against
> GStreamer on other (non-Linux) platforms. I don't really know what libtool
> does here, except that its main purpose is to abstract the differences
> between platforms. That said, are the .pc files actually used for non-Linux
> builds? If not, there's no problem.

Then I'll have a try on OS X. Is someone using GStreamer uninstalled on Windows ?
Comment 13 Julien Isorce 2016-02-05 09:06:00 UTC
Created attachment 320484 [details] [review]
uninstalled.pc: add support for non libtool build systems
Comment 14 Julien Isorce 2016-02-05 09:06:46 UTC
Created attachment 320485 [details] [review]
gst-core: uninstalled.pc: add support for non libtool build systems
Comment 15 Julien Isorce 2016-02-05 09:07:17 UTC
Created attachment 320486 [details] [review]
gst-plugins-bqse: uninstalled.pc: add support for non libtool build systems
Comment 16 Julien Isorce 2016-02-05 09:07:51 UTC
Created attachment 320487 [details] [review]
gst-plugins-bqd: uninstalled.pc: add support for non libtool build systems
Comment 17 Julien Isorce 2016-02-05 09:13:09 UTC
Upon comment #11, I would like to push these 4 patches (first one is for liborc).

I think it is safe since gst-uninstalled is only used on Linux. (On OS X it does not work with current upstream, see https://bugzilla.gnome.org/show_bug.cgi?id=761581, and is independent of these 4 patches).

I can send a pre-email on the mailing list and after pushing if someone hits a problem in the future we would still be able to either revert or fix it.
Comment 18 Sebastian Dröge (slomo) 2016-02-16 12:09:24 UTC
Let's get this in immediately after 1.8.0 release. Not sure how this works though: ${libdir} is e.g. gstreamer/gst but that one only contains the .la file. The .libs directory contains the actual .so file that would be needed by non-libtool build systems. How does it work? :)
Comment 19 Julien Isorce 2016-02-17 09:10:22 UTC
(In reply to Sebastian Dröge (slomo) from comment #18)
> Let's get this in immediately after 1.8.0 release. Not sure how this works
> though: ${libdir} is e.g. gstreamer/gst but that one only contains the .la
> file. The .libs directory contains the actual .so file that would be needed
> by non-libtool build systems. How does it work? :)

That is a great question :) Indeed in the first attachment the sed command contains ".libs" and I missed that.

So upon your remark I digged out more and here are the reasons why it still works:

1* Case when still using libtool:
libtool --mode=link gcc -Wall helloworld.c -o helloworld $(pkg-config --cflags --libs gstreamer-1.0)
It works because it finds the .la that -L path. This case is what actually happens for all gst-* build. So in the end it is not really different than without using attached patch.

2* Case when not using libtool:
gcc -Wall helloworld.c -o helloworld $(pkg-config --cflags --libs gstreamer-1.0)
It works because all those .libs paths are in the LD_LIBRARY_PATH which is customized by gst-uninstalled script (https://cgit.freedesktop.org/gstreamer/gstreamer/tree/scripts/gst-uninstalled).
(I had a try to just remove $GST/gstreamer/gst/.libs from LD_LIBRARY_PATH and then it tries to link with the system lib /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so)

I could just keep the patches like they are because of 1) and 2), but in other hand I think it is better to add missing ".libs" so that we know what we are doing.
Comment 20 Sebastian Dröge (slomo) 2016-02-17 09:17:06 UTC
1) is clear, for 2) gcc should not look into LD_LIBRARY_PATH for linking at all but only at -L and the default search paths. That seems weird.
Comment 21 Julien Isorce 2016-02-17 23:06:18 UTC
(In reply to Sebastian Dröge (slomo) from comment #20)
> 1) is clear, for 2) gcc should not look into LD_LIBRARY_PATH for linking at
> all but only at -L and the default search paths. That seems weird.

From the web "As an often unwanted side effect, LD_LIBRARY_PATH will also be searched at link (ld) stage". 
At least on my config there is this side effect, I let you experience it, just do "export LD_LIBRARY_PATH=/home/somewhere" with libany.so in it and then just invoke gcc sample.c -o sample -lany. (export call is required, just passing the env var at the same time does not reveal the side effect).

At least it is pretty clear we should not rely on this side effect :). I'll update the patches and make another go on Linux and OS X.
Comment 22 Julien Isorce 2016-02-18 07:55:06 UTC
Created attachment 321562 [details] [review]
orc: uninstalled.pc: add support for non libtool build systems
Comment 23 Julien Isorce 2016-02-18 07:55:52 UTC
Created attachment 321563 [details] [review]
gst-core: uninstalled.pc: add support for non libtool build systems
Comment 24 Julien Isorce 2016-02-18 07:56:30 UTC
Created attachment 321564 [details] [review]
gst-plugins-base: uninstalled.pc: add support for non libtool build systems
Comment 25 Julien Isorce 2016-02-18 07:56:58 UTC
Created attachment 321565 [details] [review]
gst-plugins-bad: uninstalled.pc: add support for non libtool build systems
Comment 26 Sebastian Dröge (slomo) 2016-02-18 08:00:38 UTC
This will now cause libtool to not see the .la files though.
Comment 27 Julien Isorce 2016-02-18 08:28:28 UTC
(In reply to Sebastian Dröge (slomo) from comment #26)
> This will now cause libtool to not see the .la files though.
Yes you are right since there a link, example: "gst-plugins-base/gst-libs/gst/video/.libs/libgstvideo-1.0.la -> ../libgstvideo-1.0.la".
But I tried to remove all .la in gstreamer/ and then gst-plugins-base built and run was working as expected for a gst-uninstalled env.

Also when not using libtool to build an application it won't pick up this .la and those patches allows to make that build work. So for me it is fine.

(In reply to Sebastian Dröge (slomo) from comment #18)
> Let's get this in immediately after 1.8.0 release.

Could you consider to get this in now if we are not yet at step two in "08+delta Jan 2016: 2nd pre-release + freeze for major changes" from "Release Schedule for GStreamer 1.8" mail ?
Comment 28 Sebastian Dröge (slomo) 2016-02-18 08:36:55 UTC
Oh indeed there is a link .la file in .libs. So everything's fine I guess.
Comment 29 Sebastian Dröge (slomo) 2016-02-18 08:38:16 UTC
Please also do the same change for gst-rtsp-server and gst-editing-services
Comment 30 Tim-Philipp Müller 2016-02-18 10:49:10 UTC
It might be prudent to wait at least until after 1.7.2 so any breakages this might cause don't block us from getting the next prerelease out.
Comment 31 Sebastian Dröge (slomo) 2016-02-18 10:55:30 UTC
It only matters for gst-uninstalled, so can't really block the release tomorrow :) Worst case I would revert it again but that seems unnecessary
Comment 32 Julien Isorce 2016-02-18 15:58:46 UTC
Created attachment 321594 [details] [review]
gst-rtsp-server: uninstalled.pc: add support for non libtool build systems
Comment 33 Julien Isorce 2016-02-18 15:59:14 UTC
Created attachment 321595 [details] [review]
gst-editing-services: uninstalled.pc: add support for non libtool build systems
Comment 34 Julien Isorce 2016-02-18 16:01:37 UTC
Worth to mention that even without patching gst-editing-services, so with current master I got:
  CC       libges_1.0_la-lex.priv_ges_parse_yy.lo
lex.priv_ges_parse_yy.c:1651:5: error: no previous prototype for 'priv_ges_parse_yyget_column' [-Werror=missing-prototypes]
lex.priv_ges_parse_yy.c:1727:6: error: no previous prototype for 'priv_ges_parse_yyset_column' [-Werror=missing-prototypes]

I hacked it to make it pass in order to properly check my patch.

"pkg-config gst-editing-services --cflags --libs" works as expected. Same for pkg-config gstreamer-rtsp-server --cflags --libs.
Comment 35 Julien Isorce 2016-02-18 17:50:57 UTC
Comment on attachment 321562 [details] [review]
orc: uninstalled.pc: add support for non libtool build systems

commit de23dae19fb0c8e5791c0d02b30986e3ec9c2599
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Thu Feb 18 14:18:32 2016 +0000

    uninstalled.pc: add support for non libtool build systems
    
    Currently the .la path is provided which requires to use libtool as
    mentioned in the GStreamer manual section-helloworld-compilerun.html.
    It is fine as long as the application is built using libtool.
    
    So currently it is not possible to compile a GStreamer application
    within gst-uninstalled with CMake or other build system different
    than autotools.
    
    This patch allows to do the following in gst-uninstalled env:
    gcc test.c -o test $(pkg-config --cflags --libs orc-uninstalled)
    Previously it required to prepend libtool --mode=link
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720778
Comment 36 Julien Isorce 2016-02-18 17:51:28 UTC
Comment on attachment 321563 [details] [review]
gst-core: uninstalled.pc: add support for non libtool build systems

commit 063994267ca6f0abf9bc720d73d1a3da609f75dc
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Thu Feb 18 14:20:17 2016 +0000

    uninstalled.pc: add support for non libtool build systems
    
    Currently the .la path is provided which requires to use libtool as
    mentioned in the GStreamer manual section-helloworld-compilerun.html.
    It is fine as long as the application is built using libtool.
    
    So currently it is not possible to compile a GStreamer application
    within gst-uninstalled with CMake or other build system different
    than autotools.
    
    This patch allows to do the following in gst-uninstalled env:
    gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0)
    Previously it required to prepend libtool --mode=link
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720778
Comment 37 Julien Isorce 2016-02-18 17:52:08 UTC
Comment on attachment 321564 [details] [review]
gst-plugins-base: uninstalled.pc: add support for non libtool build systems

commit c94ac3617314451833ad37430ac042e288093696
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Thu Feb 18 14:31:28 2016 +0000

    uninstalled.pc: add support for non libtool build systems
    
    Currently the .la path is provided which requires to use libtool as
    mentioned in the GStreamer manual section-helloworld-compilerun.html.
    It is fine as long as the application is built using libtool.
    
    So currently it is not possible to compile a GStreamer application
    within gst-uninstalled with CMake or other build system different
    than autotools.
    
    This patch allows to do the following in gst-uninstalled env:
    gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0 \
        gstreamer-video-1.0)
    Previously it required to prepend libtool --mode=link
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720778
Comment 38 Julien Isorce 2016-02-18 17:52:34 UTC
Comment on attachment 321565 [details] [review]
gst-plugins-bad: uninstalled.pc: add support for non libtool build systems

commit 496e7b45689edd7f0ee49ab89d62d6afd4c58391
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Thu Feb 18 14:32:23 2016 +0000

    uninstalled.pc: add support for non libtool build systems
    
    Currently the .la path is provided which requires to use libtool as
    mentioned in the GStreamer manual section-helloworld-compilerun.html.
    It is fine as long as the application is built using libtool.
    
    So currently it is not possible to compile a GStreamer application
    within gst-uninstalled with CMake or other build system different
    than autotools.
    
    This patch allows to do the following in gst-uninstalled env:
    gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0 \
        gstreamer-gl-1.0)
    Previously it required to prepend libtool --mode=link
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720778
Comment 39 Julien Isorce 2016-02-18 17:53:09 UTC
Comment on attachment 321594 [details] [review]
gst-rtsp-server: uninstalled.pc: add support for non libtool build systems

commit 8f1a9bff7f63d634055f90e29271861f5a33a136
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Thu Feb 18 15:20:05 2016 +0000

    uninstalled.pc: add support for non libtool build systems
    
    Currently the .la path is provided which requires to use libtool as
    mentioned in the GStreamer manual section-helloworld-compilerun.html.
    It is fine as long as the application is built using libtool.
    
    So currently it is not possible to compile a GStreamer application
    within gst-uninstalled with CMake or other build system different
    than autotools.
    
    This patch allows to do the following in gst-uninstalled env:
    gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0 \
      gstreamer-rtsp-server-1.0)
    Previously it required to prepend libtool --mode=link
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720778
Comment 40 Julien Isorce 2016-02-18 17:53:47 UTC
Comment on attachment 321595 [details] [review]
gst-editing-services: uninstalled.pc: add support for non libtool build systems

commit f6b0ae1e753adafe982a4102559a2da0dcbc94a9
Author: Julien Isorce <j.isorce@samsung.com>
Date:   Thu Feb 18 15:26:11 2016 +0000

    uninstalled.pc: add support for non libtool build systems
    
    Currently the .la path is provided which requires to use libtool as
    mentioned in the GStreamer manual section-helloworld-compilerun.html.
    It is fine as long as the application is built using libtool.
    
    So currently it is not possible to compile a GStreamer application
    within gst-uninstalled with CMake or other build system different
    than autotools.
    
    This patch allows to do the following in gst-uninstalled env:
    gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0 \
      gst-editing-services-1.0)
    Previously it required to prepend libtool --mode=link
    
    https://bugzilla.gnome.org/show_bug.cgi?id=720778
Comment 41 Julien Isorce 2016-02-18 17:59:14 UTC
Should I make a patch to update the manual by just removing lines from l239 to l245 ?

See https://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/manual/basics-helloworld.xml#n239