Re: [bug-gettext] libintl dependency on libgcc

[Bruno Haible]

Hi Michele,

> While compiling gettext 0.20.1 for 32-bit Windows (with
> --enable-shared --disable-static), I've noticed that libintl-8.dll
> depends on libgcc_s_sjlj-1.dll.
> 
> Here's the results of a tiny analysis with dumpbin:
> 
> C:\>dumpbin /DEPENDENTS libintl-8.dll
> 
> Dump of file libintl-8.dll
> 
> File Type: DLL
> 
>   Image has the following dependencies:
> 
>     libiconv-2.dll
>     ADVAPI32.dll
>     KERNEL32.dll
>     msvcrt.dll
>     libgcc_s_sjlj-1.dll

My binaries also depend on libwinpthread-1.dll. I guess I need to pass
the configure option --enable-threads=windows.

> C:\>dumpbin /IMPORTS:libgcc_s_sjlj-1.dll libintl-8.dll
> 
> Dump of file libintl-8.dll
> 
> File Type: DLL
> 
>   Section contains the following imports:
> 
>     libgcc_s_sjlj-1.dll
>               61EDB37C Import Address Table
>               61EDB1F4 Import Name Table
>                      0 time date stamp
>                      0 Index of first forwarder reference
> 
>                    78 __udivdi3
>                    7A __umoddi3
> 
> So, it seems that libintl only uses the two udivdi3 and umoddi3 of libgcc.
> 
> I'm wondering if there is a clean way to avoid that...

I run
  $ objdump libintl-8.dll > libintl.s
and then look which functions invoke __udivdi3 and __umoddi3.
It's __pformat_int.isra.0 which is part of the __mingw_pformat facility,
which is used by __mingw_vfprintf, __mingw_vsnprintf, __mingw_vsprintf,
which are activated by mingw's <stdio.h>.

So now this library contains two *printf implementations: the one borrowed
from gnulib and the one from mingw!

20 years ago, mingw started out as a minimal layer on top of the Windows
+ MSVCRT API. Nowadays, this layer does not seem to be minimal any more...

Bruno