Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Chí-Thanh Christopher Nguyễn]

Alec Warner schrieb:
On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel > wrote:


Someone needs to grow up here.


Meh, to me (someone who can't commit to ::gentoo) I have a few concerns here. 
First, I don't see a lot of QA reverts on the gentoo-dev list. Is it common 
practice to post reverts publicly? Second, I'm not aware that we would revert 
for things like this. Most of the items you mention look fairly minor (maybe 
the python comment looks impactful?) Why can't we fix these items in a future 
commit, rather than revert? What did Patrice's commit break?


If the issues are so serious that we have to prevent any breakage/regressions 
from reaching users, I guess an alternative response would have been to 
p.mask the offending new ebuild. Unless the commit caused some tree-wide 
breakage which I can't see here however.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

[James Le Cuirot]

On Thu, 12 Mar 2020 11:23:04 +0100
Alexis Ballier  wrote:

> On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org wrote:
> > As this native Win32 support is considered highly experimental still,
> > I
> > would like to apply the libtool patches for parity via elibtoolize
> > only,
> > without applying them in sys-devel/libtool itself yet.
> >   
> 
> IIRC you need to do it this way, experimental or not: elibtoolize is
> needed for packages whose autotools have been generated with an old
> libtool (ie all of them for now). eautoreconf should call elibtoolize,
> so, after having this in elt-patches, better focus on upstreaming this
> in libtool itself so that the need for elibtoolize fades away with
> time.
> 
> You will probably run into the same issues as in the old days with BSD:
> not all packages run elibtoolize and you do not have a sane way to
> force this besides editing ebuilds.

I've long wanted to automatically apply elibtoolize to fix other
cross-compile issues. I did come up with a rough prototype and it did
work though I imagine it might break some packages. Maybe it should be
opt-out rather than opt-in?

Without looking into the meat of the libtool patches themselves, the
changes seem good.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp7XRjCKFBMd.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 4/4] winnt: die if libtool version is not 2.4.6+

[James Le Cuirot]

On Thu, 12 Mar 2020 09:06:26 +0100
ha...@gentoo.org wrote:

> From: Michael Haubenwallner 
> 
> Signed-off-by: Michael Haubenwallner 
> ---
>  eltpatch.in | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/eltpatch.in b/eltpatch.in
> index 6b69216..e12f754 100644
> --- a/eltpatch.in
> +++ b/eltpatch.in
> @@ -179,7 +179,7 @@ elibtoolize() {
>   *-hpux*)elt_patches+=" hpux-conf deplibs hc-flag-ld 
> hardcode hardcode-relink relink-prog no-lc" ;;
>   *-irix*)elt_patches+=" irix-ltmain" ;;
>   *-mint*)elt_patches+=" mint-conf" ;;
> - *-winnt*)   elt_patches+=" winnt-conf winnt-ltmain" ;;
> + *-winnt*)   elt_patches+=" winnt-ltmain winnt-conf" ;;
>   esac
>  
>   if ${LD} --version 2>&1 | grep -qs 'GNU gold'; then

This change reorders something you added in the first patch.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUhSt6MDEk0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Andreas K. Huettel]

Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny:
> On Thu, 2020-03-12 at 11:44 -0700, Alec Warner wrote:
> > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel 
> > 
> > wrote:
> > > Someone needs to grow up here.
> > 
> > Meh, to me (someone who can't commit to ::gentoo) I have a few concerns
> > here. First, I don't see a lot of QA reverts on the gentoo-dev list. Is it
> > common practice to post reverts publicly?
> 
> I suppose that a part of the problem is the default Reply-To in these
> mails.

Which was deliberately added...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Michał Górny]

On Thu, 2020-03-12 at 11:44 -0700, Alec Warner wrote:
> On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel 
> wrote:
> 
> > Someone needs to grow up here.
> > 
> 
> Meh, to me (someone who can't commit to ::gentoo) I have a few concerns
> here. First, I don't see a lot of QA reverts on the gentoo-dev list. Is it
> common practice to post reverts publicly?

I suppose that a part of the problem is the default Reply-To in these
mails.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Andreas K. Huettel]

Am Donnerstag, 12. März 2020, 19:44:15 CET schrieb Alec Warner:
> On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel 
> 
> wrote:
> > Someone needs to grow up here.
> 
> Meh, to me (someone who can't commit to ::gentoo) I have a few concerns
> here. First, I don't see a lot of QA reverts on the gentoo-dev list. Is it
> common practice to post reverts publicly? 

It somehow depends on
* how abysmal, and
* how typical

> I'm also not sure intimating that people are acting like children is
> helpful.

You seem to to have not much interaction with the person in question.



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Alec Warner]

On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel 
wrote:

> Someone needs to grow up here.
>

Meh, to me (someone who can't commit to ::gentoo) I have a few concerns
here. First, I don't see a lot of QA reverts on the gentoo-dev list. Is it
common practice to post reverts publicly? Second, I'm not aware that we
would revert for things like this. Most of the items you mention look
fairly minor (maybe the python comment looks impactful?) Why can't we fix
these items in a future commit, rather than revert? What did Patrice's
commit break?

I'm also not sure intimating that people are acting like children is
helpful.

-A


>
> --  Weitergeleitete Nachricht  --
>
> Betreff: [gentoo-commits] repo/gentoo:master commit in:
> app-office/calcurse/
> Datum: Mittwoch, 11. März 2020, 09:24:16 CET
> Von: Patrice Clement 
> An: gentoo-comm...@lists.gentoo.org
>
> commit: 81a65d7da5b5e8b9e48323d13da05525d08b9551
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Wed Mar 11 08:21:58 2020 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Wed Mar 11 08:24:03 2020 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81a65d7d
>
> app-office/calcurse: drop package to m-n.
>
> Package-Manager: Portage-2.3.89, Repoman-2.3.20
> Signed-off-by: Patrice Clement  gentoo.org>
>
>  app-office/calcurse/metadata.xml | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/app-office/calcurse/metadata.xml
> b/app-office/calcurse/metadata.xml
> index d5b9396fdc3..aa7b56c65ee 100644
> --- a/app-office/calcurse/metadata.xml
> +++ b/app-office/calcurse/metadata.xml
> @@ -1,9 +1,7 @@
>  
>  http://www.gentoo.org/dtd/metadata.dtd";>
>  
> -
> -   monsie...@gentoo.org
> -
> +
>  Calcurse is a text-based personal organizer which helps
> keeping
>  track of events and everyday tasks. It contains a calendar, a 'todo'
> list,
> and
>  puts your appointments in order. The user interface is configurable, and
> one
> can
>
>
> -
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, qa, toolchain, base-system, perl, libreoffice)
>

[gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Andreas K. Huettel]

Someone needs to grow up here.

--  Weitergeleitete Nachricht  --

Betreff: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/
Datum: Mittwoch, 11. März 2020, 09:24:16 CET
Von: Patrice Clement 
An: gentoo-comm...@lists.gentoo.org

commit: 81a65d7da5b5e8b9e48323d13da05525d08b9551
Author: Patrice Clement  gentoo  org>
AuthorDate: Wed Mar 11 08:21:58 2020 +
Commit: Patrice Clement  gentoo  org>
CommitDate: Wed Mar 11 08:24:03 2020 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81a65d7d

app-office/calcurse: drop package to m-n.

Package-Manager: Portage-2.3.89, Repoman-2.3.20
Signed-off-by: Patrice Clement  gentoo.org>

 app-office/calcurse/metadata.xml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/app-office/calcurse/metadata.xml b/app-office/calcurse/metadata.xml
index d5b9396fdc3..aa7b56c65ee 100644
--- a/app-office/calcurse/metadata.xml
+++ b/app-office/calcurse/metadata.xml
@@ -1,9 +1,7 @@
 
 http://www.gentoo.org/dtd/metadata.dtd";>
 
-
-   monsie...@gentoo.org
-
+
 Calcurse is a text-based personal organizer which helps 
keeping
 track of events and everyday tasks. It contains a calendar, a 'todo' list, 
and
 puts your appointments in order. The user interface is configurable, and one 
can


-
-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

[Alexis Ballier]

On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org wrote:
> As this native Win32 support is considered highly experimental still,
> I
> would like to apply the libtool patches for parity via elibtoolize
> only,
> without applying them in sys-devel/libtool itself yet.
> 

IIRC you need to do it this way, experimental or not: elibtoolize is
needed for packages whose autotools have been generated with an old
libtool (ie all of them for now). eautoreconf should call elibtoolize,
so, after having this in elt-patches, better focus on upstreaming this
in libtool itself so that the need for elibtoolize fades away with
time.

You will probably run into the same issues as in the old days with BSD:
not all packages run elibtoolize and you do not have a sane way to
force this besides editing ebuilds.


Alexis.

[gentoo-dev] [PATCH 1/4] add lt-2.4.6 winnt patches for use with parity-2

[haubi]

From: Michael Haubenwallner 

If a package does not have libtool-2.4.6 there is no guarantee things
will work, and the package should use eautoreconf instead.

Signed-off-by: Michael Haubenwallner 
---
 eltpatch.in |   3 +-
 patches/winnt-conf/2.4.6-cmd-max-len|  15 +
 patches/winnt-conf/2.4.6-deplibs-method |  15 +
 patches/winnt-conf/2.4.6-dlload |  15 +
 patches/winnt-conf/2.4.6-dlopen-deplibs |  16 +
 patches/winnt-conf/2.4.6-dynlink|  46 ++
 patches/winnt-conf/2.4.6-dynlink-c  |  46 ++
 patches/winnt-conf/2.4.6-global-syms| 129 +
 patches/winnt-conf/2.4.6-pathconv   |  21 +
 patches/winnt-conf/2.4.6-pic-c  |  19 +
 patches/winnt-conf/2.4.6-pic-cxx|  18 +
 patches/winnt-conf/2.4.6-setup  |  23 +
 patches/winnt-conf/2.4.6-shlibs |  15 +
 patches/winnt-conf/2.4.6-shlibs-c   |  20 +
 patches/winnt-conf/2.4.6-shlibs-cxx |  33 ++
 patches/winnt-conf/2.4.6-strip  |  30 ++
 patches/winnt-ltmain/2.4.6  | 683 
 17 files changed, 1146 insertions(+), 1 deletion(-)
 create mode 100644 patches/winnt-conf/2.4.6-cmd-max-len
 create mode 100644 patches/winnt-conf/2.4.6-deplibs-method
 create mode 100644 patches/winnt-conf/2.4.6-dlload
 create mode 100644 patches/winnt-conf/2.4.6-dlopen-deplibs
 create mode 100644 patches/winnt-conf/2.4.6-dynlink
 create mode 100644 patches/winnt-conf/2.4.6-dynlink-c
 create mode 100644 patches/winnt-conf/2.4.6-global-syms
 create mode 100644 patches/winnt-conf/2.4.6-pathconv
 create mode 100644 patches/winnt-conf/2.4.6-pic-c
 create mode 100644 patches/winnt-conf/2.4.6-pic-cxx
 create mode 100644 patches/winnt-conf/2.4.6-setup
 create mode 100644 patches/winnt-conf/2.4.6-shlibs
 create mode 100644 patches/winnt-conf/2.4.6-shlibs-c
 create mode 100644 patches/winnt-conf/2.4.6-shlibs-cxx
 create mode 100644 patches/winnt-conf/2.4.6-strip
 create mode 100644 patches/winnt-ltmain/2.4.6

diff --git a/eltpatch.in b/eltpatch.in
index d8c847b..6b69216 100644
--- a/eltpatch.in
+++ b/eltpatch.in
@@ -179,6 +179,7 @@ elibtoolize() {
*-hpux*)elt_patches+=" hpux-conf deplibs hc-flag-ld 
hardcode hardcode-relink relink-prog no-lc" ;;
*-irix*)elt_patches+=" irix-ltmain" ;;
*-mint*)elt_patches+=" mint-conf" ;;
+   *-winnt*)   elt_patches+=" winnt-conf winnt-ltmain" ;;
esac
 
if ${LD} --version 2>&1 | grep -qs 'GNU gold'; then
@@ -371,7 +372,7 @@ elibtoolize() {
ret=$?
fi
;;
-   aixrtl|hpux-conf)
+   aixrtl|hpux-conf|winnt-conf)
ret=1
local subret=0
# apply multiple patches as often as 
they match
diff --git a/patches/winnt-conf/2.4.6-cmd-max-len 
b/patches/winnt-conf/2.4.6-cmd-max-len
new file mode 100644
index 000..0b7b290
--- /dev/null
+++ b/patches/winnt-conf/2.4.6-cmd-max-len
@@ -0,0 +1,15 @@
+--- configure
 configure
+@@ -5915,11 +5915,11 @@
+ # And add a safety zone
+ lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
+ lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
+ ;;
+ 
+-  interix*)
++  interix* | winnt*)
+ # We know the value 262144 and hardcode it with a safety zone (like BSD)
+ lt_cv_sys_max_cmd_len=196608
+ ;;
+ 
+   os2*)
diff --git a/patches/winnt-conf/2.4.6-deplibs-method 
b/patches/winnt-conf/2.4.6-deplibs-method
new file mode 100644
index 000..92b2ac9
--- /dev/null
+++ b/patches/winnt-conf/2.4.6-deplibs-method
@@ -0,0 +1,15 @@
+--- configure
 configure
+@@ -6285,11 +6285,11 @@
+   # func_win32_libid is a shell function defined in ltmain.sh
+   lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
+   lt_cv_file_magic_cmd='func_win32_libid'
+   ;;
+ 
+-mingw* | pw32*)
++mingw* | pw32* | winnt*)
+   # Base MSYS/MinGW do not provide the 'file' command needed by
+   # func_win32_libid shell function, so use a weaker test based on 'objdump',
+   # unless we find 'file', for example because we are cross-compiling.
+   if ( file / ) >/dev/null 2>&1; then
+ lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
diff --git a/patches/winnt-conf/2.4.6-dlload b/patches/winnt-conf/2.4.6-dlload
new file mode 100644
index 000..ea9b804
--- /dev/null
+++ b/patches/winnt-conf/2.4.6-dlload
@@ -0,0 +1,15 @@
+--- configure
 configure
+@@ -13596,11 +13716,11 @@
+ 
+   ;;
+ beos*)
+   LT_DLLOADERS="$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}load_add_on.la"
+   ;;
+-cygwin* | mingw* | pw32*)
++cygwin* | mingw* | pw32* | winnt*)
+   ac_fn_c_check_decl "$LINENO" "cygwin_conv_path" 
"ac_cv_have_decl_cygwin_conv_path" "#include 
+ "
+ if test "x$ac_cv_have_decl_cygwin_conv_path

[gentoo-dev] [PATCH 3/4] winnt: enable WOE properties, found in intl.m4

[haubi]

From: Michael Haubenwallner 

Signed-off-by: Michael Haubenwallner 
---
 patches/winnt-conf/woe32| 11 +++
 patches/winnt-conf/woe32dll | 11 +++
 2 files changed, 22 insertions(+)
 create mode 100644 patches/winnt-conf/woe32
 create mode 100644 patches/winnt-conf/woe32dll

diff --git a/patches/winnt-conf/woe32 b/patches/winnt-conf/woe32
new file mode 100644
index 000..3eea6d1
--- /dev/null
+++ b/patches/winnt-conf/woe32
@@ -0,0 +1,11 @@
+--- configure
 configure
+@@ -14769,7 +14769,7 @@
+ 
+ 
+ case "$host_os" in
+-  mingw* | cygwin*) is_woe32=yes ;;
++  mingw* | cygwin* | winnt*) is_woe32=yes ;;
+   *) is_woe32=no ;;
+ esac
+ WOE32=$is_woe32
diff --git a/patches/winnt-conf/woe32dll b/patches/winnt-conf/woe32dll
new file mode 100644
index 000..b4fac5f
--- /dev/null
+++ b/patches/winnt-conf/woe32dll
@@ -0,0 +1,11 @@
+--- configure
 configure
+@@ -24762,7 +24762,7 @@
+ 
+ if test "$enable_shared" = yes; then
+   case "$host_os" in
+-mingw* | cygwin*) is_woe32dll=yes ;;
++mingw* | cygwin* | winnt*) is_woe32dll=yes ;;
+ *) is_woe32dll=no ;;
+   esac
+ else
-- 
2.22.0

[gentoo-dev] [PATCH 4/4] winnt: die if libtool version is not 2.4.6+

[haubi]

From: Michael Haubenwallner 

Signed-off-by: Michael Haubenwallner 
---
 eltpatch.in | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/eltpatch.in b/eltpatch.in
index 6b69216..e12f754 100644
--- a/eltpatch.in
+++ b/eltpatch.in
@@ -179,7 +179,7 @@ elibtoolize() {
*-hpux*)elt_patches+=" hpux-conf deplibs hc-flag-ld 
hardcode hardcode-relink relink-prog no-lc" ;;
*-irix*)elt_patches+=" irix-ltmain" ;;
*-mint*)elt_patches+=" mint-conf" ;;
-   *-winnt*)   elt_patches+=" winnt-conf winnt-ltmain" ;;
+   *-winnt*)   elt_patches+=" winnt-ltmain winnt-conf" ;;
esac
 
if ${LD} --version 2>&1 | grep -qs 'GNU gold'; then
@@ -286,6 +286,18 @@ elibtoolize() {
ret=$?
fi
;;
+   winnt-ltmain)
+   local version=$(ELT_libtool_version 
"${d}/ltmain.sh")
+   case ${version} in
+   2.4.6 | 2.4.6[' .']* )
+   ELT_walk_patches 
"${d}/ltmain.sh" "${p}"
+   ret=$?
+   ;;
+   *)
+   die "${p}: need libtool 2.4.6+ 
(not ${version}) in ${d}"
+   ;;
+   esac
+   ;;
*)
ELT_walk_patches "${d}/ltmain.sh" "${p}"
ret=$?
-- 
2.22.0

[gentoo-dev] [PATCH 2/4] add lt-2.4.6.42-b88ce winnt patches for use with parity-2

[haubi]

From: Michael Haubenwallner 

If a package does not have libtool-2.4.6 or 2.4.6.42-b88c3 there is no
guarantee things will work, and the package should use eautoreconf.

Signed-off-by: Michael Haubenwallner 
---
 patches/winnt-conf/2.4.6.42-global-syms | 129 
 patches/winnt-conf/2.4.6.42-shlibs  |  15 +++
 patches/winnt-conf/2.4.6.42-shlibs-c|  20 
 patches/winnt-conf/2.4.6.42-shlibs-cxx  |  33 ++
 patches/winnt-conf/2.4.6.42-strip   |  30 ++
 5 files changed, 227 insertions(+)
 create mode 100644 patches/winnt-conf/2.4.6.42-global-syms
 create mode 100644 patches/winnt-conf/2.4.6.42-shlibs
 create mode 100644 patches/winnt-conf/2.4.6.42-shlibs-c
 create mode 100644 patches/winnt-conf/2.4.6.42-shlibs-cxx
 create mode 100644 patches/winnt-conf/2.4.6.42-strip

diff --git a/patches/winnt-conf/2.4.6.42-global-syms 
b/patches/winnt-conf/2.4.6.42-global-syms
new file mode 100644
index 000..704ee84
--- /dev/null
+++ b/patches/winnt-conf/2.4.6.42-global-syms
@@ -0,0 +1,129 @@
+--- configure
 configure
+@@ -7115,11 +7115,11 @@
+ # Define system-specific variables.
+ case $host_os in
+ aix*)
+   symcode='[BCDT]'
+   ;;
+-cygwin* | mingw* | pw32* | cegcc*)
++cygwin* | mingw* | pw32* | cegcc* | winnt*)
+   symcode='[ABCDGISTW]'
+   ;;
+ hpux*)
+   if test ia64 = "$host_cpu"; then
+ symcode='[ABCDEGRST]'
+@@ -7154,46 +7154,56 @@
+   symcode='[ABCDGIRSTW]' ;;
+ esac
+ 
+ if test "$lt_cv_nm_interface" = "MS dumpbin"; then
+   # Gets list of data symbols to import.
+-  lt_cv_sys_global_symbol_to_import="sed -n -e 's/^I .* \(.*\)$/\1/p'"
++  lt_cv_sys_global_symbol_to_import="sed -n -e 's/^I .* 
\([a-zA-Z_][0-9a-zA-Z_]*\)$/\1/p'"
+   # Adjust the below global symbol transforms to fixup imported variables.
+-  lt_cdecl_hook=" -e 's/^I .* \(.*\)$/extern __declspec(dllimport) char 
\1;/p'"
+-  lt_c_name_hook=" -e 's/^I .* \(.*\)$/  {\"\1\", (void *) 0},/p'"
++  lt_cdecl_hook=" -e 's/^I .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/extern 
__declspec(dllimport) char \1;/p'"
++  lt_c_name_hook=" -e 's/^I .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"\1\", (void 
*) 0},/p'"
+   lt_c_name_lib_hook="\
+-  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
+-  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
++  -e 's/^I .* \(lib[a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"\1\", (void *) 0},/p'\
++  -e 's/^I .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"lib\1\", (void *) 0},/p'"
+ else
+   # Disable hooks by default.
+   lt_cv_sys_global_symbol_to_import=
+   lt_cdecl_hook=
+   lt_c_name_hook=
+   lt_c_name_lib_hook=
++  case $host_os in
++  winnt*)
++lt_cv_sys_global_symbol_to_import="sed -n -e 's/^D [^ ]* 
\([a-zA-Z_][0-9a-zA-Z_]*\)$/\1/p'"
++lt_cdecl_hook=" -e 's/^D [^ ]* \([a-zA-Z_][0-9a-zA-Z_]*\)$/extern 
__declspec(dllimport) char \1;/p'"
++lt_c_name_hook=" -e 's/^D [^ ]* \([a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"\1\", 
(void *) 0},/p'"
++lt_c_name_lib_hook="\
++-e 's/^D [^ ]* \(lib[a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"\1\", (void *) 0},/p'\
++-e 's/^D [^ ]* \([a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"lib\1\", (void *) 0},/p'"
++;;
++  esac
+ fi
+ 
+ # Transform an extracted symbol line into a proper C declaration.
+ # Some systems (esp. on ia64) link data and code symbols differently,
+ # so use this general approach.
+ lt_cv_sys_global_symbol_to_cdecl="sed -n"\
+ $lt_cdecl_hook\
+-" -e 's/^T .* \(.*\)$/extern int \1();/p'"\
+-" -e 's/^$symcode$symcode* .* \(.*\)$/extern char \1;/p'"
++" -e 's/^T .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/extern int \1();/p'"\
++" -e 's/^$symcode$symcode* .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/extern char \1;/p'"
+ 
+ # Transform an extracted symbol line into symbol name and symbol address
+ lt_cv_sys_global_symbol_to_c_name_address="sed -n"\
+ $lt_c_name_hook\
+ " -e 's/^: \(.*\) .*$/  {\"\1\", (void *) 0},/p'"\
+-" -e 's/^$symcode$symcode* .* \(.*\)$/  {\"\1\", (void *) \&\1},/p'"
++" -e 's/^$symcode$symcode* .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"\1\", (void *) 
\&\1},/p'"
+ 
+ # Transform an extracted symbol line into symbol name with lib prefix and
+ # symbol address.
+ lt_cv_sys_global_symbol_to_c_name_address_lib_prefix="sed -n"\
+ $lt_c_name_lib_hook\
+ " -e 's/^: \(.*\) .*$/  {\"\1\", (void *) 0},/p'"\
+-" -e 's/^$symcode$symcode* .* \(lib.*\)$/  {\"\1\", (void *) \&\1},/p'"\
+-" -e 's/^$symcode$symcode* .* \(.*\)$/  {\"lib\1\", (void *) \&\1},/p'"
++" -e 's/^$symcode$symcode* .* \(lib[a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"\1\", (void 
*) \&\1},/p'"\
++" -e 's/^$symcode$symcode* .* \([a-zA-Z_][0-9a-zA-Z_]*\)$/  {\"lib\1\", (void 
*) \&\1},/p'"
+ 
+ # Handle CRLF in mingw tool chain
+ opt_cr=
+ case $build_os in
+ mingw*)
+@@ -7203,35 +7213,43 @@
+ 
+ # Try without a prefix underscore, then with it.
+ for ac_symprfx in "" "_"; do
+ 
+   # Transform symcode, sympat, and symprfx into a raw symbol and a C symbol.
+-  symxfrm="\\1 $ac_symprfx\\2 \\2"
++  # In Windows import libraries, symbols may be prefixed with __imp_, as well
++  # as __nm_ when using GNU ld.  The leading underscore (in 32bit) comes a

[gentoo-dev] [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

[haubi]

Hello fellow Gentoo devs!

As some of you may already know, in Prefix we are able to build native
Win32 binaries using the Visual Studio toolchain, nowadays driven by
Prefix on Cygwin as the build environment, using sys-devel/parity to
have a gcc like commandline interface for cl.exe, link.exe and others.

For example, in sys-libs/zlib the Makefile for Linux does work without
modification to create the native Win32 library, even if the library
file name does not match the Win32 library naming scheme.

On the other hand, one would expect libtool to create libraries having
proper Win32 naming scheme.

Fortunately, parity does provide libtool patches already[1], but because
parity itself is not widely recognized yet, they are unlikely to be
accepted upstream right now.  Beyond that, some of the unrelated but
required patches are submitted upstream, but without response so far.

As this native Win32 support is considered highly experimental still, I
would like to apply the libtool patches for parity via elibtoolize only,
without applying them in sys-devel/libtool itself yet.

WDYT?

[1] https://github.com/mduft/parity/tree/master/parity.patches

Thanks!
/haubi/