[MacPorts] #64362: pango @1.50.3 fails building on 10.5.8 PPC

[MacPorts]

#64362: pango @1.50.3 fails building on 10.5.8 PPC
-------------------------+---------------------
  Reporter:  udbraumann  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  leopard
      Port:  pango       |
-------------------------+---------------------

Comment (by udbraumann):

 Replying to [comment:6 evanmiller]:
 > Builds fine on 10.4 PPC

 Meanwhile, I have found a way to build `pango @1.50.3_0` on 10.5.8 G4 PPC
 (but still the abovementioned `nm` issue is "alive"):

 Since building finally stopped with linking errors with respect to
 `libX11.a` (see above), and since I noticed that `xorg-libX11` is residing
 as fat binary on my `10.5.8` G4 PPC
 {{{
 $ sudo port installed xorg-libX11
 The following ports are currently installed:
   xorg-libX11 @1.6.9_0+universal
   xorg-libX11 @1.7.3.1_0+universal (active)
 }}}
 I got the idea to build `xorg-libX11 @1.7.3.1_0` without `+universal` (I
 cannot say why my installation has quite a few fat binaries, maybe I was
 experimenting years ago with binaries - not `pango` - that could be used
 on an Intel platform as well):
 {{{
 $ sudo port installed xorg-libX11
 The following ports are currently installed:
   xorg-libX11 @1.6.9_0+universal
   xorg-libX11 @1.7.3.1_0 (active)
   xorg-libX11 @1.7.3.1_0+universal
 }}}

 Interestingly, now `pango @1.50.3_0` builds:

 {{{
 $ sudo port -s build pango
 --->  Computing dependencies for libgcc7
 --->  Cleaning libgcc7
 --->  Computing dependencies for gcc7
 --->  Cleaning gcc7
 --->  Computing dependencies for pango
 --->  Fetching distfiles for pango
 --->  Verifying checksums for pango
 --->  Extracting pango
 --->  Configuring pango
 --->  Building pango
 }}}

 Looking into the log, the linking with the "unfatted" `libX11` works now:
 {{{
 :info:build [61/150] /opt/local/bin/gcc-mp-7  -o
 pango/libpangoxft-1.0.0.dylib pango/libpangoxft-1.0.0.dylib.p/pangoxft-
 font.c.o pango/libpangoxft-1.0.0.dylib.p/pangoxft-fontmap.c.o
 pango/libpangoxft-1.0.0.dylib.p/pangoxft-render.c.o -L/opt/local/lib
 -I/opt/local/include -Wl,-dead_strip_dylibs
 -Wl,-headerpad_max_install_names -Wl,-undefined,error -shared
 -install_name @rpath/libpangoxft-1.0.0.dylib -compatibility_version 5001
 -current_version 5001.3.0 -Wl,-headerpad_max_install_names -arch ppc -pipe
 -Os -Wno-error,-Wimplicit-fallthrough -arch ppc -Wl,-rpath, at loader_path/
 pango/libpango-1.0.0.dylib pango/libpangoft2-1.0.0.dylib -lm
 -L/opt/local/lib -lglib-2.0 -lintl -L/opt/local/lib -lgobject-2.0
 -lglib-2.0 -lintl -L/opt/local/lib -lgio-2.0 -lgobject-2.0 -lglib-2.0
 -lintl -L/opt/local/lib -lfribidi -L/opt/local/lib -lharfbuzz
 -L/opt/local/lib -lfontconfig -lfreetype -L/opt/local/lib -lfreetype
 -L/opt/local/lib -lXrender -lX11 -L/opt/local/lib -lXft -framework
 CoreFoundation -framework ApplicationServices -L/opt/local/lib -lcairo
 -L/opt/local/lib -lharfbuzz-gobject -lharfbuzz -lgobject-2.0 -lglib-2.0
 -lintl
 }}}
 I am adding the main.log of the successful building for completeness. You
 will see the still existing `nm` issue as building step [38/150] as
 initially mentioned.

 As soon as I activate `xorg-libX11 @1.7.3.1_0+universal` again, building
 of `pango @1.50.3_0` fails again as described above in my original post.

 Naive question: do you assume that this peculiar behavior can be related
 to the `nm` issue?

 As there was the question which `nm` is being used, it is clear to me it
 is `/opt/local/bin/nm`. Which MacPorts port is containing it?

 And another naive question: Why do the `nm`s belonging to the various
 `gcc`s are not working, e.g.:

 {{{
 $ gcc-nm-mp-7
 gcc-nm-mp-7: Cannot find plugin 'liblto_plugin.so'
 }}}
 The latter fails also for all other versions (oldest I have is 4.8):
 {{{
 $ gcc-nm-mp-4.8
 gcc-nm-mp-4.8: Cannot find plugin 'liblto_plugin.so'
 }}}

 BTW, the `ar`s are affected as well:
 {{{
 $ gcc-ar-mp-7
 gcc-ar-mp-7: Cannot find plugin 'liblto_plugin.so'
 }}}

 However, this `liblto_plugin.so` issue is far beyond my scope...

 Very last question for today: Why do both `libgcc7` and `gcc7`, in case
 either of them is being used for building, are being explicitly checking
 for dependencies (not only for `pango`, but for all other ports) and the
 do a cleaning:
 {{{
 --->  Computing dependencies for libgcc7
 --->  Cleaning libgcc7
 --->  Computing dependencies for gcc7
 --->  Cleaning gcc7
 }}}
 If e.g. `gcc6` is being applied, this dependency check and cleaning step
 is not reported to me.

-- 
Ticket URL: <https://trac.macports.org/ticket/64362#comment:11>
MacPorts <https://www.macports.org/>
Ports system for macOS