[FFmpeg-devel] Fix libssh static linkage on Windows

[Matt Oliver]

On 6 February 2014 05:53, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Thu, Feb 06, 2014 at 01:21:34AM +1100, Matt Oliver wrote:
> > On windows there are 2 ways to link to a function found in an external
> > shared library (.dll on windows). The first is to generate an export
> > library with your shared dll. This export library looks just like a
> static
> > lib but all the functions found in it point out to the external dll. The
> > second method is to declare each function as dllimport. This bypasses
> > needing to link to the export lib by explicitly stating its from a dll in
> > the code.
> >
> > dllimport is placed in front of any function or data declarations in code
> > to specify that they are found in an external .dll (.so shared library on
> > linux). If a function is declared as dllimport then the linker will only
> > look for that function in an external dll even if that function has been
> > provided with a static library. So linking will always fail if using a
> > static library to provide a function as the linker will only allow for an
> > external shared function.
>
> Are you sure about that? Because that is not my experience.
> As long as you use dllexport for the corresponding functions while
> compiling the static lib I believe it should work just fine.
> Note that you like this risk that libavformat ends up exporting
> the libssh functions, so it's not exactly such a great idea,
> but the underlying issue should be using dllimport where you use
> the function but not using dllexport where you defined it.
> Also, to quote Microsoft:
> > dllexport of a function exposes the function with its decorated name.
> For C++ functions, this includes name mangling. For C functions or
> functions that are declared as extern "C", this includes platform-specific
> decoration that's based on the calling convention. If you don't want name
> decoration, use a .def file (EXPORTS keyword).
>
> So it's basically a name mangling issue (for C I believe it's just
> that a _ is prepended).
> It also hints that just using a .def file and none of this
> dllimport/dllexport
> stuff would avoid the issue as well.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I probably shouldn't send emails at 2am after a late night as my last one
was a bit off. Your right in that dllimport is just a name mangling thing
that works providing you compiled the original static lib with dllexport.
Having dllimport means that it will only link with static libs compiled
using LIBSSH_EXPORTS (dllexport) as opposed to the more obvious
LIBSSH_STATIC. However building a static with that define requires the
linking program to also use that define. That is the reason for the patch
as with the define you can link against a static lib without exports while
also being able to link against a shared lib that does use exports.

Given that the shared lib project provided by the libssh project defines
LIBSSH_STATIC then any static lib using the default libssh builds wont be
compatible with ffmpeg due to the conflicting use of dllexport. But by
adding the patch then not only will standard libssh static builds work but
the default shared builds will still work as well.