From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32740 invoked by alias); 25 Aug 2016 15:06:28 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 32730 invoked by uid 89); 25 Aug 2016 15:06:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=gross, formato, taught, Thinking X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Aug 2016 15:06:18 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bcwEO-0002b0-Mi for binutils@sourceware.org; Thu, 25 Aug 2016 11:06:16 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcwEO-0002ak-JJ; Thu, 25 Aug 2016 11:06:12 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4409 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bcwEM-0005RZ-NV; Thu, 25 Aug 2016 11:06:11 -0400 Date: Thu, 25 Aug 2016 15:06:00 -0000 Message-Id: <83d1kwevm1.fsf@gnu.org> From: Eli Zaretskii To: Nick Clifton CC: binutils@sourceware.org In-reply-to: <6954079e-dc38-cf7c-2cb7-357428a4b2d1@redhat.com> (message from Nick Clifton on Tue, 23 Aug 2016 10:21:21 +0100) Subject: Re: Binutils 2.27 linked statically to libintl Reply-to: Eli Zaretskii References: <834m6ecsmh.fsf@gnu.org> <6954079e-dc38-cf7c-2cb7-357428a4b2d1@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-SW-Source: 2016-08/txt/msg00275.txt.bz2 > From: Nick Clifton > 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.