Re: [Fink-devel] Handling flat_namespace on 10.10+
What else has flat_namespace in fink? I am only aware of two packages
that absolutely have to be built with flat_namespace. Openmpi and the
libXt shared lib for motif compatibility. Most everything else can be
upgraded and are producing the flat_namespace linkages on 10.10 due to
the broken configure files generated from the old buggy libtool.
On Tue, Apr 28, 2015 at 6:10 PM, TheSin the...@southofheaven.org wrote:
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;
printIf this
package BuildDepends on libtool2, make sure that you use\n;
print
BuildDepends: libtool2 (= 2.4.2-4).\n;
printand use
autoreconf to regenerate the configure script.\n;
printIf the
package doesn't BuildDepend on libtool2, you'll need to\n;
printupdate
its build procedure to avoid passing\n;
print
-Wl,-flat_namespace\n;
printwhen
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 addresstypeaddend dylib
symbol
__DATA __got0x001CC000pointer 0 flat-namespace
_ADIOI_DFLT_ERR_HANDLER
__DATA __got0x001CC008pointer 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB17 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB15 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 1. For something that
end-users never see.
It’d be easier just to get Brendan to whitelist the packages for his
auto builder.
Re: [Fink-devel] Handling flat_namespace on 10.10+
On Tue, 28 Apr 2015 07:52:03 -0700, Alexander Hansen alexanderk.han...@gmail.com wrote: On Apr 21, 2015, at 19:31, Daniel Macks dma...@netspace.org wrote: On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser f...@snaggledworks.com wrote: On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote: Summary: GNU libtool effectively assumed that there would be no 10.10, so a bunch of packages inherited conditional logic that treats 10.10 like 10.1. We’ve been patching against this, and put a .deb validator check for flat_namespace builds. Problem: openmpi apparently requires flat_namespace. Other packages might also need it, too, but I don’t happen to know of any offhand. There are a couple of options to address the problem: 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info and have that turn off the .deb validation check. This seems like a gateway to propagating new fields with very limited usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody, etc) had a significantly wider need. So far BuildFlatNamespace has N=1. Would it make more sense to have a new more general field that can receive a comma separated list of pre-set values, and each value would indicate a action? RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna Could Type: be extended in this manner? 2) Get rid of the .deb validation check and instead apply mandatory tests in the earlier phases. For example, to test at the end of the compile phase fink-package-precedence could be extended also to check for flat_namespace and packages which need flat_namespace wouldn’t use f-p-p; or an additional option flag could be added to f-p-p. We could also check config.status before the compile phase. Would built debs still be validatable (by hand)? If it controls a validator test, it needs to be in the .deb control file, which means we have to tweak dpkg itself to accept a new foreign field. All for an apparently *very* rare special case? No thanks. Support via f-p-p or a new fink-library-check (either one controlled by comand-line flags in the CompileScript) or internal to fink itself prior to rolling the .deb (controllable by some .info field) would make it happen in fink runtime and not require .deb/dpkg hackery. As a bonus, it keeps the buggy-library from ever making it into a .deb for anyone rather than lurking and spreading until someone uses -m to catch it. We already have support for a special token in Shlibs entries to control certain binary library features (32/64-bit cross-arch), so a new Flat token could be added there. I think it's a per-file idea, not per-package? I dislike doing it via grep of config.status...we want to catch bad results regardless of how they came about, not just the one way we currently see. Likewise, fink-library-check would take a list of specific file(s) to allow to be flat, not just enable/disable the whole mode (and would allow scanning .so not just .dylib). There are some other sanity checks we might want to do on modules and libs (unresolved symbols? list of runtime deps?), this new script would be a home for them all. dan -- Daniel Macks dma...@netspace.org Yeah, I’d definitely prefer not to have problematic .debs actually get built. However, since we kind of need to get a release out shortly, and we currently don’t have code in Fink to handle this, I’d like to know whether to turn off the current flat_namespace check in the validator so that openmpi can get added to the binary distribution or just leave it as-is. Knock it down to a non-fatal (remove $looks_good=0)? That way it can be caught by buildworld and maintainers who look closely, but won't prohibit. dan -- Daniel Macks dma...@netspace.org -- 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
On Apr 28, 2015, at 08:41, Jack Howarth howarth.at.f...@gmail.com wrote: Are the checks for the shlibs in Validation.pm done for the files from all packages at once or as sets for each package and/or its split-offs? If the latter, what about the idea of hard-coding a blacklist into Validation.pm of packages and/or split-off which should be skipped? It’s the latter. .info file validation is done as a batch, but the .deb validator works package by package—ideally only the root directories for the package family currently being built would even be available for validation during the build operation. -- 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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 1. 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
--
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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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 1. 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
Since this issue is so rare (only openmpi and libXt require flat_namepace...with the latter being an historical artifact to keep motif working), why not check the package name as they are processed and if it skip the flat_namespace check if the package name matches openmpi-shlibs_*.deb or openmpi_*.deb? Ugly but it will suffice. On Tue, Apr 28, 2015 at 12:20 PM, Alexander Hansen alexanderk.han...@gmail.com wrote: On Apr 28, 2015, at 08:41, Jack Howarth howarth.at.f...@gmail.com wrote: Are the checks for the shlibs in Validation.pm done for the files from all packages at once or as sets for each package and/or its split-offs? If the latter, what about the idea of hard-coding a blacklist into Validation.pm of packages and/or split-off which should be skipped? It’s the latter. .info file validation is done as a batch, but the .deb validator works package by package—ideally only the root directories for the package family currently being built would even be available for validation during the build operation. -- 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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.
On Tue, Apr 28, 2015 at 12:30 PM, Jack Howarth
howarth.at.f...@gmail.com wrote:
Since this issue is so rare (only openmpi and libXt require
flat_namepace...with the latter being an historical artifact to keep
motif working), why not check the package name as they are processed
and if it skip the flat_namespace check if the package name matches
openmpi-shlibs_*.deb or openmpi_*.deb? Ugly but it will suffice.
On Tue, Apr 28, 2015 at 12:20 PM, Alexander Hansen
alexanderk.han...@gmail.com wrote:
On Apr 28, 2015, at 08:41, Jack Howarth howarth.at.f...@gmail.com wrote:
Are the checks for the shlibs in Validation.pm done for the files from
all packages at once or as sets for each package and/or its
split-offs? If the latter, what about the idea of hard-coding a
blacklist into Validation.pm of packages and/or split-off which should
be skipped?
It’s the latter. .info file validation is done as a batch, but the .deb
validator works package by package—ideally only the root directories for the
package family currently being built would even be available for validation
during the build operation.
--
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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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 addresstypeaddend dylibsymbol
__DATA __got0x001CC000pointer 0 flat-namespace
_ADIOI_DFLT_ERR_HANDLER
__DATA __got0x001CC008pointer 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB17 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB15 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 1. 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
Re: [Fink-devel] 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;
printIf this
package BuildDepends on libtool2, make sure that you use\n;
print
BuildDepends: libtool2 (= 2.4.2-4).\n;
printand use
autoreconf to regenerate the configure script.\n;
printIf the
package doesn't BuildDepend on libtool2, you'll need to\n;
printupdate
its build procedure to avoid passing\n;
print
-Wl,-flat_namespace\n;
printwhen
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 addresstypeaddend dylibsymbol
__DATA __got0x001CC000pointer 0 flat-namespace
_ADIOI_DFLT_ERR_HANDLER
__DATA __got0x001CC008pointer 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB17 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB15 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 1. 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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;
printIf this
package BuildDepends on libtool2, make sure that you use\n;
print
BuildDepends: libtool2 (= 2.4.2-4).\n;
printand use
autoreconf to regenerate the configure script.\n;
printIf the
package doesn't BuildDepend on libtool2, you'll need to\n;
printupdate
its build procedure to avoid passing\n;
print
-Wl,-flat_namespace\n;
printwhen
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 addresstypeaddend dylib
symbol
__DATA __got0x001CC000pointer 0 flat-namespace
_ADIOI_DFLT_ERR_HANDLER
__DATA __got0x001CC008pointer 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB17 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 capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL 0x00 DYLIB15 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 1. 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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 1. 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
Re: [Fink-devel] Handling flat_namespace on 10.10+
On Apr 21, 2015, at 19:31, Daniel Macks dma...@netspace.org wrote: On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser f...@snaggledworks.com mailto:f...@snaggledworks.com wrote: On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote: Summary: GNU libtool effectively assumed that there would be no 10.10, so a bunch of packages inherited conditional logic that treats 10.10 like 10.1. We’ve been patching against this, and put a .deb validator check for flat_namespace builds. Problem: openmpi apparently requires flat_namespace. Other packages might also need it, too, but I don’t happen to know of any offhand. There are a couple of options to address the problem: 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info and have that turn off the .deb validation check. This seems like a gateway to propagating new fields with very limited usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody, etc) had a significantly wider need. So far BuildFlatNamespace has N=1. Would it make more sense to have a new more general field that can receive a comma separated list of pre-set values, and each value would indicate a action? RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna Could Type: be extended in this manner? 2) Get rid of the .deb validation check and instead apply mandatory tests in the earlier phases. For example, to test at the end of the compile phase fink-package-precedence could be extended also to check for flat_namespace and packages which need flat_namespace wouldn’t use f-p-p; or an additional option flag could be added to f-p-p. We could also check config.status before the compile phase. Would built debs still be validatable (by hand)? If it controls a validator test, it needs to be in the .deb control file, which means we have to tweak dpkg itself to accept a new foreign field. All for an apparently *very* rare special case? No thanks. Support via f-p-p or a new fink-library-check (either one controlled by comand-line flags in the CompileScript) or internal to fink itself prior to rolling the .deb (controllable by some .info field) would make it happen in fink runtime and not require .deb/dpkg hackery. As a bonus, it keeps the buggy-library from ever making it into a .deb for anyone rather than lurking and spreading until someone uses -m to catch it. We already have support for a special token in Shlibs entries to control certain binary library features (32/64-bit cross-arch), so a new Flat token could be added there. I think it's a per-file idea, not per-package? I dislike doing it via grep of config.status...we want to catch bad results regardless of how they came about, not just the one way we currently see. Likewise, fink-library-check would take a list of specific file(s) to allow to be flat, not just enable/disable the whole mode (and would allow scanning .so not just .dylib). There are some other sanity checks we might want to do on modules and libs (unresolved symbols? list of runtime deps?), this new script would be a home for them all. dan -- Daniel Macks dma...@netspace.org mailto:dma...@netspace.org Yeah, I’d definitely prefer not to have problematic .debs actually get built. However, since we kind of need to get a release out shortly, and we currently don’t have code in Fink to handle this, I’d like to know whether to turn off the current flat_namespace check in the validator so that openmpi can get added to the binary distribution or just leave it as-is. -- 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
