Re: build failure on mac

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 17,  3:09pm, gdt%ir.bbn.com@localhost (Greg Troxel) wrote:
-- Subject: Re: build failure on mac

| --=-=-=
| Content-Type: text/plain
| Content-Transfer-Encoding: quoted-printable
| 
| 
| christos%zoulas.com@localhost (Christos Zoulas) writes:
| 
| > On Feb 17,  1:19pm, gdt%ir.bbn.com@localhost (Greg Troxel) wrote:
| > -- Subject: Re: build failure on mac
| >
| > | The problem seems to be in external/gpl3/binutils/usr.sbin/dbsym/Makefi=
| le:
| > |=20
| > |   revision 1.7
| > |   date: 2013/02/14 21:29:36;  author: christos;  state: Exp;  lines: +8=
|  -4
| > |   re-order library dependencies to make sure that -lintl and -lz are af=
| ter
| > |   the rest of the libraries so that static linking works.
| > |=20
| > | There is;
| > |=20
| > |   LDADD+=3D         -lz
| > |   DPADD+=3D         ${LIBZ}
| > |=20
| > | which seems wrong in the HOSTPROG case.
| >
| > I wonder how to fix this properly. Perhaps we need an autoconf test? Or
| > is it just enough not to include libz in the hostprog case?
| 
| The mac does have libz, but doesn't have .a, and has .dylib instead of
| .so.  There appears to be no static library
| 
| So $(LIBZ) has to be set to a platform-specific value, which probably
| seems separating library-as-dep and library-as-link (since the dep is
| null for dynlinking only), but all that seems best avoided.
| 
| I commented out those two lines, and the (host tool) build still
| includes -lz somehow.  With that, builds for i386, amd64 and evbppc all
| succeeded.
| 
| So as a first cut, putting the LDADD/DPADD of -lz/$(LIBZ) under the host
| tool ifndef sounds best.
| 
| Here's my build of dbsym after cleandir, with the LDADD/DPADD commented
| out.  You can see there are still two -lz.  Plus, there's no static
| linking, so the hard dependency on the .a does not make sense anyway.

Right, I get it now; thanks!

christos