Binutils 2.27 linked statically to libintl

Binutils 2.27 linked statically to libintl

[Eli Zaretskii]

Hi,

I built Binutils 2.27 natively on MS-Windows, using mingw.org's MinGW
tools, and found that the programs are linked statically to libintl
and libiconv, which makes the binaries significantly more fat.
Binutils 2.26, built on the same machine, was linked dynamically to
those libraries.

Digging a little deeper, I see that intl/config.intl says in Binutils
2.27:

  USE_NLS='yes'
  LIBINTL='d:/usr/lib/libintl.a d:/usr/lib/libiconv.a'
  LIBINTL_DEP=''
  INCINTL=''

whereas in 2.26 it said this:

  USE_NLS='yes'
  LIBINTL='-lintl'
  LIBINTL_DEP=''
  INCINTL=''

The same 'configure' command was used in both cases.

Can someone tell what am I doing wrong, and how can I cause the build
to use the dynamic link to shared libraries?  Is it a bug that I
should report to the Binutils Bugzilla?

TIA

P.S. I'm not subscribed to this list, so please CC me on the
responses.

Re: Binutils 2.27 linked statically to libintl

[Nick Clifton]

Hi Eli,

> Digging a little deeper, I see that intl/config.intl says in Binutils
> 2.27:
> 
>   USE_NLS='yes'
>   LIBINTL='d:/usr/lib/libintl.a d:/usr/lib/libiconv.a'
> 
> whereas in 2.26 it said this:
> 
>   USE_NLS='yes'
>   LIBINTL='-lintl'
> 
> The same 'configure' command was used in both cases.
> 
> Can someone tell what am I doing wrong,

Sorry - no.  Well not me anyway.  As far as I can see nothing has changed
in the configuration of intl library between 2,26 and 2,27.  Is the output 
from the two runs of the configure script (in the intl/ directory) the same ?
Especially when it runs the "checking for GNU gettext in libintl" tests ?
(It looks like the result of this test decides how LIBINTL is set up).


> and how can I cause the build to use the dynamic link to shared libraries?

Have you tried adding --enable-shared to the configure command line ?

If you are not using the internationalization features you could also add 
--disable-nls to the configure command line.


> Is it a bug that I should report to the Binutils Bugzilla?

Well more of a mis-feature than a bug.  The programs still work, they are
just a little bit bigger than they used to be.  So personally I do not think 
that it is a bug, but if it really matters to you then please feel free to
file a bug report.

Cheers
  Nick

Re: Binutils 2.27 linked statically to libintl

[Eli Zaretskii]

> From: Nick Clifton <nickc@redhat.com>
> Date: Tue, 23 Aug 2016 10:21:21 +0100
> 
> Hi Eli,

Thanks for responding.

> > Digging a little deeper, I see that intl/config.intl says in Binutils
> > 2.27:
> > 
> >   USE_NLS='yes'
> >   LIBINTL='d:/usr/lib/libintl.a d:/usr/lib/libiconv.a'
> > 
> > whereas in 2.26 it said this:
> > 
> >   USE_NLS='yes'
> >   LIBINTL='-lintl'
> > 
> > The same 'configure' command was used in both cases.
> > 
> > Can someone tell what am I doing wrong,
> 
> Sorry - no.  Well not me anyway.  As far as I can see nothing has changed
> in the configuration of intl library between 2,26 and 2,27.  Is the output 
> from the two runs of the configure script (in the intl/ directory) the same ?
> Especially when it runs the "checking for GNU gettext in libintl" tests ?
> (It looks like the result of this test decides how LIBINTL is set up).

Here's the result of comparing intl/config.log with Diff in the
relevant portions:

   configure:6224: checking for GNU gettext in libintl
  -configure:6251: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS   -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  -lintl >&5
  +configure:6251: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -Id:/usr/include  -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  d:/usr/lib/libintl.a d:/usr/lib/libiconv.a >&5
   configure:6251: $? = 0
   configure:6290: result: yes
  [...]
   configure:5431: checking for iconv
  -configure:5455: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS   -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  >&5
  -C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\cceE228y.o: In function `main':
  -d:\gnu\build-binutils-2.26\intl/conftest.c:49: undefined reference to `libiconv_open'
  -d:\gnu\build-binutils-2.26\intl/conftest.c:50: undefined reference to `libiconv'
  -d:\gnu\build-binutils-2.26\intl/conftest.c:51: undefined reference to `libiconv_close'
  +configure:5455: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS  -Id:/usr/include -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  >&5
  +C:\DOCUME~1\Zaretzky\LOCALS~1\Temp\ccQ4bEoy.o: In function `main':
  +d:\gnu\build-binutils-2.27\intl/conftest.c:49: undefined reference to `libiconv_open'
  +d:\gnu\build-binutils-2.27\intl/conftest.c:50: undefined reference to `libiconv'
  +d:\gnu\build-binutils-2.27\intl/conftest.c:51: undefined reference to `libiconv_close'
   collect2.exe: error: ld returned 1 exit status
   configure:5455: $? = 1
   configure: failed program was:
  @@ -2303,13 +2285,13 @@
   |   ;
   |   return 0;
   | }
  -configure:5518: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS   -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  -liconv
  >&5
  +configure:5518: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS  -Id:/usr/include -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  d:/usr/lib/libiconv.a >&5
   configure:5518: $? = 0
   configure:5529: result: yes
   configure:5560: checking how to link with libiconv
  -configure:5562: result: -liconv
  +configure:5562: result: d:/usr/lib/libiconv.a
   configure:5572: checking for iconv declaration
  [...]
   configure:6224: checking for GNU gettext in libintl
  -configure:6251: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS   -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  -lintl >&5
  +configure:6251: mingw32-gcc -o conftest.exe -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -Id:/usr/include  -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  d:/usr/lib/libintl.a d:/usr/lib/libiconv.a >&5
   configure:6251: $? = 0
   configure:6290: result: yes

As you see, the test for gettext returns the same result, and so is
the test of how to link against libiconv.  The difference is that the
latter test already uses -liconv in the first case, but explicit
linking against libiconv.a in the second.  And the same with libintl.

The only other difference I see between these two builds is that 2.26
was built with GCC 4.8.1, whereas 2.27 with GCC 5.3.0.  But that's
just the compiler, the libraries involved, libiconv and libintl,
didn't changed, and neither did the respective *.la files installed on
this system.

> > and how can I cause the build to use the dynamic link to shared libraries?
> 
> Have you tried adding --enable-shared to the configure command line ?

No, I haven't.  This is supposed to be enabled by default, and
config.log says

  configure:8802: checking whether the mingw32-gcc linker (d:/usr/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32/bin/ld.exe) supports shared libraries
  configure:9873: result: yes

But I will try this and see if it helps, thanks.

> If you are not using the internationalization features you could also add 
> --disable-nls to the configure command line.

Yes, I know.  But I'd like NLS support to be included.

> > Is it a bug that I should report to the Binutils Bugzilla?
> 
> Well more of a mis-feature than a bug.  The programs still work, they are
> just a little bit bigger than they used to be.

Surely not a catastrophe, I just am stumped about this.  Where could
the configure script take the d:/usr/lib/libintl.a and
d:/usr/lib/libiconv.a file names for the test programs -- they cannot
be an accident, as they specify the exact file names of these
libraries on my system.  Where do they come from?  Maybe if I find
that out, I could dig deeper into the root cause(s).

Thanks.

Re: Binutils 2.27 linked statically to libintl

[Eli Zaretskii]

> From: Nick Clifton <nickc@redhat.com>
> Date: Tue, 23 Aug 2016 10:21:21 +0100
> 
> Have you tried adding --enable-shared to the configure command line ?

I tried that; it didn't help.  Thinking some more about this, I
concluded that I don't really understand why you thought this could
make a difference.  Perhaps you thought that this would force libbfd
and libopcodes to be built as shared libraries, and then through that
force a dynamic link against libintl?  But in that case, as I knew for
quite some time, Binutils simply were not taught to produce shared
libraries on MS-Windows.  Here's the error message from libtool that
explains why:

  /bin/sh ./libtool --tag=CC    --mode=link mingw32-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wno-format  -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS   -release `cat libtool-soversion`   -static-libstdc++ -static-libgcc -Wl,--stack,12582912 -o libbfd.la -rpath /d/usr/lib archive.lo archures.lo bfd.lo bfdio.lo bfdwin.lo  cache.lo coff-bfd.lo compress.lo corefile.lo format.lo hash.lo  init.lo libbfd.lo linker.lo merge.lo opncls.lo reloc.lo  section.lo simple.lo stab-syms.lo stabs.lo syms.lo targets.lo  binary.lo ihex.lo srec.lo tekhex.lo verilog.lo `cat ofiles`   -lz
  libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  libtool: link: ar rc .libs/libbfd.a  archive.o archures.o bfd.o bfdio.o bfdwin.o cache.o coff-bfd.o compress.o corefile.o format.o hash.o init.o libbfd.o linker.o merge.o opncls.o reloc.o section.o simple.o stab-syms.o stabs.o syms.o targets.o binary.o ihex.o srec.o tekhex.o verilog.o pe-i386.o peigen.o cofflink.o coffgen.o dwarf2.o pei-i386.o elf32-i386.o elf-ifunc.o elf-nacl.o elf-vxworks.o elf32.o elf.o elflink.o elf-attrs.o elf-strtab.o elf-eh-frame.o dwarf1.o elf32-gen.o plugin.o cpu-i386.o cpu-iamcu.o cpu-plugin.o
  libtool: link: ranlib .libs/libbfd.a

I believe this happens because the link command doesn't specify
'--no-undefined', which AFAIK is required on Windows.

Since the only change in my system configuration I'm aware of is the
newer version of GCC, I compared the specs of both versions, but
didn't find anything relevant.  (I can post the specs, in case you
would like to review them.)

The only other change is that when I was building 2.26, the installed
Binutils were v2.25, while now it's 2.26.  Not sure how could that be
related, though.

I ended up manually editing each Makefile in the source tree to set:

  LIBINTL = -lintl -liconv
  LIBICONV = -liconv

This is quite gross, but it's simple and does the job.

Thanks.