[FFmpeg-devel] Fix libssh static linkage on Windows

Timothy Gu timothygu99 at gmail.com
Mon Feb 10 17:38:38 CET 2014

On Feb 10, 2014 8:35 AM, "Timothy Gu" <timothygu99 at gmail.com> wrote:
> On Feb 10, 2014 7:45 AM, "Matt Oliver" <protogonoi at gmail.com> wrote:
> >
> > OK because the last email wasnt all that clear and in case people ask
> > supporting evidence ill clarify a bit more (and everyone responded to my
> > email before I could clarify).
> >
> > DLLs on windows traditionally use module definition files (.DEF) to list
> > each function that you want exported from your dll. This basically
> > the external visibility or entry points for those functions. DEF files
> > often troublesome because you have to manually add each new function to
> > list and remove old ones which is why dllexport came in as this
> > when added to a function will just automatically add that function to
> > exports list without you having to do it yourself. Functionally though
> > are both the same.
> >
> > Functions in DLLs have a entry point generally prefixed with __imp__ and
> > when a function is exported then it will also be added to the
> > .LIB file. The .LIB file contain the exported function with a standard c
> > naming scheme. So you can link against the exported LIB that comes with
> > shared DLL and everything works fine. This is because the LIB has the
> > standard C function name entry points where each of these simply
> > to the __imp__ versions.
> >
> > Declaring a function as dllimport explicitly adds the __imp__ prefix
and so
> > bypasses the standard indirection. This can have the advantage of
> > the redirect and potentially improving performance. That said an
> > compiler is often smart enough to optimize out the indirection anyway
> > as ive been told ffmpeg uses alot of DCE as it stands (this time im
> > actually supporting it).
> >
> > So to clarify by default unless LIBSSH_STATIC is declared before
> > the libssh headers then the libssh headers will automatically default to
> > using dllimport on windows. This causes a problem as now the linker is
> > looking for the __imp__ versions which obviously dont exist in a static
> > and so fails. By using LIBSSH_STATIC then the dllimport is removed and
> > linking is performed through the .LIB file which redirects to the .DLL
> > hopefully the redirect is optimized out). This way both static and
> > dlls can be supported from the same code.
> >
> > All other ffmpeg dependencies that provide native windows builds use
> > exports but dont auto define dllimport and just use the LIB indirection.
> > Only libssh defaults to dllimport which is why this issue hasnt been a
> > problem previously hence needing the LIBSSH_STATIC this time.
> >
> > But to make things clear i will quote Microsoft: "You do not need to use
> > *__declspec(dllimport)* for your code to compile correctly"
> > As found here:
> > http://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx
> >
> > So defining LIBSSH_STATIC prevents the libssh headers defaulting to
> > dllimport and preventing linking with static libs. Wile still supporting
> > linking against dlls using the standard approach of a LIB indirection.
> > is how all other ffmpeg dependencies are done and as microsoft states it
> > will work fine.
> OK, am I correct that .def file is the same as linker script (e.g.
libavcodec.v) in the Linux world? And dllexport eliminates the need to add
an extra file?

> Also you haven't explained what is dllimport.

Sorry, never mind. I see it now.

The patch LGTM, although a comment might be helpful.


More information about the ffmpeg-devel mailing list