Request: Shared + 'true' Static

[God-damnit-all]

@1480c1 I would like the suite to have an option similar to one that already exists - shared + static. The difference is, I do not want the static versions to include anything that would make them dependent on an external file. Self-contained exe files. This would of course mean they would lack features from any library that can't be embedded in the exe, but that's what the shared set would be for.

Currently this is difficult, because you'll have to compile with everything enabled at least once to figure out which libraries can't be embedded in static exe files, then you'll either have to keep changing your options around between compilations or just have two sets of media-autobuild_suite.

I feel like this approach would give a user the best of both worlds. I would personally use shared for home use, and static for a remote server or a thumbdrive - and any situation where it would be more convenient to have just a single file that doesn't need anything else to run.

[wiiaboo]

Hey, here's a better idea. Grab the binaries you want "true" static, and try removing options until it's "true" static like you want, and then you can maybe tell us what you found.

On Fri, 9 Aug 2019 at 09:56, ImportTaste notifications@github.com wrote:

@1480c1 https://github.com/1480c1 I would like the suite to have an option similar to one that already exists - shared + static. The difference is, I do not want the static versions to include anything that would make them dependent on an external file. Self-contained exe files. This would of course mean they would lack features from any library that can't be embedded in the exe, but that's what the shared set would be for.

Currently this is difficult, because you'll have to compile with everything enabled at least once to figure out which libraries can't be embedded in static exe files, then you'll either have to keep changing your options around between compilations or just have two sets of media-autobuild_suite.

I feel like this approach would give a user the best of both worlds. I would personally use shared for home use, and static for a remote server or a thumbdrive - and any situation where it would be more convenient to have just a single file that doesn't need anything else to run.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jb-alvarado/media-autobuild_suite/issues/1336?email_source=notifications&email_token=AAA3H5KLZA2SHS25TDOE2MDQDUWMPA5CNFSM4IKR7TN2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HELCMCQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA3H5PD5CWBDF6QM6PWEILQDUWMPANCNFSM4IKR7TNQ .

[wiiaboo]

There's dozens of binaries being built by the suite, with dozens of variable external dependencies. I hope you don't seriously expect us to do this investigation ourselves.

On Fri, 9 Aug 2019 at 11:06, Ricardo Constantino wiiaboo@gmail.com wrote:

Hey, here's a better idea. Grab the binaries you want "true" static, and try removing options until it's "true" static like you want, and then you can maybe tell us what you found.

On Fri, 9 Aug 2019 at 09:56, ImportTaste notifications@github.com wrote:

@1480c1 https://github.com/1480c1 I would like the suite to have an option similar to one that already exists - shared + static. The difference is, I do not want the static versions to include anything that would make them dependent on an external file. Self-contained exe files. This would of course mean they would lack features from any library that can't be embedded in the exe, but that's what the shared set would be for.

Currently this is difficult, because you'll have to compile with everything enabled at least once to figure out which libraries can't be embedded in static exe files, then you'll either have to keep changing your options around between compilations or just have two sets of media-autobuild_suite.

I feel like this approach would give a user the best of both worlds. I would personally use shared for home use, and static for a remote server or a thumbdrive - and any situation where it would be more convenient to have just a single file that doesn't need anything else to run.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jb-alvarado/media-autobuild_suite/issues/1336?email_source=notifications&email_token=AAA3H5KLZA2SHS25TDOE2MDQDUWMPA5CNFSM4IKR7TN2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HELCMCQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA3H5PD5CWBDF6QM6PWEILQDUWMPANCNFSM4IKR7TNQ .

[1480c1]

If I have enough time, maybe.

[1480c1]

One thing you can do to help contribute to this would be to make a list of which projects cannot be compiled static by the suite. If you choose static but the suite still has a dll, that most likely means that it wasn't produced statically by the suite (SVT-HEVC is one such project ATM)

[wiiaboo]

Hard shared dependencies for FFmpeg/mpv:

• openh264 if enabled, due to their license
• vapoursynth, due to not being compilable in mingw statically
• opencl and opengl, since they use system libs
• svt-hevc, if enabled

Soft shared dependencies for FFmpeg/mpv

• libaacs and libbdplus, by libbluray, if available

Hard shared dependencies for mpv:

• libEGL and libGLESv2 (angle) if enabled and gpu-api=angle is used

Other than that, there's tons of system dependencies that are impossible to drop. Basically, you can compile your "true" static FFmpeg/mpv right now, without a single modification from us.

[God-damnit-all]

@1480c1 @wiiaboo I'm getting mixed messages here.

Yes, I'm aware you can compile the 'true' static right now. What I'm asking for (making the assumption that everything is enabled) is for the script to build ffmpeg & friends as shared builds with all the components, and then, do static builds without openh264, vapoursynth, opencl, opengl, svt-hevc, libbluray, libEGL, and libGLESv2.

Yes, you can do this right now, but you have to maintain two configurations, and it is a pain to swap between them. The script currently already allows a shared + static build in the same run, I just want a version of it that excludes those libraries from the static portion.

Right now I maintain two copies of the media-autobuild_suite configuration to accomplish this, which is a pain - hence this request.

Hey, here's a better idea. Grab the binaries you want "true" static, and try removing options until it's "true" static like you want, and then you can maybe tell us what you found.

I was presenting this from the perspective of a typical user. It's a lot of hoops for people who are new to compiling these tools to jump through.

[1480c1]

What @wiiaboo is saying is that you can make a copy for your ffmpeg_options.txt and mpv_options.txt with one having all of the libs you want, and another with only static libs and switch between the files to get static only and static and shared

What I'm saying is that if I have the time, I might look into making such an option. No promises nor guarantees that it will be done in the foreseeable future

[1480c1]

My alternative would include you to compile the suite with everything we provide for use in mpv and ffmpeg with static selected and note down which libraries still only provide .dll instead of .a

If someone (you) could compile that list, it would help speed up the search as I also have multiple instances of the suite on my desktop/vm/laptop to the point that I'm not sure which suite originally had which configuration. Doing the search would help me not use a couple of hours waiting for everything to compile

[God-damnit-all]

What @wiiaboo is saying is that you can make a copy for your ffmpeg_options.txt and mpv_options.txt with one having all of the libs you want, and another with only static libs and switch between the files to get static only and static and shared

This is what I'm already doing, It's just a pain in the butt. I was trying to present the request as a way of describing the hoops I jumped through to accomplish this, and it seems @wiiaboo interpreted it as a demand that you do testing to determine the dependencies yourself.

What I'm saying is that if I have the time, I might look into making such an option. No promises nor guarantees that it will be done in the foreseeable future

Thank you. @wiiaboo seemed to be dismissive, so I wasn't sure what to think.

If someone (you) could compile that list, it would help speed up the search as I also have multiple instances of the suite on my desktop/vm/laptop to the point that I'm not sure which suite originally had which configuration. Doing the search would help me not use a couple of hours waiting for everything to compile

@wiiaboo's response right before the 'wiiaboo closed this' message actually has everything already.

[1480c1]

I know, I'm just clarifying my original message

[God-damnit-all]

Appreciated.

[wiiaboo]

I just don't want another snowflake option just to remove four libs. I'd rather they have to maintain two ffmpeg_options.txt (and ffmpeg_options_shared.txt or something) than add another option that no one uses (like ffmpeg's 5th).

[God-damnit-all]

Ah, so adapting the existing shared+static option to read from two different ffmpeg/mpv options files? If the default files were altered slightly with comments about which libraries force external dependencies, that would certainly do the job.

Perhaps all static builds, regardless of which option you choose, could prioritize reading from ffmpeg_options_static.txt but falls back to ffmpeg_options.txt if it doesn't exist. (And shared from ffmpeg_options_shared.txt, and mpv... you get the idea.)

[wiiaboo]

Basically, if the suite warns you about binaries depending on something, it means they're shared. There's already warnings since forever for those.

[God-damnit-all]

Basically, if the suite warns you about binaries depending on something, it means they're shared. There's already warnings since forever for those.

I'm aware. Providing good comments and documentation is to everyone's benefit, however.

[God-damnit-all]

I feel that combing through logs or watching the extremely long compilation process to learn that the static build will be tied to these external dependencies is just not as good as learning about it just from customizing your options file - a lot of the projects included in linux repos have extremely detailed options templates for good reason.

[1480c1]

I can work on it when I wake up (if I don't have anything else I need to do)

[wiiaboo]

c664a5f0c30cb3f5fa416d446412b4048434698c there, that should be enough.

a lot of the projects included in linux repos have extremely detailed options templates for good reason.

Usually because they have non-lazy users, or people dedicated to documentation, or very dedicated devs.

[God-damnit-all]

I saw today's commits and you over-delivered - very good stuff. I appreciate this a lot. Thank you.