[FFmpeg-devel] Fix libssh static linkage on Windows

[Timothy Gu]

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 for
> 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 creates
> the external visibility or entry points for those functions. DEF files are
> often troublesome because you have to manually add each new function to
the
> list and remove old ones which is why dllexport came in as this
declaration
> when added to a function will just automatically add that function to your
> exports list without you having to do it yourself. Functionally though
they
> 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 accompanying
> .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
the
> shared DLL and everything works fine. This is because the LIB has the
> standard C function name entry points where each of these simply redirects
> 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 avoiding
> the redirect and potentially improving performance. That said an
optimizing
> compiler is often smart enough to optimize out the indirection anyway and
> 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 including
> 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
lib
> 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
(and
> hopefully the redirect is optimized out). This way both static and shared
> 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.
This
> 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.

Timothy