Opened 9 years ago
Last modified 9 years ago
#45851 new enhancement
port should scan for DYLIB missing the TWOLEVEL flag
| Reported by: | howarth.at.macports@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | base | Version: | |
| Keywords: | Cc: | larryv (Lawrence Velázquez) | |
| Port: |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
The port packaging scan...
---> Scanning binaries for linking errors
should be enhanced to warn if a non-bundle shared library, identified by the presence of DYLIB on the output of 'otool -hv', is missing the TWOLEVEL flag, indicating that it was linked with -flat_namespace.
Change History (6)
comment:1 Changed 9 years ago by larryv (Lawrence Velázquez)
| Cc: | larryv@… added |
|---|
comment:2 follow-up: 4 Changed 9 years ago by larryv (Lawrence Velázquez)
Is is always safe to assume that this state is an error?
comment:3 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
| Component: | ports → base |
|---|---|
| Description: | modified (diff) |
| Port: | port removed |
| Version: | 2.3.2 |
comment:4 Changed 9 years ago by howarth.at.macports@…
Replying to larryv@…:
Is is always safe to assume that this state is an error?
Yes, this is an indicator that either a broken libtool.m4 was used to generate the configure files...
http://lists.gnu.org/archive/html/libtool-patches/2014-09/msg00002.html
or the software is just erroneously forcing the use of "-flat_namespace" with -dynamiclib which is unconventional and can cause runtime issues...
http://trac.sagemath.org/ticket/17204?cversion=0&cnum_hist=5
The output from 'otool -hv' can be used to detect this flaw...
% otool -hv /opt/local/lib/libfftw3.3.dylib /opt/local/lib/libfftw3.3.dylib: Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 14 1704 NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
where the absence of the "TWOLEVEL" flag in combination with the presence of the "DYLIB" filetype is a marker for the use of -flat_namespace.
Rather than trying to parse out the filetype field, each shared library file can be checked with the 'file' command to verify that it isn't a bundle
and for those non-bundle shared libraries, an warning emitted if the output of 'otool -hv' for that filename doesn't contain "TWOLEVEL".
The fink project has made the same type of shared library test for -flat-namespace a fatal packaging error.
comment:5 Changed 9 years ago by jmroot (Joshua Root)
And yet openmpi, pyqt3, libdv, libpano13 and tagtool use it deliberately. And that’s just the ones that set it in the portfile. Another example: https://lists.macosforge.org/pipermail/macports-dev/2009-February/007366.html
comment:6 Changed 9 years ago by howarth.at.macports@…
The openmpi usage of -flat-namespace seems dubious. Homebrew has the same mumps package and they seem to build it without resorting to hacking up openmpi like that...
https://github.com/Homebrew/homebrew-science/blob/master/mumps.rb
Cc Me!