Opened 13 years ago
Closed 13 years ago
#32511 closed defect (fixed)
openjpeg @1.4-r697 openjpeg/ffmpeg/libjasper symbol collision
Reported by: | marin.saric@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.0.3 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), jmroot (Joshua Root), dbevans (David B. Evans) | |
Port: | openjpeg jasper ffmpeg |
Description
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.
Change History (4)
comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | mcalhoun@… jmr@… devans@… added; mcalhoun removed |
---|---|
Port: | jasper ffmpeg added; libjasper removed |
comment:2 Changed 13 years ago by jmroot (Joshua Root)
comment:3 Changed 13 years ago by marin.saric@…
I stumbled upon this problem during static linking and didn't even think of Apple's clever two-level namespace scheme. Considering Qt4 binaries are still built with -flat_namespace, I am guessing the problem can resurface..
Also there's no two-level namespace equivalent during static linking.
For example, when trying to link opencv statically you run into this: opencv links against jasper and ffmpeg, ffmpeg links against openjpeg and boom you have duplicate symbols.
However, the symbol collision is an accident. A private function got exported under a common name..
comment:4 Changed 13 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in 1.5.
Out of curiosity, why isn't this issue avoided with a two-level namespace? Or does some of this stuff force a flat namespace?