Re: Fwd: validation test for Puma-linked shared librarieson darwin14 and later

That otool-hv is the same test we first encountered in the original 
transition to two-level namespaces. Was that gcc3.3ish? Quick and easy 
because all we care about is the bit (the detail of the whole library), 
not the detailed symbol-by-symbol analysis. 

dan

On Tue, 28 Oct 2014 22:09:29 -0400, Jack Howarth 
<[email protected]> wrote:

> ---------- Forwarded message ----------
> From: Jack Howarth <[email protected]>
> Date: Tue, Oct 28, 2014 at 10:08 PM
> Subject: Re: [Fink-devel] validation test for Puma-linked shared 
> libraries on darwin14 and later
> To: Alexander Hansen <[email protected]>
>
> Alternatively, the Apple linker developer pointed out, we can use... 
>
> # otool -hv libgdbm.3.0.0.dylib
>  libgdbm.3.0.0.dylib:
>  Mach header
>        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
>  MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    14   
>     1536   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
>
> vs
>
> # otool -hv libgdbm.3.0.0.dylib
>  libgdbm.3.0.0.dylib:
>  Mach header
>        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
>  MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    14   
>     1536 DYLDLINK NO_REEXPORTED_DYLIBS
>
> and look for the presence of TWOLEVEL. 
>
> On Tue, Oct 28, 2014 at 9:38 PM, Jack Howarth 
> <[email protected]> wrote:
>
>       As I mentioned to Alexander on fink irc, it appears that we can use.. 
>
> # /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind 
> .libs/libgdbm.3.0.0.dylib
>  bind information:
>  segment section          address        type    addend 
> dylib            symbol
>  __DATA  __got            0x00004000    pointer      0 
> libSystem        ___stack_chk_guard
>  __DATA  __nl_symbol_ptr  0x00004008    pointer      0 
> libSystem        dyld_stub_binder
>
> vs
>
> # /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind 
> .libs/libgdbm.3.0.0.dylib | grep flat
>  __DATA  __got            0x00004000    pointer      0 
> flat-namespace   ___stack_chk_guard
>  __DATA  __got            0x00004008    pointer      0 
> flat-namespace   _gdbm_errno
>  __DATA  __nl_symbol_ptr  0x00004010    pointer      0 
> flat-namespace   dyld_stub_binder
>
> and just grep the output for flat-namespace. 
>               Jack
>
> On Tue, Oct 28, 2014 at 9:14 PM, Alexander Hansen 
> <[email protected]> wrote:
>
>       On 10/28/14, 6:05 PM, Jack Howarth wrote:
>
>              As I mentioned to Alexander on fink irc, I think we can add a
> fatal fink validation error for the dynamic shared libraries on darwin14
> and later that are erroneously linked with -flat_namespace rather than
> -undefined dynamic_lookup due to the buggy libtool. We can use the
> following approach... 
>
> 1) test with the 'file' command to make sure the shared library isn't
> really a bundle
> 2) if not a bundle, use 'otool -H <filename> | grep Hint' to look for... 
>
> Two-level namespace hints table (0 hints)
>
> which shared libraries created with -flat_namespace should be missing. 
>
> If this test fails on darwin14 or later, this should be treated as a
> fatal validation error with the appropriate error message. 
>
>                 Jack
>
>  The good news is that Validation.pm already has a loop over the 
> installed dylibs in a .deb, excluding bundles, so adding an extra 
> test won't be too difficult. 
>
> The bad news is that my test case (libtcd-shlibs on 10.10 with and 
> without the PatchScript) didn't seem to give different "otool -H " 
> output whether or not -flat_namespace was used. 
> -- Alexander Hansen, Ph.D. 
> Fink User Liaison
> My package updates: http://finkakh.wordpress.com/
>
> -------------------------
>
> ------------------------------------------------------------------------------
>
> -------------------------
>
> _______________________________________________
> Fink-devel mailing list
> [email protected]
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>

  --
Daniel Macks
[email protected]



------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel