Re: [Bug-tar] Small bug in tar-1.29

[Jack Howarth]

On Mon, Sep 05, 2016 at 02:19:48PM -0400, Rob Gross wrote:
> Hi, Jack,
> 
> You wrote:
> 
>  > It would be helpful if you confimed what the linkages for gtar
>  > looked like with...
>  >
>  > otool -L /usr/local/Cellar/gnu-tar/1.29/bin/gtar
> 
> $ otool -L /usr/local/bin/gnutar
> /usr/local/bin/gnutar:
>       /usr/local/lib/libintl.8.dylib (compatibility version 10.0.0, current 
> version 10.3.0)
>       /usr/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current 
> version 8.0.0)
>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
> version 1226.10.1)
>       
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 150.0.0, current version 1258.1.0)
>       /Users/gross/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, 
> current version 1.0.0)
> 
>  > and double check that you don't have any headers or libs for
>  > libiconv, gettext, and libintl accidentally installed in /usr/local
>  > (to make sure you aren't ending up with mismatched headers and libs
>  > during the tar build).
> 
> They are all installed in /usr/local.  I'm not using homebrew or any
> similar systems--I install programs manually (metaphorically).
> There's no possibility of conflict, because those are the only copies
> on the system, as far as I know.  I ran "make check" before installing
> each, and no errors were reported.
> 
>  > ps I suspect you will also find that passing --disable-nls to
>  > configure during the tar build will also suppress your problem.
> 
> Correct.  Does that help in any way to narrow down the source of the
> bug?
> 
>  > Also, I suspect that building tar against libiconv without
>  > gettext is poorly tested on OS X.
> 
> gettext is also installed.  I'm not sure why it's not showing up on
> the list above, because it's in /usr/local/lib.  I think that tar is
> calling xgettext instead, based on the references to xgettext in
> Makefile.

Did you run 'make check' on the gettext and libiconv builds for /usr/local
to make sure those libs are completely passing their testsuites? Those are
both 'core' libraries for fink, MacPorts and homebrew. A quick scan of the
build recipes for gettext at...

https://trac.macports.org/browser/trunk/dports/devel/gettext/Portfile
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.9-libcxx/stable/main/finkinfo/base/libgettext8-shlibs.info?revision=1.4&view=markup
https://github.com/Homebrew/homebrew-core/blob/master/Formula/gettext.rb

show that they are all building gettext with the common configure options of...

--with-included-gettext
--with-included-glib
--with-included-libcroco
--with-included-libunistring
--with-included-libxml
--disable-csharp
--without-git
--without-cvs
--without-xz
ac_cv_prog_AWK=/usr/bin/awk
ac_cv_path_GREP=/usr/bin/grep
ac_cv_path_SED=/usr/bin/sed

I don't see a homebrew rb file and the fink/MacPorts builds of don't share 
configure options.

My only suggestion here is to be absolutely sure that you are properly building 
so that both the headers and libraries from /usr/local are being used in the 
each build (to make sure that you aren't mixing headers and libraries from 
different software releases versions by accident). 


> 
> Incidentally, running "gdb" on the latest Mac OS is a pain--Apple
> thought for some reason that it was a security risk.  Running "lldb,"
> the default debugger, told me nothing.--Rob
> 
> --
> Rob Gross                              (617) 552-3758
> Department of Mathematics              http://fmwww.bc.edu/gross/
> Boston College                         address@hidden
> Chestnut Hill, MA 02467-3806