Opened 10 years ago
Last modified 10 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 10 years ago by larryv (Lawrence Velázquez)
| Cc: | larryv@… added |
|---|
comment:2 follow-up: 4 Changed 10 years ago by larryv (Lawrence Velázquez)
Is is always safe to assume that this state is an error?
comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
| Component: | ports → base |
|---|---|
| Description: | modified (diff) |
| Port: | port removed |
| Version: | 2.3.2 |
comment:4 Changed 10 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 10 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 10 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!