[MacPorts] #44268: libpixman: Unknown thread local support for this system (was: libpixman 0.32.6 failing to upgrade from 0.32.4)

[MacPorts]

#44268: libpixman: Unknown thread local support for this system
-------------------------+---------------------------
  Reporter:  josephaw@…  |      Owner:  ryandesign@…
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.3.1
Resolution:  fixed       |   Keywords:  powerpc tiger
      Port:  libpixman   |
-------------------------+---------------------------
Changes (by ryandesign@…):

 * keywords:  powerpc => powerpc tiger
 * status:  new => closed
 * resolution:   => fixed


Comment:

 This is not a change in libpixman 0.32.6; you'll see the same if you try
 to rebuild 0.32.4. The change is one that was made in MacPorts 2.3.0: I
 changed the default compiler for Tiger from Xcode's gcc-4.0 to MacPorts'
 apple-gcc-4.2, to avoid bugs in gcc-4.0 (#41782, r115646).

 Under gcc-4.0, libpixman's configure script will detect pthread support
 and be happy:

 {{{
 :info:configure checking for thread local storage (TLS) support... none
 :info:configure checking for pthreads... yes
 }}}

 Under apple-gcc-4.2, it won't detect pthread, and the build will later
 fail because it doesn't have any thread support.

 {{{
 :info:configure checking for thread local storage (TLS) support... none
 :info:configure checking for pthreads... no
 }}}

 In r123600 I blacklisted apple-gcc-4.2 for libpixman (and libpixman-devel)
 on Tiger ppc (since that's the only platform affected by this issue) which
 sets things back the way they were in MacPorts 2.2.1 and earlier and at
 least allows the port to build on Tiger ppc again.

 Looking at the config.log files is quite interesting. For gcc-4.0 we see
 this:

 {{{
 configure:14112: checking for pthreads
 configure:14162: /usr/bin/gcc-4.0 -o conftest -pipe -Os -arch ppc -Wall
 -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden
 -pthread -I/Volumes/Data/macports/tiger/include
 -L/Volumes/Data/macports/tiger/lib -Wl,-headerpad_max_install_names -arch
 ppc -pthread conftest.c   >&5
 powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
 powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
 configure:14162: $? = 0
 configure:14237: /usr/bin/gcc-4.0 -o conftest -pipe -Os -arch ppc -Wall
 -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden
 -D_REENTRANT -I/Volumes/Data/macports/tiger/include
 -L/Volumes/Data/macports/tiger/lib -Wl,-headerpad_max_install_names -arch
 ppc  conftest.c  -lpthread >&5
 configure:14237: $? = 0
 configure:14350: result: yes
 }}}

 This looks to me as though the configure script is trying various ways of
 ascertaining pthread support. First it tries with the `-pthread` flag,
 which causes something to be printed to stderr, as a result of which the
 configure script decides that's not going to work and tries a different
 way, using the `-D_REENTRANT` flag. This produces no error output, so it
 files that away as the correct way to get pthread support.

 With apple-gcc-4.2 we see something different:

 {{{
 configure:14112: checking for pthreads
 configure:14162: /Volumes/Data/macports/tiger/bin/gcc-apple-4.2 -o
 conftest -pipe -Os -arch ppc -pthread
 -I/Volumes/Data/macports/tiger/include -L/Volumes/Data/macports/tiger/lib
 -Wl,-headerpad_max_install_names -arch ppc -pthread conftest.c   >&5
 ld: warning: object file compiled with -mlong-branch which is no longer
 needed. To remove this warning, recompile without -mlong-branch:
 /usr/lib/crt1.o
 configure:14162: $? = 0
 configure:14237: /Volumes/Data/macports/tiger/bin/gcc-apple-4.2 -o
 conftest -pipe -Os -arch ppc -D_REENTRANT
 -I/Volumes/Data/macports/tiger/include -L/Volumes/Data/macports/tiger/lib
 -Wl,-headerpad_max_install_names -arch ppc  conftest.c  -lpthread >&5
 ld: warning: object file compiled with -mlong-branch which is no longer
 needed. To remove this warning, recompile without -mlong-branch:
 /usr/lib/crt1.o
 configure:14237: $? = 0
 configure:14312: /Volumes/Data/macports/tiger/bin/gcc-apple-4.2 -o
 conftest -pipe -Os -arch ppc -D_REENTRANT
 -I/Volumes/Data/macports/tiger/include -L/Volumes/Data/macports/tiger/lib
 -Wl,-headerpad_max_install_names -arch ppc -lroot conftest.c   >&5
 ld: library not found for -lroot
 collect2: ld returned 1 exit status
 configure:14312: $? = 1
 configure: failed program was:
 | /* confdefs.h */
 | [snip]
 configure:14350: result: no
 }}}

 `-pthread` is no longer an unrecognized option, but we have a new warning:
 a complaint about the way the system library /usr/lib/crt1.o was compiled.
 That's part of the OS so we can't do much about that, but the configure
 script doesn't know that, and takes this stderr output to mean that
 `-pthread` doesn't work, and moves on to `-D_REENTRANT`, which issues the
 same warning, which causes that to fail as well. The third and final
 attempt using `-D_REENTRANT` and `-lroot` fails because there is no "root"
 library, so thread support is now assumed to not exist, and the build
 fails later.

 It's also interesting to note that with apple-gcc-4.2, configure also
 assumes `-Werror` cannot be used, again because of the unexpected stderr
 output. Who knows how many other configure scripts are making wrong
 decisions as a result of this compiler warning. I will ask the maintainer
 of the apple-gcc-4.2 port if there is a way that we can get it to not
 print that warning, at least for system libraries which aren't going to
 get changed at this point.

-- 
Ticket URL: <https://trac.macports.org/ticket/44268#comment:6>
MacPorts <http://www.macports.org/>
Ports system for OS X