Opened 7 years ago

Last modified 6 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 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 7 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:2 in reply to:  description ; Changed 7 years ago by larryv (Lawrence Velázquez)

Is is always safe to assume that this state is an error?

comment:3 Changed 7 years ago by ryandesign (Ryan Schmidt)

Component: portsbase
Description: modified (diff)
Port: port removed
Version: 2.3.2

comment:4 in reply to:  2 Changed 7 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 6 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 6 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

Note: See TracTickets for help on using tickets.