Hanspeter,
Just to clarify things, the history of openmpi is as follows.
Originally when I picked up the package it was designed to use only
the fortran compiler from the gcc4x-compiler packages and the system gcc
and cc compilers were used for c and c++ code. I got
a number of user requests to switch the c and c+ compilers to those in the
gcc4x-compiler package as well. That change became
much more problematic with the switch of the system c++ library from the
libstdc++ ABI to the libc++ ABI in 10.9 hence the
switch back to the system compilers for mpicc and mpicxx. While this lost
us the option of simultaneously enabling openmp
(which is different) in the code, that limitation should disappear in a
future clang release once Apple has fully merged the donated
Intel openmp code base into llvm.
Jack
ps In the past, I wan't that concerned about the use of the gcc4x-compiler
c/c++ compilers in openmpi as code that used it tended
to not have many or any c++ support libraries to worry about so that the
compiles where pretty self contained. The boost situation
is quite different. There are a lot of complex builds that use boost which
would require swaths of the fink package set to be rebuilt
against g++-fsf-4.8 for properly standardized linkage on the same libstdc++
throughout. Also, it is a corner case that users would
really want to run their application with openmpi. Especially with boost
which already approaches that problem via threading.
Enabling openmpi support in boost doesn't make much sense for a single
workstation and only becomes sensible if the user
is running the program across a number of different workstations via
openmpi so it only makes sense as a boost-openmpi variant.
Considering that Apple may remove their ancient gas assembler,
essential for the FSF gcc compilers to function, in some
future Xcode release, we should attempt to avoid unnecessary usage of the
gcc4x packages unless they are essential. This
will limit the carnage that will ensue when Apple depreciates gas (as they
still haven't made any commitment to providing
a stand alone replacement based on the integrated assembler from clang).
When Mavericks support in fink was being developed, I initially
proposed adding a check for this mixing of incompatible
c++ libraries but never pushed it as every case that I looked at failed to
link due to the incompatible symbols in the libstdc++
and libc++.
On Sat, Apr 26, 2014 at 1:13 PM, Jack Howarth <howarth.at.f...@gmail.com>wrote:
> Hanspeter,
> Okay, I see now that you are trying to leverage the openmpi support
> in boost. This creates two different problems.
>
> 1) On 10.8 and earlier, openmpi uses the gcc-fsf-4.8 and g++-fsf-4.8
> compilers so you would need to compile boost against that compiler.
> However this will mean that when you link other c++ programs and c++
> support libraries against boost1.55 on 10.8 or earlier,
> it will be mixing two different libstdc++ releases. The c++ program and
> support libraries will be linked against the system libstdc++
> (which is from gcc 4.2.1) and boost1.55 will be linked against the newer
> libstdc++ from gcc48. This might work but isn't really
> a good idea in general.
>
> 2) On 10.9 and later, the openmpi compiler wrappers call the clang and
> clang++ compilers for c and c++ code and the gfortran-fsf-4.8
> compiler for fortran code. So your packaging is broken on 10.9 in that it
> breaks the expected compiler usage for openmpi and prevents
> the c++ code from being generated to use libc++. The libc++ and libstdc++
> ABIs are incompatible and never should be mixed.
>
> On 10.9, you at least want to create a 10.9 variant for boost1.55 which
> removes the usage of gcc-fsf-4.8 and g++-fsf-4.8 and restores
> the usage of the clang and clang++ compilers via the compiler wrappers.
>
> On reflection, I also don't think you want the stock boost1.55 to build
> against openmpi in any case. There should be a boost1.55-openmpi
> variant to do that. It really doesn't make sense to build the library as
> openmpi code unless you intend to force all the packages that use
> boost1.55 to be built with mpicc. mpicxx and mpif90.
> Jack
> ps Also are you sure you didn't enable openmpi in boost1.55 simply because
> you were confusing it with openmp? The openmp support
> is much more transparent and doesn't require the resulting executables to
> be executed through utility programs ala mdrun like openmpi.
>
>
> On Sat, Apr 26, 2014 at 12:14 PM, Jack Howarth
> <howarth.at.f...@gmail.com>wrote:
>
>> Hanspeter,
>> What is the logic behind making boost1.55 build against the
>> g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that,
>> you require any program that links against boost1.55 and all of its support
>> libraries to be built with g++-fsf-4.8. We were very careful when Mavericks
>> landed to make sure that boost1.53 properly built against libc++ from
>> clang++ rather than any of the libstdc++ releases (system or fsf gcc). This
>> seems like a major regression in the packaging compared to boost1.53. I am
>> surprised you resorted to that as the newer boost release should have even
>> more libc++ related fixes than 1.53 did.
>> Jack
>>
>
>
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
