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 <howarth.at.f...@gmail.com> 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 <the...@southofheaven.org> 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 
>>> <alexanderk.han...@gmail.com> wrote:
>>>
>>>
>>>> On Apr 28, 2015, at 09:41, Alexander Hansen <alexanderk.han...@gmail.com> 
>>>> wrote:
>>>>
>>>>
>>>>> On Apr 28, 2015, at 09:36, Jack Howarth <howarth.at.f...@gmail.com> 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
>>> Fink-devel@lists.sourceforge.net
>>> 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
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to