GNU bug report logs - #56505
[PATCHES] Mingw configuration for openssl

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56505 in the body.
You can then email your comments to 56505 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vivien Kraus <vivien <at> planete-kraus.eu>
To: guix-patches <at> gnu.org
Subject: [PATCHES] Mingw configuration for openssl
Date: Tue, 12 Jul 2022 01:55:37 +0200

[Message part 1 (text/plain, inline)]

Dear guix,

openssl can be cross-compiled to mingw, by adding a mingw entry in the
list of known openssl targets.

What do you think?

Best regards,

Vivien

[0001-gnu-openssl-Cross-compile-to-mingw.patch (text/x-patch, attachment)]

Message #8 received at 56505 <at> debbugs.gnu.org (full text, mbox):

From: Vivien Kraus <vivien <at> planete-kraus.eu>
To: 56505 <at> debbugs.gnu.org
Subject: Use the target predicates from (guix utils)
Date: Tue, 19 Jul 2022 20:37:08 +0200

[Message part 1 (text/plain, inline)]

Dear guix,

antipode on #guix told me that these archaic tests to determine the
openssl target should be replaced with the new target predicates in
(guix utils), and that the kernel and the architecture should be dealt
with independently.

However, it seems that mingw targets do not use the same scheme, so I
had to keep that special case.

I had to introduce a new predicate for mips64el. As far as I
understand, this is also a 64-bit target, so it should also be detected
by target-64bit?, but fortunately this is already the case, so I don’t
have to change target-64bit?. I don’t think there are other predicates
that I should change, but I may be wrong.

What do you think?

Best regards,

Vivien

[v2-0001-gnu-openssl-Cross-compile-to-mingw.patch (text/x-patch, attachment)]

[v2-0002-guix-Add-target-mips64el.patch (text/x-patch, attachment)]

[v2-0003-gnu-openssl-use-target-predicates-from-guix-utils.patch (text/x-patch, attachment)]

Message #13 received at 56505-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vivien Kraus <vivien <at> planete-kraus.eu>
Cc: 56505-done <at> debbugs.gnu.org
Subject: Re: bug#56505: [PATCHES] Mingw configuration for openssl
Date: Fri, 05 Aug 2022 00:14:12 +0200

Hi Vivien,

Vivien Kraus <vivien <at> planete-kraus.eu> skribis:

> antipode on #guix told me that these archaic tests to determine the
> openssl target should be replaced with the new target predicates in
> (guix utils), and that the kernel and the architecture should be dealt
> with independently.

Good idea.

> However, it seems that mingw targets do not use the same scheme, so I
> had to keep that special case.
>
> I had to introduce a new predicate for mips64el. As far as I
> understand, this is also a 64-bit target, so it should also be detected
> by target-64bit?, but fortunately this is already the case, so I don’t
> have to change target-64bit?. I don’t think there are other predicates
> that I should change, but I may be wrong.
>
> What do you think?

I think that’s good!

> From 4084fb014e84e6b15825c6c37dcdba8bde56fa4e Mon Sep 17 00:00:00 2001
> From: Vivien Kraus <vivien <at> planete-kraus.eu>
> Date: Sat, 9 Jul 2022 23:39:16 +0200
> Subject: [PATCH v2 1/3] gnu: openssl: Cross-compile to mingw.
>
> * gnu/packages/tls.scm (target->openssl-target): Add cases for mingw and
> mingw64.

[...]

> From e4631751a4e435a2125b5d72f665f6ec0ef5d6e1 Mon Sep 17 00:00:00 2001
> From: Vivien Kraus <vivien <at> planete-kraus.eu>
> Date: Tue, 19 Jul 2022 20:05:45 +0200
> Subject: [PATCH v2 2/3] guix: Add target-mips64el?.
>
> * guix/utils.scm (target-mips64el?): New function. It detects whether the
> target system is mips64el.

[...]

> From ae3bffd19c2887342e28372c3c613e998eb21840 Mon Sep 17 00:00:00 2001
> From: Vivien Kraus <vivien <at> planete-kraus.eu>
> Date: Tue, 19 Jul 2022 20:09:14 +0200
> Subject: [PATCH v2 3/3] gnu: openssl: use target predicates from (guix utils)
>  for openssl.
>
> ---
>  gnu/packages/tls.scm | 65 ++++++++++++++++++++++++++------------------
>  1 file changed, 38 insertions(+), 27 deletions(-)

Added a commit log to this one and committed, thanks!

‘guix build openssl --target=x86_64-w64-mingw32’ works and the funny
part is that .dll files end up in bin/, but I think that’s intended on
Windows?

Ludo’.

Message #16 received at 56505-done <at> debbugs.gnu.org (full text, mbox):

From: Vivien Kraus <vivien <at> planete-kraus.eu>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 56505-done <at> debbugs.gnu.org
Subject: Re: bug#56505: [PATCHES] Mingw configuration for openssl
Date: Fri, 05 Aug 2022 09:58:56 +0200

[Message part 1 (text/plain, inline)]

Hi,

Le vendredi 05 août 2022 à 00:14 +0200, Ludovic Courtès a écrit :
> ‘guix build openssl --target=x86_64-w64-mingw32’ works and the funny
> part is that .dll files end up in bin/, but I think that’s intended
> on
> Windows?

That’s right. Windows does not have shared objects, and DLLs are not.
You cannot use the compiler to link to a DLL as far as I understand, so
you wouldn’t put them in lib. What you have in lib are the so-called
"import libraries" (.dll.a). These are static libraries that pretend to
provide the functionality, but in fact open the DLL at run-time to
fetch the library implementation from the DLL. So DLLs are kind of
resources.

Anyway, you see that in lib/ you have all the .dll.a files… Oops… I may
have forgotten to check this… This is not a huge problem, because all
outputs would be available when building a dependent package, but it’s
still not right I think.

Now, the .dll.a files are smaller than the static libraries, but not
that small. I don’t know why exactly.

Should I open a new issue with this patch, or is it somehow possible to
continue the discussion here?

Best regards,

Vivien

[0001-gnu-openssl-Keep-.dll.a-files-in-main-output.patch (text/x-patch, attachment)]

Message #19 received at 56505-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vivien Kraus <vivien <at> planete-kraus.eu>
Cc: 56505-done <at> debbugs.gnu.org
Subject: Re: bug#56505: [PATCHES] Mingw configuration for openssl
Date: Fri, 05 Aug 2022 11:34:36 +0200

Hi,

Vivien Kraus <vivien <at> planete-kraus.eu> skribis:

> Le vendredi 05 août 2022 à 00:14 +0200, Ludovic Courtès a écrit :
>> ‘guix build openssl --target=x86_64-w64-mingw32’ works and the funny
>> part is that .dll files end up in bin/, but I think that’s intended
>> on
>> Windows?
>
> That’s right. Windows does not have shared objects, and DLLs are not.
> You cannot use the compiler to link to a DLL as far as I understand, so
> you wouldn’t put them in lib. What you have in lib are the so-called
> "import libraries" (.dll.a). These are static libraries that pretend to
> provide the functionality, but in fact open the DLL at run-time to
> fetch the library implementation from the DLL. So DLLs are kind of
> resources.
>
> Anyway, you see that in lib/ you have all the .dll.a files… Oops… I may
> have forgotten to check this… This is not a huge problem, because all
> outputs would be available when building a dependent package, but it’s
> still not right I think.

Oh, I see.

> From 1ee8daf446ca874ff4e5daa65d6f4034df51838e Mon Sep 17 00:00:00 2001
> From: Vivien Kraus <vivien <at> planete-kraus.eu>
> Date: Fri, 5 Aug 2022 09:52:21 +0200
> Subject: [PATCH] gnu: openssl: Keep .dll.a files in main output.
>
> * gnu/packages/tls.scm (openssl) [phase move-static-libraries]: Do not move
> .dll.a files to the static output when targetting mingw.

Applied, thanks!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.