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
