openjpeg build fails on 10.4 with missing symbols

[ned-deily (Ned Deily)]

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

[ned-deily (Ned Deily)]

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

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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 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.

[ned-deily (Ned Deily)]

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.

[ryandesign (Ryan Carsten Schmidt)]

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.