#43950: openjpeg build fails on 10.4 with missing symbols -----------------------+-------------------------------- Reporter: nad@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.0 Resolution: | Keywords: Port: openjpeg | -----------------------+-------------------------------- Comment (by ryandesign@…): Replying to [ticket:43950 nad@…]:
Upgrading openjeg (2.0.0_1 < 2.1.0_0) fails on my 10.4.11 PPC system. On 10.4, the port depends on the `apple-gcc42` compiler port.
On 10.4, the default compiler was changed to apple-gcc42 in MacPorts 2.3.0, because the older gcc-4.0 included in Tiger's Xcode has many bugs.
After a quick look, I'm not sure what is going on but one thing looks rather odd: it appears that `ld` may be incorrectly looking for MacPorts- installed library using the SDK root prefix (note, this installation uses a --prefix of `/macports` rather than `/opt/local`).
This is a known bug in /usr/bin/ld on OS X 10.4 that occurs when an SDK is used.
I wonder whether the addition of `-isystem` in r115051 is causing problems.
That's unrelated. The problem is the `-isysroot` argument. openjpeg uses cmake, so I would say the change to the cmake 1.0 portgroup in r119436 probably caused this issue to occur more frequently. Previously, MacPorts would only use an SDK when building universal on Mac OS X 10.4 on PowerPC systems, which is what you're using; MacPorts would not use an SDK on any other OS X version, nor on Intel systems. After this change to the cmake portgroup, an SDK is always used, on all systems, when the cmake portgroup is used. I have suggested we should always use an SDK, in all cases, not just with the cmake portgroup (#41783) but ran into a different problem so that has not yet been done.
{{{ :info:build /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/macports/lib/liblzma.5.dylib referenced from: /macports/lib/libtiff.dylib (checking for undefined symbols may b e affected) (No such file or directory, errno = 2) :info:build /usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/macports/lib/libjpeg.9.dylib referenced from: /macports/lib/libtiff.dylib (checking for undefined symbols may b e affected) (No such file or directory, errno = 2) :info:build /usr/bin/ld: Undefined symbols: :info:build _jpeg_CreateCompress referenced from libtiff expected to be defined in /macports/lib/libjpeg.9.dylib :info:build _jpeg_CreateDecompress referenced from libtiff expected to be defined in /macports/lib/libjpeg.9.dylib ... }}}
Because you have apple-gcc42 installed, you should also already have the ld64 port installed, which should provide a newer ld that does not have the bug that was present in the version that shipped in Tiger. But I am uncertain why the build has nevertheless decided to use /usr/bin/ld and not /opt/local/bin/ld. Replying to [comment:1 nad@…]:
Ahah! Adding a symlink in the SDK to the MacPorts root does seem to solve the build failure. That shouldn't be necessary but that may be an OK workaround.
Yes, that is one of the known workarounds for this problem. -- Ticket URL: <https://trac.macports.org/ticket/43950#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X