gnutls icon indicating copy to clipboard operation
gnutls copied to clipboard

vcpkg Support

Open webfolderio opened this issue 6 years ago • 9 comments

Hi,

Do you consider to add vcpkg support?

Thanks

webfolderio avatar Mar 19 '19 10:03 webfolderio

@Sibras

I am working on bringing GnuTLS to vcpkg: https://github.com/microsoft/vcpkg/pull/14242

Most (if not all) of the issues I am facing over there were solved by this fork. I could pull in the necessary patches, but am wondering what is the reason you maintain this fork instead of asking for those patches to be included upstream? This would make everyone's life easier.

wrobelda avatar Mar 01 '21 01:03 wrobelda

@wrobelda There is a SMP.patch that has all the relevant source code changes in it to help aid others. However there would have to be work done to the gnutls build system in order to get it all working within that before gnutls would likely accept it.

Currently this project doesnt receive funding so unfortunately I have limited time to prioritize such things. Your welcome to try and work on it yourself if you want.

Sibras avatar Mar 29 '21 09:03 Sibras

@Sibras Well, coincidentally, I am almost done adding support for building your fork as part of the vcpkg's gnutls port, in a similar fashion to how nettle and gmp ports are done. I may how some follow up questions, will get back to you within a day or two if so.

wrobelda avatar Mar 29 '21 14:03 wrobelda

The first issue I noticed is that you don't provide minitasn1 with your source archives, while upstream does. So what I am working on right now is getting the libtasn1 build under windows.

wrobelda avatar Mar 29 '21 18:03 wrobelda

libtasn1 is a git submodule within the devel folder. The VS project uses several files from within that directory directly as part of the project compiation so it will need to be initialised. You can see "project_get_dependencies.bat" for how I init the submodules.

Sibras avatar Mar 30 '21 03:03 Sibras

Yeah, I am aware of that, although your readme only mentions the gnulib submodule, so at first I thought your sources had the minitasn1 amalgamated in – just like the upstream GnuTLS does. Anyway, that's not a big issue, as I explained I am working on getting the libtasn1 vcpkg port to build on Windows.

wrobelda avatar Mar 30 '21 03:03 wrobelda

FYI you may want to check out and test the referenced vcpkg PR for a Windows-compatible port.

wrobelda avatar May 20 '21 20:05 wrobelda

@Sibras, FYI, the vcpkg port is now feature-complete and ready for merging: https://github.com/microsoft/vcpkg/pull/18029

You may want to look into the patches there. In fact, all of the projects of yours that vcpkg uses (nettle, libgcrypt, gmp) are patched similarly. In particular, vcpkg expects that the library bears the same name between different types of builds (except the debug libs with a customary 'd' suffix), whereas you tend to add custom suffixes. Static builds also had to have the explicit dependency on libraries removed. Lastly, the relative output folder is set to high up (shallow) in the structure, which causes the build files to be saved outside of the tree.

On top of that, I wish you had a separate branch for a stable gnutls 3.6.x. The 3.7 is a "next" release and both are supported by the upstream. Right now the latest 3.6 version you had tagged was 3.6.15, but 3.6.16 was released in May, addressing two CVS'.

wrobelda avatar Oct 06 '21 22:10 wrobelda

You may want to look into the patches there. In fact, all of the projects of yours that vcpkg uses (nettle, libgcrypt, gmp) are patched similarly. In particular, vcpkg expects that the library bears the same name between different types of builds (except the debug libs with a customary 'd' suffix), whereas you tend to add custom suffixes.

Thats just differences in the output folder format. SMP outputs static and dynamic libs to the same folder so they have to have different names so they dont clash.

Static builds also had to have the explicit dependency on libraries removed.

I have been considering removing the explicit inclusion of dependencies in static libs for a while. But this means people who download the prebuilt libs will then need to download all the dependencies and update their projects to also include those. So im undecided on whether that is more trouble than its worth.

Lastly, the relative output folder is set to high up (shallow) in the structure, which causes the build files to be saved outside of the tree.

You can also correct this by just passing "/p:OutDir=..." to the msbuild options command line instead of patching the project files.

On top of that, I wish you had a separate branch for a stable gnutls 3.6.x. The 3.7 is a "next" release and both are supported by the upstream. Right now the latest 3.6 version you had tagged was 3.6.15, but 3.6.16 was released in May, addressing two CVS'.

I just track the upstream master branch. Again its one of those 'limited time/resources' issues where I only track a single branch.

Sibras avatar Oct 07 '21 04:10 Sibras

I am updating gnutls to 3.8.3 https://github.com/microsoft/vcpkg/pull/39983

I try to use your update lib in vcpkg (shiftmedia-libgnutls) to compile with curl on windows. I get an error on this line: https://github.com/ShiftMediaProject/gnutls/blob/master/SMP/gnutls/gnutls.h#L42

C:\src\vcpkg\installed\x64-windows\include\gnutls/gnutls.h(42): error C2628: 'SSIZE_T' followed by '__int64' is illegal (did you forget a ';'?)

I remove this line and it compile. But I am not sure that intendent solution. Can you help?

talregev avatar Jul 19 '24 15:07 talregev

The SSIZE_T macro is from BaseTSD.h in the windows SDK. This is required because msvc doesnt have a ssize_t define. By the look of the error it appears something else has already defined ssize_t on your build platform and that is causing the issue. A stock msvc configuration shouldnt do that. So either find what is already defining ssize_t or change the affected lines in gnutls.h to be wrapped in a #ifndef ssize_t

Sibras avatar Jul 20 '24 06:07 Sibras

I will try to add a #ifndef ssize_t. If it help I will add PR to here. I think maybe ssize_t is define with typedef. If is this case, how we can overcome?

talregev avatar Jul 20 '24 07:07 talregev

The SSIZE_T macro is from BaseTSD.h in the windows SDK. This is required because msvc doesnt have a ssize_t define. By the look of the error it appears something else has already defined ssize_t on your build platform and that is causing the issue. A stock msvc configuration shouldnt do that. So either find what is already defining ssize_t or change the affected lines in gnutls.h to be wrapped in a #ifndef ssize_t

You solution is working. But I am thinking maybe is better to undefine the ssize_t then define it your way?

talregev avatar Jul 20 '24 07:07 talregev

I will make a PR with your original solution, and we can discuss there. Thank you for the hint.

talregev avatar Jul 20 '24 07:07 talregev

I added the latest version of this repo to vcpkg. Do you want to close this issue?

talregev avatar Jul 31 '24 06:07 talregev