Re: Handling flat_namespace on 10.10+

Note that we are using the absence of TWOLEVEL in the otool -hv output
in Validation.pm...

                               if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
                                        <OTOOL>; <OTOOL>; <OTOOL>; #
skip first three lines
                                        unless ( <OTOOL> =~ /TWOLEVEL/ ) {
                                                print "Error:
$dylib_temp appears to have been linked using a flat namespace.\n";
                                                print "       If this
package BuildDepends on libtool2, make sure that you use\n";
                                                print "
BuildDepends: libtool2 (>= 2.4.2-4).\n";
                                                print "       and use
autoreconf to regenerate the configure script.\n";
                                                print "       If the
package doesn't BuildDepend on libtool2, you'll need to\n";
                                                print "       update
its build procedure to avoid passing\n";
                                                print "
-Wl,-flat_namespace\n";
                                                print "       when
linking libraries.\n";
                                                $looks_good = 0;
                                        }
                                        close (OTOOL);
                                }

On Tue, Apr 28, 2015 at 5:12 PM, Jack Howarth <[email protected]> wrote:
> There are a couple of trivial tests for flat_namespace linkage.
>
> %  /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind
> /sw/lib/openmpi/libmpi.1.dylib
> bind information:
> segment section          address        type    addend dylib            symbol
> __DATA  __got            0x001CC000    pointer      0 flat-namespace
> _ADIOI_DFLT_ERR_HANDLER
> __DATA  __got            0x001CC008    pointer      0 flat-namespace
> _ADIOI_Datarep_head
>
> or
>
> % otool -hv /sw/lib/openmpi/libmpi.1.dylib
> /sw/lib/openmpi/libmpi.1.dylib:
> Mach header
>       magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    17       1888
> DYLDLINK NO_REEXPORTED_DYLIBS
>
> where the absence of TWOLEVEL indicates flat_namespace linkage...
>
> % otool -hvi /sw/lib/libfftw3.3.dylib
> /sw/lib/libfftw3.3.dylib:
> Mach header
>       magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1768
> NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
>
> On Tue, Apr 28, 2015 at 1:46 PM, TheSin <[email protected]> wrote:
>> if we upgrade to my PR I think we could use the symbols files in the dpkg info die to find flat libs, I’m not 100% certain as I’d need an example to test, but if flat_namespace creates a symbol it would be possible, it could even be a trigger to process and sort all libs known to use flat_namespace, then just check that.  Either options is pretty easy to do.
>> ---
>> TS
>> http://www.southofheaven.org/
>> Life begins and ends with chaos, live between the chaos!
>>
>>> On Apr 28, 2015, at 11:14 AM, Alexander Hansen <[email protected]> wrote:
>>>
>>>
>>>> On Apr 28, 2015, at 09:41, Alexander Hansen <[email protected]> wrote:
>>>>
>>>>
>>>>> On Apr 28, 2015, at 09:36, Jack Howarth <[email protected]> wrote:
>>>>>
>>>>> Looking at the code, it seem we would have to do this check in sub
>>>>> validate_dpkg_file and use global boolean called
>>>>> skip_flat_namespace_check or such. In validate_dpkg_file, regex check
>>>>> $dpkg_filename against both openmpi-shlibs_*.deb or openmpi_*.deb. If
>>>>> either match, set skip_flat_namespace_check to true
>>>>> and otherwise to false. Then add skip_flat_namespace_check as a
>>>>> conditional in the...
>>>>>
>>>>> if (open (OTOOL, "$otool -hv '$dylib_temp' |")) {
>>>>>
>>>>> state that controls the flat namespace checks on each file.
>>>>>
>>>>
>>>> As Daniel said, adding a new .info field (if that’s what you mean by global boolean) involves adding on another hack to the .deb control field for 2 packages out of more than 10000.  For something that end-users never see.
>>>>
>>>> It’d be easier just to get Brendan to whitelist the packages for his auto builder.
>>>> --
>>>> Alexander Hansen, Ph.D.
>>>> Fink User Liaison
>>>>
>>>
>>> Oh wait, I re-parsed that, so I think I understand better what you’re getting at.  And I don’t think it will work as intended, since I believe $validate_dpkg_file is run only on actual .debs and not on root directories before they get packed.
>>>
>>> In principle we could just check individual dylib’s names against a whitelist of filename patterns and if they match we can skip the flat_namespace check via a ‘next’.
>>>
>>> --
>>> Alexander Hansen, Ph.D.
>>> Fink User Liaison
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> _______________________________________________
>>> 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
>>

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
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