[tex-live] Mac OS X compilation failure (revision 3204)

[Jonathan Kew]

To follow up on this.... I'd say this is definitely libtool-related.  
In Work/texk/xdvipdfmx/src/Makefile, we find

xdvipdfmx$(EXEEXT): $(xdvipdfmx_OBJECTS) $(xdvipdfmx_DEPENDENCIES)
	@rm -f xdvipdfmx$(EXEEXT)
	$(LINK) $(xdvipdfmx_LDFLAGS) $(xdvipdfmx_OBJECTS) $(xdvipdfmx_LDADD)  
$(LIBS)

where the build log shows that the $(LINK)... command expands to

/bin/sh ../libtool --tag=CC --mode=link gcc  -g -O2    -o xdvipdfmx - 
L../../../texk/kpathsea/.libs  xdvipdfmx-agl.o xdvipdfmx- 
agl_standard.o xdvipdfmx-bmpimage.o xdvipdfmx-cff.o xdvipdfmx- 
cff_dict.o xdvipdfmx-cid.o xdvipdfmx-cidtype0.o xdvipdfmx-cidtype2.o  
xdvipdfmx-cmap.o xdvipdfmx-cmap_read.o xdvipdfmx-cmap_write.o  
xdvipdfmx-cs_type2.o xdvipdfmx-dpxconf.o xdvipdfmx-dpxcrypt.o  
xdvipdfmx-dpxfile.o xdvipdfmx-dpxutil.o xdvipdfmx-dvi.o xdvipdfmx- 
dvipdfmx.o xdvipdfmx-epdf.o xdvipdfmx-error.o xdvipdfmx-fontmap.o  
xdvipdfmx-jpegimage.o xdvipdfmx-mem.o xdvipdfmx-mfileio.o xdvipdfmx- 
mpost.o xdvipdfmx-numbers.o xdvipdfmx-otl_conf.o xdvipdfmx-otl_opt.o  
xdvipdfmx-pdfcolor.o xdvipdfmx-pdfdev.o xdvipdfmx-pdfdoc.o xdvipdfmx- 
pdfdraw.o xdvipdfmx-pdfencoding.o xdvipdfmx-pdfencrypt.o xdvipdfmx- 
pdffont.o xdvipdfmx-pdfnames.o xdvipdfmx-pdfobj.o xdvipdfmx- 
pdfparse.o xdvipdfmx-pdfresource.o xdvipdfmx-pdfximage.o xdvipdfmx- 
pkfont.o xdvipdfmx-pngimage.o xdvipdfmx-pst.o xdvipdfmx-pst_obj.o  
xdvipdfmx-sfnt.o xdvipdfmx-spc_color.o xdvipdfmx-spc_dvips.o  
xdvipdfmx-spc_html.o xdvipdfmx-spc_misc.o xdvipdfmx-spc_pdfm.o  
xdvipdfmx-spc_tpic.o xdvipdfmx-spc_util.o xdvipdfmx-spc_xtx.o  
xdvipdfmx-specials.o xdvipdfmx-subfont.o xdvipdfmx-tfm.o xdvipdfmx- 
tt_aux.o xdvipdfmx-tt_cmap.o xdvipdfmx-tt_glyf.o xdvipdfmx-tt_gsub.o  
xdvipdfmx-tt_post.o xdvipdfmx-tt_table.o xdvipdfmx-truetype.o  
xdvipdfmx-type0.o xdvipdfmx-t1_char.o xdvipdfmx-t1_load.o xdvipdfmx- 
type1.o xdvipdfmx-type1c.o xdvipdfmx-unicode.o xdvipdfmx-vf.o  -lpng - 
lz../../../libs/freetype2/.libs/libfreetype.a -lkpathsea -lm  - 
framework ApplicationServices

This just mentions -lpng, it doesn't make any assumptions about its  
library type or location (which is as I'd expect for --with-system- 
libpng).

It's libtool, then, which is converting -lpng to /usr/local/lib/ 
libpng12.dylib, which you don't have installed. So either it's a bug  
in libtool, or it's a feature that this scenario is not supported.

Either way, I don't expect to fix it at this point. Just don't use -- 
with-system-pnglib on this setup.

JK