[MacPorts] #32511: openjpeg @1.4-r697 openjpeg/ffmpeg/libjasper symbol collision
MacPorts
noreply at macports.org
Sun Dec 11 16:57:52 PST 2011
#32511: openjpeg @1.4-r697 openjpeg/ffmpeg/libjasper symbol collision
-----------------------------------+----------------------------------------
Reporter: marin.saric@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.0.3
Keywords: | Port: openjpeg libjasper
-----------------------------------+----------------------------------------
The purpose of this ticket is to point out a serious issue with OpenJPEG
that can lead to unpredictable crashes and seek feedback and advice.
I volunteer to cherry-pick the simple symbol-mangling patch from the
OpenJPEG trunk and apply it to the stable version of OpenJPEG currently in
MacPorts.
This issue has been discussed and addressed in the OpenJPEG trunk:
http://code.google.com/p/openjpeg/issues/detail?id=30
Background information:
{{{OpenJPEG}}} was designed as an alternative to {{{libjasper}}}, a
library providing the JPEG2000 format functionality.
Ideally, a project will use either {{{OpenJPEG}}} or {{{libjasper}}}.
Some private symbols in OpenJPEG (such as {{{jp2_decode}}}), which are
never called by the library user's code end up colliding with the public
library API symbols of {{{libjasper}}}.
{{{ffmpeg}}} is a popular library that is compiled with {{{OpenJPEG}}}
support in MacPorts.
A program (or, even worse, a {{{dylib}}} plugin) relying on
{{{libjasper}}} can also depend on {{{ffmpeg}}}. Even worse, a program
loading a {{{dylib}}} plugin can have {{{OpenJPEG}}} already loaded,
tripping up a segmentation fault once the plugin loads and the code to
open a JPEG2000 file executes.
A simple fix is to change the name of the offending private functions in
the OpenJPEG code and recompile openjpeg.
--
Ticket URL: <https://trac.macports.org/ticket/32511>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list