Static .lib compile of lbav

Questions that occur when trying to compile FFmpeg.
rgarcia
Posts: 1
Joined: Mon Sep 24, 2012 2:51 pm

Re: Static .lib compile of lbav

Post by rgarcia »

Zeranoe wrote:
DonMoir wrote:Your builds save me time and it would be great if you would provide the static link libs as well. As it stands, I will have to build them myself and would rather not spend time on it. You are already building a static link version of ffplay.exe etc. You have the objs and lib = collection of objs in the static link case. The static libs should parallel what you do for dll libs. I would be willing to donate for the cause.
I'm a bit confused, what are you reffering to the "libs"? The .lib files, the .dll.a files, or the .dll files?

I'm not aware of a more static way to create the .lib files, but there might be?

If I supplied the .def files, you could create your own .lib files, would that help?
Hi all,

I'm new, but I think they are talking about .a files (not .dll.a). They can be used with MSVC as input libraries in order to avoid having to distribute .dll files with your application.

I would appreciate them too.

Regards

rogerdpack
Posts: 1882
Joined: Fri Aug 05, 2011 9:56 pm

Re: Static .lib compile of lbav

Post by rogerdpack »


DonMoir
Posts: 7
Joined: Tue May 22, 2012 7:22 pm

Re: Static .lib compile of lbav

Post by DonMoir »

Referring to using --enable-static --disable-shared

The .lib files that you supply allow for usage of dll's only which can be a pain.

Some would rather just link code directly into the app instead of messing with dll's. --enable-static does build a static link .a file but then you get lots of unresolved references when trying to link .a files. .a files are compatible with msvc, just the linkage to a variety of functions is a problem.

e.g. libavcodec.a(xbmenc.o) : error LNK2001: unresolved external symbol _snprintf

and many more. Seems there should be an easy resolution.

There are some like:

libylib.a(ytime.o) : error LNK2019: unresolved external symbol ___moddi3

These are taken care of by linking in libgcc.a but other unresolved symbols are not so clear how to resolve. Has to be some combination of flags and praying.

JWellington
Posts: 6
Joined: Mon Jan 09, 2012 5:00 pm

Re: Static .lib compile of lbav

Post by JWellington »

Yea after a while I just gave up. Unless Microsoft creates a C99 compatible compiler, it will be nearly impossible to create static binaries compatible with Windows. Intel's C compilers may be of help though.

DonMoir
Posts: 7
Joined: Tue May 22, 2012 7:22 pm

Re: Static .lib compile of lbav

Post by DonMoir »

Seems like I can see some light with this.

I am linking to the following:

(these 3 come from MinGW/lib)
libgcc.a
libmingwex.a
libmsvcrt.a

(these 4 I did an --enable-static --disable-shared build on)
libavutil.a
libavformat.a
libavcodec.a
libswscale.a

I did not try with linking the other ffmpeg libraries because I don't currently need them. I also did not try with building in the various other 3rd party libraries.

All link warnings and errors are now gone and app seems to be happy.

JWellington, if you could run some more test it would be good to see what you come up with.

EDIT: Debug build of application works fine. Still having some problems with Release build. Get a lot of link warnings for release build but no link errors. Debug build doesn't seem to have any problem.
Last edited by DonMoir on Fri Nov 02, 2012 9:16 pm, edited 1 time in total.

ramiro
Posts: 157
Joined: Tue May 10, 2011 12:56 am

Re: Static .lib compile of lbav

Post by ramiro »

if you want to strip debug information you have to run "strip -x xxx.a" before linking. apparently it's now possible to compile ffmpeg with msvc (I haven't tested though).

DonMoir
Posts: 7
Joined: Tue May 22, 2012 7:22 pm

Re: Static .lib compile of lbav

Post by DonMoir »

ramiro wrote:if you want to strip debug information you have to run "strip -x xxx.a" before linking. apparently it's now possible to compile ffmpeg with msvc (I haven't tested though).
I tried strip and didn't seem to help. I think you have to do a c99 to c89 conversion and go from there. I took a look and just seemed like more endless tangle. Then I know I would always be blaming c99-to-c89 if I had a bug that was buggin me.

The release version of my app with static linkage of ffmpeg libraries RIPs in av_find_stream_info. From there I traced it to avcodec_open2 and rested waiting for second wind.

DonMoir
Posts: 7
Joined: Tue May 22, 2012 7:22 pm

Re: Static .lib compile of lbav

Post by DonMoir »

I got the release build to run with static link of ffmpeg. Had to do with some linker optimization I had in for References and Enable COMDAT Folding. Just set these to Default.

Needs more testing etc.

rogerdpack
Posts: 1882
Joined: Fri Aug 05, 2011 9:56 pm

Re: Static .lib compile of lbav

Post by rogerdpack »

DonMoir wrote:Seems like I can see some light with this.

I am linking to the following:

(these 3 come from MinGW/lib)
libgcc.a
libmingwex.a
libmsvcrt.a

(these 4 I did an --enable-static --disable-shared build on)
libavutil.a
libavformat.a
libavcodec.a
libswscale.a

I did not try with linking the other ffmpeg libraries because I don't currently need them. I also did not try with building in the various other 3rd party libraries.

All link warnings and errors are now gone and app seems to be happy.

JWellington, if you could run some more test it would be good to see what you come up with.

EDIT: Debug build of application works fine. Still having some problems with Release build. Get a lot of link warnings for release build but no link errors. Debug build doesn't seem to have any problem.
Did this make it much bigger?
Possibly could you write up what you did in a new wiki page under http://ffmpeg.org/trac/ffmpeg/wiki so it could become a reference for others too?
Thanks.

DonMoir
Posts: 7
Joined: Tue May 22, 2012 7:22 pm

Re: Static .lib compile of lbav

Post by DonMoir »

rogerdpack wrote:Did this make it much bigger?
Possibly could you write up what you did in a new wiki page under http://ffmpeg.org/trac/ffmpeg/wiki so it could become a reference for others too?
Thanks.
The size would be approximately the size of your app plus the size of each ffmpeg dll you are currently using.

You can then take resulting exe (or if app is dll) and then do a UPX on it. UPX will cut the size in half or more. UPX is a compress / decompress tool for executables. It's very fast and you will never know the difference performance wise.

http://upx.sourceforge.net/

The goal would be to see if zeranoe is interested in providing the statically linkable lib or .a files. I think the wiki already points to zeranoe for windows pre-built dll's. First thing though is to figure out all the details and make sure it makes sense to do a public distribution. I am in the process of checking it further so will know more later. I need to see how the 3rd party libs come into play. I see some differences when compiling under linux vs msys in windows with the result libraries so need to check on that.

Post Reply