defect: boost @1.56.0_1+no_single+no_static+python27+gcc48 won't build on PPC Tiger (Mac OS X 10.4.11)

[ballapete (Peter "Pete" Dyballa)]

Gtk-doc has a dependency of source-highlight which depends on boost. Boost has these variants:

   clang30: Build using the MacPorts clang 3.0 compiler
     * conflicts with clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   clang31: Build using the MacPorts clang 3.1 compiler
     * conflicts with clang30 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   clang32: Build using the MacPorts clang 3.2 compiler
     * conflicts with clang30 clang31 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   clang33: Build using the MacPorts clang 3.3 compiler
     * conflicts with clang30 clang31 clang32 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   clang34: Build using the MacPorts clang 3.4 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   clang35: Build using the MacPorts clang 3.5 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   debug: Builds debug versions of the libraries as well
   dragonegg30: Build using the MacPorts dragonegg 3.0 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   dragonegg31: Build using the MacPorts dragonegg 3.1 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   dragonegg32: Build using the MacPorts dragonegg 3.2 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   dragonegg33: Build using the MacPorts dragonegg 3.3 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   dragonegg34: Build using the MacPorts dragonegg 3.4 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   g95: Build using the Fortran compiler from g95 compiler
     * conflicts with dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   gcc44: Build using the MacPorts gcc 4.4 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   gcc45: Build using the MacPorts gcc 4.5 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc46 gcc47 gcc48 gcc49 gfortran llvm
   gcc46: Build using the MacPorts gcc 4.6 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc47 gcc48 gcc49 gfortran llvm
   gcc47: Build using the MacPorts gcc 4.7 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc48 gcc49 gfortran llvm
   gcc48: Build using the MacPorts gcc 4.8 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc49 gfortran llvm
   gcc49: Build using the MacPorts gcc 4.9 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gfortran llvm
   gfortran: Build using the Fortran compiler from gcc48 compiler
     * conflicts with dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 llvm
   llvm: Build using the Apple native llvm-gcc 4.2 compiler
     * conflicts with clang30 clang31 clang32 clang33 clang34 clang35 dragonegg30 dragonegg31 dragonegg32 dragonegg33 dragonegg34 g95 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gfortran
   mpich: Build using the MPICH Compiler compiler
     * conflicts with mpich_devel openmpi openmpi_devel
   mpich_devel: Build using the MPICH-devel Compiler compiler
     * conflicts with mpich openmpi openmpi_devel
[+]no_single: Disable building single-threaded libraries
[+]no_static: Disable building static libraries
   openmpi: Build using the OpenMPI Compiler compiler
     * conflicts with mpich mpich_devel openmpi_devel
   openmpi_devel: Build using the OpenMPI-devel Compiler compiler
     * conflicts with mpich mpich_devel openmpi
   python25: Build Boost.Python for Python 2.5
     * conflicts with debug python26 python27 python31 python32 python33 python34
   python26: Build Boost.Python for Python 2.6
     * conflicts with debug python25 python27 python31 python32 python33 python34
[+]python27: Build Boost.Python for Python 2.7
     * conflicts with debug python25 python26 python31 python32 python33 python34
   python31: Build Boost.Python for Python 3.1
     * conflicts with debug python25 python26 python27 python32 python33 python34
   python32: Build Boost.Python for Python 3.2
     * conflicts with debug python25 python26 python27 python31 python33 python34
   python33: Build Boost.Python for Python 3.3
     * conflicts with debug python25 python26 python27 python31 python32 python34
   python34: Build Boost.Python for Python 3.4
     * conflicts with debug python25 python26 python27 python31 python32 python33
   regex_match_extra: Enable access to extended capture information of submatches in Boost.Regex
   universal: Build for multiple architectures

but it does not build using GCC 4.8:

DEBUG: compiler clang blacklisted because it's not installed or it doesn't work
DEBUG: Reading variant descriptions from /opt/mports/trunk/dports/_resources/port1.0/variant_descriptions.conf
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Executing variant gcc48 provides gcc48
DEBUG: Executing variant python27 provides python27
DEBUG: Executing variant no_static provides no_static
DEBUG: Executing variant no_single provides no_single
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Chosen compiler macports-clang-3.3 is provided by a port, adding dependency
DEBUG: Adding depends_build port:clang-3.3
DEBUG: Adding depends_skip_archcheck clang-3.3
DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: changing euid/egid - current euid: 0 - current egid: 0
...
--->  Fetching archive for llvm-3.3
DEBUG: Executing org.macports.archivefetch (llvm-3.3)
DEBUG: euid/egid changed to: 0/0
DEBUG: chowned /opt/local/var/macports/incoming to macports
DEBUG: euid/egid changed to: 506/502
--->  llvm-3.3-3.3_4.darwin_8.ppc.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
--->  Attempting to fetch llvm-3.3-3.3_4.darwin_8.ppc.tbz2 from http://nue.de.packages.macports.org/macports/packages/llvm-3.3
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
DEBUG: Fetching archive failed:: The requested URL returned error: 404
--->  Attempting to fetch llvm-3.3-3.3_4.darwin_8.ppc.tbz2 from http://lil.fr.packages.macports.org/llvm-3.3
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
DEBUG: Fetching archive failed:: The requested URL returned error: 404
--->  Attempting to fetch llvm-3.3-3.3_4.darwin_8.ppc.tbz2 from http://packages.macports.org/llvm-3.3
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
DEBUG: Fetching archive failed:: The requested URL returned error: 404
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: fetch phase started at Mon Sep  8 22:28:45 CEST 2014
--->  Fetching distfiles for llvm-3.3
DEBUG: Executing org.macports.fetch (llvm-3.3)
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: checksum phase started at Mon Sep  8 22:28:45 CEST 2014
--->  Verifying checksums for llvm-3.3
DEBUG: Executing org.macports.checksum (llvm-3.3)
--->  Checksumming llvm-3.3.src.tar.gz
DEBUG: Calculated (rmd160) is 22878ad746c50b02a7ac8713dd6f8c95c7af4220
DEBUG: Correct (rmd160) checksum for llvm-3.3.src.tar.gz
DEBUG: Calculated (sha256) is 68766b1e70d05a25e2f502e997a3cb3937187a3296595cf6e0977d5cd6727578
DEBUG: Correct (sha256) checksum for llvm-3.3.src.tar.gz
DEBUG: Privilege de-escalation not attempted as not running as root.
DEBUG: extract phase started at Mon Sep  8 22:28:47 CEST 2014
--->  Extracting llvm-3.3
DEBUG: Executing org.macports.extract (llvm-3.3)
--->  Extracting llvm-3.3.src.tar.gz
DEBUG: setting option extract.args to '/opt/local/var/macports/distfiles/llvm/llvm-3.3.src.tar.gz'
DEBUG: Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_mports_trunk_dports_lang_llvm-3.3/llvm-3.3/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.4'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_lang_llvm-3.3/llvm-3.3/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/llvm/llvm-3.3.src.tar.gz' | /usr/bin/gnutar --no-same-owner -xf -'
DEBUG: Executing command line:  cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_lang_llvm-3.3/llvm-3.3/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/llvm/llvm-3.3.src.tar.gz' | /usr/bin/gnutar --no-same-owner -xf - 

Compilation exited abnormally with code 1 at Mon Sep  8 22:28:51

Obviously the Portfile is faulty.

[ballapete (Peter "Pete" Dyballa)]

main.log

[ryandesign (Ryan Carsten Schmidt)]

The transcript above doesn't show a build failure, but somehow an extract failure of the llvm-3.3 port. I have not seen messages of the form "Compilation exited abnormally with code 1 at Mon Sep 8 22:28:51" before, but a quick Google suggests this is produced by emacs. Are you using emacs to run MacPorts? Try running MacPorts directly from bash instead.

I'm not sure if llvm-3.3 is expected to be able to build on PowerPC at this point. I'm not sure why llvm-3.3 is being used here either, but I suspect it's because you have the cctools port and/or the ld64 port installed with the +llvm33 variant? If so, you could avoid the sometimes problematic llvm dependency and its lengthy compilation time by reinstalling the cctools and ld64 ports without any llvm variant.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

The transcript above doesn't show a build failure, but somehow an extract failure of the llvm-3.3 port.

No, no! You see me aborting after I saw that port is again going to build llvm-3.3. So that's quite OK.

Are you using emacs to run MacPorts?

Yes, of course! There is nothing more useful and handy.

Try running MacPorts directly from bash instead.

After death I'll try contemplating this…

I'm not sure if llvm-3.3 is expected to be able to build on PowerPC at this point. I'm not sure why llvm-3.3 is being used here either, but I suspect it's because you have the cctools port and/or the ld64 port installed with the +llvm33 variant?

No, that's obviously not the case:

port installed | egrep 'cctool|ld'
  cctools @806_3+llvm29 (active)
  cctools-headers @855_0 (active)
  dyld-headers @239.3_0 (active)
  ld64 @97.17_3 (active)
  openldap @2.4.39_0 (active)

But ld64 looks suspicious, doesn't it?

If so, you could avoid the sometimes problematic llvm dependency and its lengthy compilation time by reinstalling the cctools and ld64 ports without any llvm variant.

To me it looks as if I have to choose one variant, so I'll try to build ld64 +llvm29 (and after checking whether any port depends on some particular LLVM version I'll try to upgrade cctools and ld64 to that version. At least I could build:

  llvm-2.9 @2.9_14 (active)
  llvm-3.0 @3.0_13 (active)
  llvm-3.1 @3.1_8 (active)
  llvm-3.2 @3.2_3 (active)

[ballapete (Peter "Pete" Dyballa)]

DEBUG: Chosen compiler macports-clang-3.3 is provided by a port, adding dependency
DEBUG: Adding depends_build port:clang-3.3
DEBUG: Adding depends_skip_archcheck clang-3.3
DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies

After ld64 +llvm29 was installed, port again was willing to build llvm33 – probably in order to get this Clang compiler. I am now trying to build clang-2.9 and select this version as active Clang compiler for MacPorts. Hopefully this brings me a step further!

[neverpanic (Clemens Lang)]

On a (probably) unrelated note, running MacPorts from within emacs may cause problems with the progress bar code and lead to fetch failures – in some situations MacPorts cannot detect the terminal size when started in emacs.

Whether you select a compiler or not doesn't make a difference for any port. If it did, that would be a bug.

The debug output shows that the gcc48 variant did run, and it also shows that MacPorts chose the clang-3.3 compiler for boost. Installing llvm-3.3 is the obvious consequence, trying to install a different llvm won't help here – the problem is the compiler choice of the boost port. You were right in assuming the boost Portfile is to blame.

[neverpanic (Clemens Lang)]

The compiler variants come from the mpi portgroup (which loads the compilers portgroup) and mpi.setup (which calls compilers.setup). The compilers portgroup however doesn't change configure.compiler (which would avoid the problem at hand), but directly modifies configure.{cc,cxx,...} and leaves configure.compiler at the default.

This causes MacPorts to attempt to find a compiler itself, which causes this problem, because the fallback list contains clang-3.3.

[ballapete (Peter "Pete" Dyballa)]

Replying to cal@…:

On a (probably) unrelated note, running MacPorts from within emacs may cause problems with the progress bar code and lead to fetch failures – in some situations MacPorts cannot detect the terminal size when started in emacs.

I am an old European citizen, I see for some seconds ghostly shadows dancing on an invisible line… Maybe it's useful to add a MacPorts option to switch off that gimmick in areas with good (to European standards) Internet bandwidth.

Whether you select a compiler or not doesn't make a difference for any port. If it did, that would be a bug.

What is then the purpose of packages like gcc_select, llvm_select, clang_select?

[ryandesign (Ryan Carsten Schmidt)]

Replying to Peter_Dyballa@…:

Replying to ryandesign@…:

The transcript above doesn't show a build failure, but somehow an extract failure of the llvm-3.3 port.

No, no! You see me aborting after I saw that port is again going to build llvm-3.3. So that's quite OK.

Oh, ok, I didn't realize that.

I'm not sure if llvm-3.3 is expected to be able to build on PowerPC at this point. I'm not sure why llvm-3.3 is being used here either, but I suspect it's because you have the cctools port and/or the ld64 port installed with the +llvm33 variant?

No, that's obviously not the case:

port installed | egrep 'cctool|ld'
  cctools @806_3+llvm29 (active)
  cctools-headers @855_0 (active)
  dyld-headers @239.3_0 (active)
  ld64 @97.17_3 (active)
  openldap @2.4.39_0 (active)

But ld64 looks suspicious, doesn't it?

It doesn't look suspicious to me. I've checked on my PowerPC Tiger machine now, and it has the same installed.

If so, you could avoid the sometimes problematic llvm dependency and its lengthy compilation time by reinstalling the cctools and ld64 ports without any llvm variant.

To me it looks as if I have to choose one variant, so I'll try to build ld64 +llvm29 (and after checking whether any port depends on some particular LLVM version I'll try to upgrade cctools and ld64 to that version. At least I could build:

  llvm-2.9 @2.9_14 (active)
  llvm-3.0 @3.0_13 (active)
  llvm-3.1 @3.1_8 (active)
  llvm-3.2 @3.2_3 (active)

On Intel machines running OS X 10.5 or later, you must select one of the llvm variants. On PowerPC machines running any OS X version or on Intel machines running OS X 10.4 it is permitted to not select any of them. But that was already the case for you.

Replying to cal@…:

The debug output shows that the gcc48 variant did run, and it also shows that MacPorts chose the clang-3.3 compiler for boost. Installing llvm-3.3 is the obvious consequence, trying to install a different llvm won't help here – the problem is the compiler choice of the boost port. You were right in assuming the boost Portfile is to blame.

Right, I just realized that as well. And llvm-3.3 doesn't build on PowerPC; I found the ticket: #39849. It was closed as not to be fixed. So it seems there is no compiler in existence that can build the current version of boost on a PowerPC Mac.

Replying to Peter_Dyballa@…:

What is then the purpose of packages like gcc_select, llvm_select, clang_select?

To assist you in more easily compiling your own software outside of MacPorts. MacPorts itself is not supposed to take any notice of what you select (although some ports still erroneously do, and need to be fixed not to do that).

[neverpanic (Clemens Lang)]

Replying to ryandesign@…:

The debug output shows that the gcc48 variant did run, and it also shows that MacPorts chose the clang-3.3 compiler for boost. Installing llvm-3.3 is the obvious consequence, trying to install a different llvm won't help here – the problem is the compiler choice of the boost port. You were right in assuming the boost Portfile is to blame.

Right, I just realized that as well. And llvm-3.3 doesn't build on PowerPC; I found the ticket: #39849. It was closed as not to be fixed. So it seems there is no compiler in existence that can build the current version of boost on a PowerPC Mac.

I think GCC would work just fine. The problem is that the compilers-1.0 PortGroup which provides the GCC variants doesn't set configure.compiler, but it should. If MacPorts would not default to selecting a suitable compiler automatically, the build would work, because configure.cc, configure.cxx, etc. are properly set. The problem is that configure.compiler is being left at its default value, triggering auto-selection of compilers.

[ryandesign (Ryan Carsten Schmidt)]

I was able to build clang 2.9, 3.0 and 3.2 on Tiger PowerPC. The port blacklists clang 2.9 and 3.0. So using 3.2 might work. On Tiger Intel, I was only able to build clang 2.9 and 3.0, but fortunately Intel users don't have much reason to stay on Tiger.

It might be nice if on older versions of OS X MacPorts base would not include in the compiler fallback list compilers that cannot be compiled.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[seanfarley (Sean Farley)]

Replying to cal@…:

Replying to ryandesign@…:

The debug output shows that the gcc48 variant did run, and it also shows that MacPorts chose the clang-3.3 compiler for boost. Installing llvm-3.3 is the obvious consequence, trying to install a different llvm won't help here – the problem is the compiler choice of the boost port. You were right in assuming the boost Portfile is to blame.

Right, I just realized that as well. And llvm-3.3 doesn't build on PowerPC; I found the ticket: #39849. It was closed as not to be fixed. So it seems there is no compiler in existence that can build the current version of boost on a PowerPC Mac.

I think GCC would work just fine. The problem is that the compilers-1.0 PortGroup which provides the GCC variants doesn't set configure.compiler, but it should. If MacPorts would not default to selecting a suitable compiler automatically, the build would work, because configure.cc, configure.cxx, etc. are properly set. The problem is that configure.compiler is being left at its default value, triggering auto-selection of compilers.

Yes, you are correct about how the compilers portgroup behaves currently. I pretty much neglect configure.compiler since the compilers portgroup is trying to achieve a similar effect via a different way. I'm open to suggestions about changing the behavior, though. Thoughts?

[neverpanic (Clemens Lang)]

Replying to sean@…:

Yes, you are correct about how the compilers portgroup behaves currently. I pretty much neglect configure.compiler since the compilers portgroup is trying to achieve a similar effect via a different way. I'm open to suggestions about changing the behavior, though. Thoughts?

You could just set it to *any* value to avoid the auto-config. Or, you could keep a list options currently supported in base and use those if available. Or, you could somehow dynamically determine the list of compilers supported by base (which would be future-proof, wouldn't get out of date and would work nicely with trunk).

[seanfarley (Sean Farley)]

Replying to cal@…:

Replying to sean@…:

Yes, you are correct about how the compilers portgroup behaves currently. I pretty much neglect configure.compiler since the compilers portgroup is trying to achieve a similar effect via a different way. I'm open to suggestions about changing the behavior, though. Thoughts?

You could just set it to *any* value to avoid the auto-config. Or, you could keep a list options currently supported in base and use those if available. Or, you could somehow dynamically determine the list of compilers supported by base (which would be future-proof, wouldn't get out of date and would work nicely with trunk).

Fair enough. I would like more integration with configure.compiler but am unfortunately low on time now. Feel free to tackle this :-)

[Schamschula (Marius Schamschula)]

I just ran into a similar problem trying to build boost on a G5 iMac running 10.5.8:

MacPorts wants to force me to use mp-clang-3.4, which cannot be built (at least not out of the box). I built mp-clang-3.3, but boost refuses to take the +clang33 variant.

[Schamschula (Marius Schamschula)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

What do you mean exactly, "refuses to take the +clang33 variant"?

[Schamschula (Marius Schamschula)]

Replying to ryandesign@…:

What do you mean exactly, "refuses to take the +clang33 variant"?

When I do port variants boost I see a series of mutually exclusive compiler options. As the build defaults to clang-3.4, which cannot be built, I tried to choose clang-3.3 which can be built. However, the boost compiler blacklist causes my choice of variant, i.e. +clang33, to be ignored. The only options I see is to use configure.compiler or to define default compilers.

[ballapete (Peter "Pete" Dyballa)]

Replying to mschamschula@…:

I just ran into a similar problem trying to build boost on a G5 iMac running 10.5.8:

I am seeing a similar effect on a G4 based Leopard, 10.5.8. Asking port to

install boost +clang33 +no_single +no_static +python27

(clang33 can be installed and clang34 cannot be built) it starts to compute dependencies and then makes a faulty decision:

--->  Computing dependencies for boost
DEBUG: boost has no conflicts
DEBUG: Searching for dependency: clang-3.3
DEBUG: Found Dependency: receipt exists for clang-3.3
DEBUG: Searching for dependency: clang-3.4
DEBUG: Didn't find receipt, going to depspec regex for: clang-3.4

Clang33 is installed. It is one build variant. Why does it have to insist on clang-3.4?

Without boost I meanwhile cannot upgrade:

gtk-doc                        1.20_2 < 1.21_0           
ImageMagick                    6.8.9-1_0 < 6.8.9-7_0     
librsvg                        2.40.2_0 < 2.40.4_0       
pstoedit                       3.61_5 < 3.62_0           

[ryandesign (Ryan Carsten Schmidt)]

As Clemens explained above, the boost port's compiler variants do not change configure.compiler. As discussed in #44911, we should remove the compiler variants since they only cause confusion (for people who expect them to do things they weren't designed to do) and problems (for people who use them on Mavericks or later).

Boost has not been buildable on older systems for a long time already. It's only recently become a major problem since now gtk-doc has an indirect dependency on boost, and lots of things use gtk-doc. I'll ask the maintainer of gtk-doc to revert the change that introduced the indirect boost dependency.

[cooljeanius (Eric Gallager)]

Cc Me!

[dbevans (David B. Evans)]

Replying to ryandesign@…:

Boost has not been buildable on older systems for a long time already. It's only recently become a major problem since now gtk-doc has an indirect dependency on boost, and lots of things use gtk-doc. I'll ask the maintainer of gtk-doc to revert the change that introduced the indirect boost dependency.

See #45170 for this request. I've attached a patch there that removes the gtk-doc dependency on boost on older systems but this is just a work around. The problem with boost remains and it effects a number of other C++ based ports as well (175 by my count).

[ryandesign (Ryan Carsten Schmidt)]

Removed the compiler variants in r125939.

[seanfarley (Sean Farley)]

Replying to ryandesign@…:

Removed the compiler variants in r125939.

That is needed to make dolfin and others that need Boost.MPI. As cal mentioned above, something needs to be done with configure.compiler. I'd like the compiler portgroup to be integrated with the way base handles compilers but haven't gotten around to it.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

Removed the compiler variants in r125939.

The solution presented here, #39809, works for me on PPC Leopard.

[ballapete (Peter "Pete" Dyballa)]

Replying to Peter_Dyballa@…:

Replying to ryandesign@…:

Removed the compiler variants in r125939.

The solution presented here, #39809, works for me on PPC Leopard.

And on PPC Tiger (Mac OS X 10.4.11) I have now boost installed as well and can start to upgrade. Again, I had to change Portfile, comment the blacklist line and add twice the configure option "--without-libraries=log".

[ryandesign (Ryan Carsten Schmidt)]

Did you test whether adding "--without-libraries=log" was really necessary? Because I've succeeded in installing Boost on PPC 10.4 and 10.5 just by removing the GCC 4.2 blacklisting. I'm testing on Intel 10.4 as well to make sure but if that works I'll commit it momentarily.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

Did you test whether adding "--without-libraries=log" was really necessary?

Not yet! I think it will take a day or so until all ports Tiger will be upgraded. Then I'll have the opportunity to test this variant – and try to see what this log library might be. Leopard can follow afterwards only – one piece of hardware only …

[ryandesign (Ryan Carsten Schmidt)]

My build on Intel 10.4 completed fine, and I tried on 10.6 as well to make sure that was still building. I committed the change in r126002.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

Did you test whether adding "--without-libraries=log" was really necessary? Because I've succeeded in installing Boost on PPC 10.4 and 10.5 just by removing the GCC 4.2 blacklisting. I'm testing on Intel 10.4 as well to make sure but if that works I'll commit it momentarily.

I can confirm that I succeeded to build Boost 1.56 on PowerPC (G4, 7447A) Tiger (Mac OS X 10.4.11) and Leopard (Mac OS X 10.5.8). I did not add "--without-libraries=log", I only commented the C compilers blacklisting.