[MacPorts] #43950: openjpeg build fails on 10.4 with missing symbols

[MacPorts]

#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