130418 2014-03-18 13:32:33 -0700 [GStreamer] FindGStreamer.cmake should also look for libraries in ${PC_${_component_prefix}_LIBDIR}/.libs 2014-05-21 13:47:33 -0700 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 b.long b.long bunhere commit-queue gyuyoung.kim pnormand rakuco sergio oldest_to_newest 991842 0 b.long 2014-03-18 13:32:33 -0700 [GStreamer] FindGStreamer.cmake should also look for libraries in ${PC_${_component_prefix}_LIBDIR}/.libs 991845 1 227098 b.long 2014-03-18 13:36:14 -0700 Created attachment 227098 Patch 991875 2 227098 rakuco 2014-03-18 14:28:51 -0700 Comment on attachment 227098 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=227098&action=review > ChangeLog:8 > + When building GStreamer from git, it uses libtool, which creates libgstwhatever.la, > + but the real library goes in .libs/libgstwhatever.so. Another approach > + would be to compile with libtool, but that's much more involved. This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me. 991893 3 b.long 2014-03-18 14:50:31 -0700 (In reply to comment #2) > This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me. Because this is how GStreamer is meant to be used: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#idp55212752 I doubt many people will need to use this, but it's a trivial change that makes working with git checkouts of GStreamer significantly easier. 991912 4 rakuco 2014-03-18 15:26:08 -0700 (In reply to comment #3) > (In reply to comment #2) > > This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me. > > Because this is how GStreamer is meant to be used: > > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#idp55212752 I fail to see anything GStreamer-specific in this link, the content there applies to any libtool project -- it's all about changing environment variables. > I doubt many people will need to use this, but it's a trivial change that makes working with git checkouts of GStreamer significantly easier. My concern with this approach is that it's basically an undocumented hack for a very specific use case. If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally? 991918 5 b.long 2014-03-18 15:36:41 -0700 (In reply to comment #4) > If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally? The whole point of gst-git is that it sets up PKG_CONFIG_PATH automatically. Hard-coding every library directory is a much bigger hack than just looking in the libtool .libs directory. And there are hundreds of them, which change every time a new plugin is added to GStreamer.. 991925 6 b.long 2014-03-18 15:45:47 -0700 I also find it frustrating that it worked until we switched to CMake.. 991926 7 b.long 2014-03-18 15:46:45 -0700 (In reply to comment #4) > My concern with this approach is that it's basically an undocumented hack for a very specific use case. I could also document this with a comment that we're looking in .libs because GStreamer's git checkouts automatically use libtool, which puts libraries in .libs. 991928 8 b.long 2014-03-18 15:50:22 -0700 philn, do you use a git checkout of GStreamer? If so, how do you handle building against it in WebKit? 991932 9 rakuco 2014-03-18 16:02:34 -0700 (In reply to comment #5) > (In reply to comment #4) > > If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally? > > The whole point of gst-git is that it sets up PKG_CONFIG_PATH automatically. Hard-coding every library directory is a much bigger hack than just looking in the libtool .libs directory. And there are hundreds of them, which change every time a new plugin is added to GStreamer.. Doesn't `gst-git && export CMAKE_LIBRARY_PATH=${LD_LIBRARY_PATH}' work? Additionally, if you just build GStreamer with ./autogen.sh won't the .pc files have "prefix=/usr/local" and thus the current patch will tell CMake to look at /usr/local/lib/.libs? 992045 10 pnormand 2014-03-19 00:34:32 -0700 (In reply to comment #8) > philn, do you use a git checkout of GStreamer? If so, how do you handle building against it in WebKit? I usually rely on the version we have in jhbuild, which I make point to trunk whenever needed. 1010828 11 b.long 2014-05-21 13:47:22 -0700 Sorry, I didn't get emailed about the responses on here for some reason. I'll look into just using the jhbuild to do what I need (and hopefully GStreamer will fix this eventually). 227098 2014-03-18 13:36:14 -0700 2014-05-21 13:47:33 -0700 Patch bug-130418-20140318153551.patch text/plain 1552 b.long U3VidmVyc2lvbiBSZXZpc2lvbjogMTY1ODE0CmRpZmYgLS1naXQgYS9Tb3VyY2UvY21ha2UvRmlu ZEdTdHJlYW1lci5jbWFrZSBiL1NvdXJjZS9jbWFrZS9GaW5kR1N0cmVhbWVyLmNtYWtlCmluZGV4 IDVmM2Y2NWJiNmU3MWMzMjkxYzUwYjA0ZDk2NWIyM2QyYzQzZjBmMDQuLmQ2ZjZlNDNmZWJhYmYw MGUyYmIwZWVmZjVmZDZiMDM1ZjZhZTBiODIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9jbWFrZS9GaW5k R1N0cmVhbWVyLmNtYWtlCisrKyBiL1NvdXJjZS9jbWFrZS9GaW5kR1N0cmVhbWVyLmNtYWtlCkBA IC02NCw3ICs2NCw3IEBAIG1hY3JvKEZJTkRfR1NUUkVBTUVSX0NPTVBPTkVOVCBfY29tcG9uZW50 X3ByZWZpeCBfcGtnY29uZmlnX25hbWUgX2hlYWRlciBfbGlicmFyCiAKICAgICBmaW5kX2xpYnJh cnkoJHtfY29tcG9uZW50X3ByZWZpeH1fTElCUkFSSUVTCiAgICAgICAgIE5BTUVTICR7X2xpYnJh cnl9Ci0gICAgICAgIEhJTlRTICR7UENfJHtfY29tcG9uZW50X3ByZWZpeH1fTElCUkFSWV9ESVJT fSAke1BDXyR7X2NvbXBvbmVudF9wcmVmaXh9X0xJQkRJUn0KKyAgICAgICAgSElOVFMgJHtQQ18k e19jb21wb25lbnRfcHJlZml4fV9MSUJSQVJZX0RJUlN9ICR7UENfJHtfY29tcG9uZW50X3ByZWZp eH1fTElCRElSfS8ubGlicyAke1BDXyR7X2NvbXBvbmVudF9wcmVmaXh9X0xJQkRJUn0KICAgICAp CiBlbmRtYWNybygpCiAKZGlmZiAtLWdpdCBhL0NoYW5nZUxvZyBiL0NoYW5nZUxvZwppbmRleCBk NDY3NGJmOGUyYTg0NmU5NmIxODYzMzUwZDM4ZDA3YzQyYTQzMDQzLi4zMWY4Nzg2YjMzY2I3NGQz MGI3ZTE2NjkyYjgxYTI3YjAzMTg1MzkxIDEwMDY0NAotLS0gYS9DaGFuZ2VMb2cKKysrIGIvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTQtMDMtMTggIEJyZW5kYW4gTG9uZyAgPGIubG9u Z0BjYWJsZWxhYnMuY29tPgorCisgICAgICAgIFtHU3RyZWFtZXJdIEZpbmRHU3RyZWFtZXIuY21h a2Ugc2hvdWxkIGFsc28gbG9vayBmb3IgbGlicmFyaWVzIGluICR7UENfJHtfY29tcG9uZW50X3By ZWZpeH1fTElCRElSfS8ubGlicworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93 X2J1Zy5jZ2k/aWQ9MTMwNDE4CisKKyAgICAgICAgV2hlbiBidWlsZGluZyBHU3RyZWFtZXIgZnJv bSBnaXQsIGl0IHVzZXMgbGlidG9vbCwgd2hpY2ggY3JlYXRlcyBsaWJnc3R3aGF0ZXZlci5sYSwK KyAgICAgICAgYnV0IHRoZSByZWFsIGxpYnJhcnkgZ29lcyBpbiAubGlicy9saWJnc3R3aGF0ZXZl ci5zby4gQW5vdGhlciBhcHByb2FjaAorICAgICAgICB3b3VsZCBiZSB0byBjb21waWxlIHdpdGgg bGlidG9vbCwgYnV0IHRoYXQncyBtdWNoIG1vcmUgaW52b2x2ZWQuCisKKyAgICAgICAgUmV2aWV3 ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBTb3VyY2UvY21ha2UvRmluZEdTdHJl YW1lci5jbWFrZToKKwogMjAxNC0wMy0xNyAgQnJlbmRhbiBMb25nICA8Yi5sb25nQGNhYmxlbGFi cy5jb20+CiAKICAgICAgICAgW0dTdHJlYW1lcl0gaHVtYW4gcmVhZGFibGUgbGFuZ3VhZ2UgY29k ZSBmb3IgdHJhY2tzCg==