#44268: libpixman 0.32.6 failing to upgrade from 0.32.4 -------------------------+-------------------------- Reporter: josephaw@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: libpixman | -------------------------+-------------------------- Changes (by ryandesign@…): * cc: josephaw@… (removed) * owner: macports-tickets@… => ryandesign@… * port: => libpixman Comment: Please attach the main.log file. -- Ticket URL: <https://trac.macports.org/ticket/44268#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X

#44268: libpixman 0.32.6 failing to upgrade from 0.32.4 -------------------------+-------------------------- Reporter: josephaw@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: libpixman | -------------------------+-------------------------- Comment (by ryandesign@…): Thanks. The error in the log is: {{{:info:build pixman-compiler.h:230:6: error: #error "Unknown thread local support for this system. Pixman will not work with multiple threads. Define PIXMAN_NO_TLS to acknowledge and accept this limitation and compile pixman without thread-safety support."}}} I'll look into this. -- Ticket URL: <https://trac.macports.org/ticket/44268#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X

#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

#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 | -------------------------+--------------------------- Comment (by ryandesign@…): Replying to [comment:6 ryandesign@…]:

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.

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