link failures when building projects that use libtool

[Charlie Kester <corky1951@comcast.net>]

I have a recurring problem trying to build projects that use libtool.
The link step fails with a message like the one below, for libzip:

------------------
/bin/bash ../libtool  --tag=CC   --mode=link musl-gcc  -O2 -D_GNU_SOURCE
-I/usr/local/musl/include -static -s  -static -L/usr/local/musl/lib  -o
zipcmp zipcmp.o ../lib/libzip.la -lz

libtool: link: musl-gcc -O2 -D_GNU_SOURCE -I/usr/local/musl/include -s
-o zipcmp zipcmp.o  -L/usr/local/musl/lib ../lib/.libs/libzip.a -lz

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o: relocation
R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when
making a shared object

/usr/bin/ld: final link failed: Nonrepresentable section on output
-------------------

(I added blank lines to separate the lines of output, to satisfy
linelength conventions for email.)

Note that the -static flag was used in both the compile & the link
steps.  Yet the linker error seems to indicate that it is still trying
to build a shared library.  Worse, it's pulling in modules from glibc.

I've seen similar error messages with other projects that don't use
libtool, but in those cases it was fixed by adding the -static flag to
the link command in the Makefile.  As you can see, however, libtool
seems to be discarding that flag.

$ /usr/bin/ld --version
GNU ld (GNU Binutils for Debian) 2.27.90.20170205

The ltmain.sh included with the libzip sourcecode 
contains the following version info:
# libtool (GNU libtool) 2.4.2

I'd appreciate any ideas about how to fix this.  I see in the wiki's list of
bugs found with musl that something very like this was reported to the 
libtool developers as far back as 2012, but I don't see that it was ever resolved.