Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libgit2 StdCall (/Gz) calling convention #693

Closed
tritao opened this issue Apr 25, 2014 · 6 comments
Closed

libgit2 StdCall (/Gz) calling convention #693

tritao opened this issue Apr 25, 2014 · 6 comments

Comments

@tritao
Copy link

tritao commented Apr 25, 2014

I've been trying to get an SSL/SSH2 enabled build of libgit2 going on, but unfortunately OpenSSL is pretty hard to compile with /Gz. It'd be best if LibGit2Sharp could consume a usual (cdecl) build of libgit2.

Is there some specific reason that LibGit2Sharp needs libgit2 to be compiled as stdcall?

@carlosmn
Copy link
Member

We need to build with /Gz in order to have callbacks work.

@nulltoken
Copy link
Member

In order to discuss this further, below some related references on those topics

stdcall/cdecl:

ssh:

Is there some specific reason that LibGit2Sharp needs libgit2 to be compiled as stdcall?

#205 was a proposal showing how to implement cdecl calling convention with working callbacks.

I'm fully ok to re-open the calling convention subject provided we all reach an agreement 😉.

/cc @phkelley @ethomson @jamill @paulcbetts

@nulltoken
Copy link
Member

/cc @igor-gorbunov

@tritao
Copy link
Author

tritao commented Apr 25, 2014

Thanks for the references.

I've posted some thoughts on how I think this could be solved to #888. That way we would not need any changes to LibGit2Sharp.

But regarding cdecl callbacks under .NET, can't it be done with UnmanagedFunctionPointer?

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate ...

@nulltoken
Copy link
Member

But regarding cdecl callbacks under .NET, can't it be done with UnmanagedFunctionPointer?

@tritao #205 was showcasing this.

@carlosmn
Copy link
Member

carlosmn commented Mar 7, 2016

We're keeping stdcall. There is no need for OpenSSL for libssh2 to work, so they no longer set the calling convention. If libssh2 does not support stdcall when using Windows crypto that's a bug to be filed with them.

@carlosmn carlosmn closed this as completed Mar 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants