#3042 closed defect (wontfix)
JPEG port causes core-dump
Reported by: | opendarwin@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.0 |
Keywords: | Cc: | ||
Port: |
Description
If the JPEG port is installed on a 10.4 system and one has /opt/local/lib in one's DYLD_LIBRARY_PATH environment variable, then, under at least one circumstance, you can get a core dump.
One such circumstance is to open a .term file from a shell using Terminal. The way to reproduce this is:
- Launch Terminal.
- Create a shell window if one isn't already created.
- From the File menu, select Save As...
- Save the Main Window as a .term file, say bug.term.
- From the shell inside the existing Terminal window, enter: open bug.term.
You'll then get this:
dyld: Symbol not found: cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/
Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /opt/local/lib/libJPEG.dylib
Trace/BPT trap (core dumped)
The reason this happens is because ImageIO uses a version of libJPEG.dylib that's in the directory:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ ImageIO.framework/Versions/A/Resources
However, if /opt/local/lib is in one's DYLD_LIBRARY_PATH, then libjpeg.dylib is found first and it's presumeably a different version that doesn't have the required symbol defined. Note that the two library names differ in capitalization but, on an HFS+ filesystem, case isn't taken into consideration.
Now, I have no idea why opening a .term file should cause ImageIO to be used at all, but it does. :-/
Attachments (1)
Change History (5)
Changed 20 years ago by opendarwin@…
Attachment: | kdump.out.txt.gz added |
---|
comment:1 Changed 20 years ago by toby@…
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This isn't a problem with DarwinPorts. Don't set DYLD_LIBRARY_PATH, and all your troubles will go away.
comment:2 Changed 20 years ago by toby@…
Might also try setting DYLD_FALLBACK_LIBRARY_PATH instead. But seriously, there should be no reason to set either environment variable permanently; normally you'd only use them when launching a single application.
comment:3 Changed 20 years ago by toby@…
But then how can programs in /opt/local/bin what may use libraries installed in /opt/local/lib ever find their libraries? Same for /usr/local/bin and /usr/local/lib.
- Paul
By being linked against them in the first place. DYLD_LIBRARY_PATH is only used to override the previously-used path, and can often lead to disaster.
output of kdump -m1700