[MacPorts] #43950: openjpeg build fails on 10.4 with missing symbols
#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 Keywords: | Port: openjpeg --------------------+-------------------------------- 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. 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`). I wonder whether the addition of `-isystem` in r115051 is causing problems. {{{ :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 ... }}} For example, those first two symbols do appear to exist in the MacPorts- installed libjpeg: {{{ $ nm /macports/lib/libjpeg.9.dylib | grep Create 000011ac T _jpeg_CreateCompress 0000d2e8 T _jpeg_CreateDecompress }}} -- Ticket URL: <https://trac.macports.org/ticket/43950> MacPorts <http://www.macports.org/> Ports system for OS X
#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 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. {{{ sudo sh cd /Developer/SDKs/MacOSX10.4u.sdk/ umask 022 ln -s /macports macports }}} -- Ticket URL: <https://trac.macports.org/ticket/43950#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#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
#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 nad@…):
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.
Yes, I was aware of that.
The problem is the -isysroot argument. [...]
That makes more sense. I didn't recall that there were issues when using an SDK. Ages ago I believe I used to have it set in `macports.conf` for some releases. I agree that there is something to be said for always using a SDK, particularly if it can avoid edge cases.
Because you have apple-gcc42 installed, you should also already have the ld64 port installed [...]
Yes, I see I should but, for some reason, I didn't. I can't explain why it's missing: the dependencies are clear. After installing `ld64` and its dependencies and after removing the symlink workaround, I was able to successfully build `openjpeg`. Sorry for the noise and thanks for the detailed reply. -- Ticket URL: <https://trac.macports.org/ticket/43950#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#43950: openjpeg build fails on 10.4 with missing symbols -----------------------+-------------------------------- Reporter: nad@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.0 Resolution: invalid | Keywords: Port: openjpeg | -----------------------+-------------------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => invalid Comment: Ok great, I'm glad the fix was so simple. Perhaps you forced ld64 to uninstall at some point. Since the dependencies are already correct, I'll close the ticket. -- Ticket URL: <https://trac.macports.org/ticket/43950#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts