yeah I tried to build something with flat_namespace today just so I could see
the symbols file but the validator wouldn’t pass, I guess I could have turned
off -m though ;) I’ll try again since I just thought of that now.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!
> On Apr 28, 2015, at 3:15 PM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
> 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
