From: Eli Zaretskii <eliz@gnu.org>
To: Nick Clifton <nickc@redhat.com>
Cc: binutils@sourceware.org
Subject: Re: Binutils 2.27 linked statically to libintl
Date: Thu, 25 Aug 2016 15:06:00 -0000 [thread overview]
Message-ID: <83d1kwevm1.fsf@gnu.org> (raw)
In-Reply-To: <6954079e-dc38-cf7c-2cb7-357428a4b2d1@redhat.com> (message from Nick Clifton on Tue, 23 Aug 2016 10:21:21 +0100)
> 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.
prev parent reply other threads:[~2016-08-25 15:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-21 10:40 Eli Zaretskii
2016-08-23 9:21 ` Nick Clifton
2016-08-23 14:31 ` Eli Zaretskii
2016-08-25 15:06 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83d1kwevm1.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).