libpixman: Unknown thread local support for this system

[josephaw@…]

sudo port clean libpixman 
--> Cleaning libpixman

sudo port upgrade libpixman
--->  Computing dependencies for libpixman
--->  Fetching archive for libpixman
--->  Attempting to fetch libpixman-0.32.6_0.darwin_8.ppc.tbz2 from http://packages.macports.org/libpixman
--->  Attempting to fetch libpixman-0.32.6_0.darwin_8.ppc.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libpixman
--->  Attempting to fetch libpixman-0.32.6_0.darwin_8.ppc.tbz2 from http://lil.fr.packages.macports.org/libpixman
--->  Fetching distfiles for libpixman
--->  Verifying checksums for libpixman
--->  Extracting libpixman
--->  Configuring libpixman
--->  Building libpixman
Error: org.macports.build for port libpixman returned: command execution failed
Please see the log file for port libpixman for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_libpixman/libpixman/main.log
Error: Unable to upgrade port: 1
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

System: OS X 10.4.11 G4 Desktop

[josephaw@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Please attach the main.log file.

[josephaw@…]

Replying to ryandesign@…:

Please attach the main.log file.

Log Attached

[ryandesign (Ryan Carsten Schmidt)]

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.

[ryandesign (Ryan Carsten Schmidt)]

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.

[josephaw@…]

Thanks for the update, was able to install libpixman now.

[ryandesign (Ryan Carsten Schmidt)]

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