Re: Binutils 2.27 linked statically to libintl

[Eli Zaretskii <eliz at gnu dot org>]

> 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.