[Ffmpeg-devel-irc] ffmpeg-devel.log.20171014

[burek]

[01:29:02 CEST] <cone-568> ffmpeg 03James Almer 07master:854c4e974db9: configure: add a -lstdc++ flag to the some external library checks
[01:29:02 CEST] <cone-568> ffmpeg 03James Almer 07master:fa5e71a815ef: configure: add missing pthreads extralib to the libilbc check
[01:29:02 CEST] <cone-568> ffmpeg 03Reino Wijnsma 07master:458783315b8f: configure: switch the libzvbi check to pkg-config
[01:59:31 CEST] <cone-568> ffmpeg 03James Almer 07master:ad56e8057d8a: configure: force erroring out in check_disable_warning() if an option doesn't exists
[01:59:40 CEST] <cone-568> ffmpeg 03James Almer 07release/3.4:7deb7e6acd4f: configure: force erroring out in check_disable_warning() if an option doesn't exists
[04:28:59 CEST] <jamrial> right, so the librubberband issue tracker has a report about the missing -lstcd++ on static builds
[04:29:09 CEST] <jamrial> reported in March 2015, and ignored since then
[04:29:42 CEST] <jamrial> so we can forget it being fixed anytime soon
[04:31:48 CEST] <jamrial> my email sent to the libbluray ml is in moderation limbo
[04:32:52 CEST] <jamrial> so that leaves libopenmpt as the last library with a broken pkg-config file, if you don't count the dead libxavs
[04:33:00 CEST] <jamrial> at least for now
[09:50:05 CEST] <beauty> hello
[09:50:21 CEST] <beauty> how to stress hls nginx server?
[13:38:18 CEST] <ffmpeg> Good moring,how to simulate thousands of clients request?
[14:16:01 CEST] <ffmpeg>  Good moring,how to simulate thousands of clients request?
[14:17:07 CEST] <BtbN> Just because you don't like the answer doesn't mean you should just keep asking the same question over and over. Also, stop cross-posting a non-devel question.
[15:01:47 CEST] <ffmpeg> BtbN: thanks
[16:04:31 CEST] <jamrial> any comment about what Jörn Heusipp mentioned regarding libstdc++ with static linking?
[16:05:35 CEST] <JEEB> multiple C++ stdlibs being around (Even on linux only) make it a PITA
[16:05:53 CEST] <JEEB> like, you could be using the thing that you have in llvm/clang, or the usual GNU GCC one
[16:05:58 CEST] <JEEB> even mismatching them
[16:06:02 CEST] <jamrial> i'm really pissed about configure having worked all this time by pure chance and pixie dust
[16:06:25 CEST] <JEEB> preferably it would be the deal of the projects that are done in C++ to handle and know what they were going to be linked against
[16:06:37 CEST] <JEEB> because they're the only ones that know it
[16:06:50 CEST] <JEEB> of course, how you notice that is...
[16:07:27 CEST] <jamrial> maybe we could probe for a c++ library somehow? and use that in checks instead of hardcoding -lstdc++
[16:07:43 CEST] <JEEB> yea, but is it really our job?
[16:07:52 CEST] <JEEB> I mean, sure. upstreams don't want to fix their jack
[16:08:00 CEST] <JEEB> but we're not a C++ project
[16:08:25 CEST] <JEEB> if I recall correctly zimg just expects you to use lstdc++ unless you set a flag
[16:08:55 CEST] <JEEB> https://github.com/sekrit-twc/zimg/blob/master/configure.ac#L55
[16:09:05 CEST] <JEEB> and then that gets put into the pc file
[16:12:06 CEST] <jamrial> fucking static linking
[16:12:30 CEST] <JEEB> ayup
[16:12:51 CEST] <jamrial> worst part is that some library checks probably only worked if you also checked for another library before it
[16:13:20 CEST] <JEEB> I consider this to be a problem, but I'm not sure if pkg-config can fix it so it will have to be fixed in the upstreams, making the required checks and noting the c++ stdlib that is used to build that specific module
[16:13:37 CEST] <JEEB> and most certainly I'm not sure if *we* should be working around it
[16:14:15 CEST] <JEEB> we most certainly can double our C++ checks to first try without a stdlib, and if it fails then try with the stdlib included. but does that send the right signal to the C++ projects?
[16:14:45 CEST] <jamrial> no
[16:14:50 CEST] <jamrial> do i revert 854c4e974d then?
[16:15:22 CEST] <JEEB> as we can see from zimg, the author clearly has put the minimum amount of effort there :P so we have a precedent of a C++ upstream doing something about it
[16:15:25 CEST] <JEEB> lemme se
[16:15:45 CEST] <nevcairiel> clearly pkg-config is not meant for c++ projects, if it apparently cant solve it
[16:16:12 CEST] <JEEB> nevcairiel: how would pkg-config know which stdlib with the project was originally built/linked against?
[16:16:20 CEST] <JEEB> the project has to tell it and put the flag there
[16:16:33 CEST] <JEEB> the one who generates the pkg-config file is responsible
[16:17:17 CEST] <JEEB> jamrial: yea . while that might fix some things there's no way of f.ex. overriding it. so either improvement is required, or we revert it and tell people to fix their jacks
[16:18:06 CEST] <JEEB> also so many projects missing the pthread lib
[16:18:08 CEST] <nevcairiel> static linking and c++ requires very careful control anyway
[16:18:08 CEST] <jamrial> oh wow, x265 pkg-config file doesn't list -lpthread for static builds
[16:18:11 CEST] <jamrial> fuck this shit
[16:18:22 CEST] <JEEB> yes, I just told someone on #ffmpeg to report it and fix it manually in his pc file
[16:18:41 CEST] <jamrial> how many projects so far we found didn't add the math and pthreads library?
[16:18:59 CEST] <nevcairiel> i think its rather braindead of whoever designed libm to be standalone anyway
[16:19:08 CEST] <nevcairiel> shove it into the crt and solve so many issues
[16:19:26 CEST] <jamrial> sure, but since it's not, just fucking add it to the .pc file if needed
[16:19:45 CEST] <nevcairiel> maybe we should just link libm globally everywhere, all of our libraries link against it anyway, and solve some headaches =p
[16:19:53 CEST] <jamrial> opening a ticket in x265...
[16:20:04 CEST] <JEEB> cheers, since that project at least is alive unlike some others
[16:20:07 CEST] <jamrial> nevcairiel: probably a good idea
[16:22:25 CEST] <kurosu> and now waiting for the case where ffmpeg has to link against 2 libs that use different c++/stl libs
[16:22:48 CEST] <nevcairiel> that has never been possible and will never be, at least not with static linking
[16:24:39 CEST] <JEEB> yes, that case is just something you don't support
[16:24:47 CEST] <JEEB> they can have their broken garbage if someone attempts
[16:39:25 CEST] <jamrial> https://pastebin.com/9CvcmdXC so x265 purposely removes pthreads from libs.private
[16:40:18 CEST] <ubitux> probably because it depends on the compiler?
[16:40:40 CEST] <nevcairiel> static linking and big differences in compilers dont really mix anyway
[16:41:01 CEST] <JEEB> yea, the only way to know is to know if you used pthreads when creating the library
[16:41:18 CEST] <jamrial> ok so, we add libm_extralibs to global extralibs, and probably also pthreads_extralibs then?
[16:41:30 CEST] <ubitux> it might be wise
[16:41:41 CEST] <jamrial> otherwise we'll be adding them to each external library check as users report breakages
[16:41:41 CEST] <ubitux> why libm btw?
[16:41:46 CEST] <JEEB> such a clusterduck
[16:41:50 CEST] <JEEB> ubitux: some miss that
[16:42:02 CEST] <ubitux> define <some>?
[16:42:02 CEST] <jamrial> ubitux: libm_extralibs evaluates to -lm or nothing, depending on system
[16:42:13 CEST] <ubitux> alright, so just like pthread then
[16:42:42 CEST] <JEEB> jamrial I think went through it
[16:42:49 CEST] <JEEB> wrt what were missing math lib
[16:42:51 CEST] <nevcairiel> pthreads might be annoying, not every of our libs links to it
[16:43:16 CEST] <jamrial> true
[16:43:39 CEST] <jamrial> i'll start with libm for now
[17:27:05 CEST] <Zeranoe> I'm now providing macOS 64-bit builds targeting 10.10 and newer. Could I be added under the OS X download section?
[17:29:10 CEST] <Zeranoe> Let me know if this request belongs on the ML.
[17:32:11 CEST] <atomnuker> yeah, send a patch as usual
[17:33:53 CEST] <Zeranoe> Will do
[18:24:04 CEST] <jamrial> nevcairiel: avutil links to pthreads, so virutally everything else will
[18:30:29 CEST] <jamrial> anyway, patches in the ml
[20:36:38 CEST] <nevcairiel> what would one consider a "normal" bicubic scaler? b-spline?
[00:00:00 CEST] --- Sun Oct 15 2017