[MacPorts] #42840: cmake issues -bundle instead of -dynamiclib when creating shared modules
MacPorts
noreply at macports.org
Sun Mar 16 08:32:36 PDT 2014
#42840: cmake issues -bundle instead of -dynamiclib when creating shared modules
--------------------------+-------------------
Reporter: rjvbertin@… | Owner: css@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.2.1
Resolution: | Keywords:
Port: cmake |
--------------------------+-------------------
Changes (by ryandesign@…):
* keywords: CMAKE_SHARED_MODULE_CREATE =>
* owner: macports-tickets@… => css@…
Old description:
> This is a follow-up to issue [http://trac.macports.org/ticket/40188]. I
> was bitten by the cmake specificity while building KDE's Calligra suite,
> when the linker refused to link in 'bundle' shared objects (intended to
> act as plugins also) in x86_64 mode. Googling, I came across
> http://www.wireshark.org/lists/wireshark-dev/201009/msg00231.html where
> one reads
>
> "CMake is using -bundle rather than -dylib/-dynamiclib to build the asn1
> plugin, probably so that it'll work even on versions of OS X where you
> can't dynamically load an MH_DYLIB."
>
> AFAIK, that's a moot point since OS X 10.3 (or at least 10.4). I cannot
> decide whether a modification of the corresponding cmake formulas is
> something MacPorts can do during an installation, but it is possible.
> Finding all CMAKE_SHARED_MODULE_CREATE definitions in
> /opt/local/lib/cmake{,-2.8} and replacing -bundle with -dynamiclib
> resolves the linking problem I encountered.
New description:
This is a follow-up to issue #40188. I was bitten by the cmake specificity
while building KDE's Calligra suite, when the linker refused to link in
'bundle' shared objects (intended to act as plugins also) in x86_64 mode.
Googling, I came across
http://www.wireshark.org/lists/wireshark-dev/201009/msg00231.html where
one reads
"CMake is using -bundle rather than -dylib/-dynamiclib to build the asn1
plugin, probably so that it'll work even on versions of OS X where you
can't dynamically load an MH_DYLIB."
AFAIK, that's a moot point since OS X 10.3 (or at least 10.4). I cannot
decide whether a modification of the corresponding cmake formulas is
something MacPorts can do during an installation, but it is possible.
Finding all CMAKE_SHARED_MODULE_CREATE definitions in
/opt/local/lib/cmake{,-2.8} and replacing -bundle with -dynamiclib
resolves the linking problem I encountered.
--
Comment:
Is there an upstream bug report for this problem?
--
Ticket URL: <https://trac.macports.org/ticket/42840#comment:2>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list