GNOME Bugzilla – Bug 720778
gst-uninstalled requires building with libtool
Last modified: 2016-02-18 18:06:10 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?
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.
(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
(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... :(
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.
Created attachment 295002 [details] Remove libtool from uninstalled environment
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.
+1, our usecase is chromium and it does not use libtool.
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...
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.
> 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 :)
(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.
(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 ?
Created attachment 320484 [details] [review] uninstalled.pc: add support for non libtool build systems
Created attachment 320485 [details] [review] gst-core: uninstalled.pc: add support for non libtool build systems
Created attachment 320486 [details] [review] gst-plugins-bqse: uninstalled.pc: add support for non libtool build systems
Created attachment 320487 [details] [review] gst-plugins-bqd: uninstalled.pc: add support for non libtool build systems
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.
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? :)
(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.
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.
(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.
Created attachment 321562 [details] [review] orc: uninstalled.pc: add support for non libtool build systems
Created attachment 321563 [details] [review] gst-core: uninstalled.pc: add support for non libtool build systems
Created attachment 321564 [details] [review] gst-plugins-base: uninstalled.pc: add support for non libtool build systems
Created attachment 321565 [details] [review] gst-plugins-bad: uninstalled.pc: add support for non libtool build systems
This will now cause libtool to not see the .la files though.
(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 ?
Oh indeed there is a link .la file in .libs. So everything's fine I guess.
Please also do the same change for gst-rtsp-server and gst-editing-services
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.
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
Created attachment 321594 [details] [review] gst-rtsp-server: uninstalled.pc: add support for non libtool build systems
Created attachment 321595 [details] [review] gst-editing-services: uninstalled.pc: add support for non libtool build systems
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 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 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 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 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 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 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
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