Hanspeter,
No problem. On 10.8 and earlier, there isn't a completely painless
option. Mixing the two different libstdc++'s
by linkage into the same program can be a tricky proposition, but reverting
openmpi to build against the system libstdc++
will also break existing binaries. However, since I had been putting off
upgrading the openmpi in 10.8 and earlier
(as the ABI was broken between the 1.6.x and 1.7.x releases), we could
accept that pain for the benefit of getting
current with the openmpi code base in 10.8 and earlier. Also, packages that
use openmpi are a special case
anyway as we periodically switch the gcc4x used by the openmpi package to a
later release. I've leaned against
creating -gcc4x variants for the openmpi package in order to drive us to
the latest gcc4x release and limit the
number of different gcc4x packages that have to be installed on any one
machine. Macports takes the opposite
approach and creates a truly insane number of openmpi package variants.
The main reason folks wanted to use the gcc4x compilers for mpicc
and mpicxx was to obtain openmp
support. There was a very early openmp support in gcc-4.2.1 but it wasn't
very robust or complete…
http://stackoverflow.com/questions/9084123/fftw3-configure-issue-for-openmp-use
In the past, the openmpi package wasn't used to build support libraries so
using the gcc4x compilers in
openmpi was acceptable as long as the package using openmpi was prepared to
build its c++ completely
with the g++-fsf-4.x compiler. So you gained robust and modern openmp
support in openmpi but you
boxed yourself in a corner such that any code using openmpi had to be
sandboxed such that it built
entirely with the gcc4x compilers.
Jack
ps Fortunately there are very few fink packages that use openmpi so
switching back to using the
system compilers for mpicc/mpicxx will only require a few fink packages to
get a versioned
openmpi dependency and associated revision bump to force their rebuilds.
On Sat, Apr 26, 2014 at 7:43 PM, Hanspeter Niederstrasser <
f...@snaggledworks.com> wrote:
> On Sat, April 26, 2014 11:14 am, Jack Howarth 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
>
> Jack,
>
> I'm currently traveling and unable to test any issues until Wednesday at
> the earliest, but more likely not until the weekend. I'm OK with the <
> 10.9 conditional you put in to build with clang++ on 10.9 (plus the atomic
> patch). I'll be back towards the middle/end of the week to further
> discuss as needed. If you feel more changes are needed, please discuss on
> here or on #fink with dmacks since he'll understand issues that may arise
> from the package management end. Thanks for your help,
>
> Hanspeter
>
> --
> More agile than a turtle, stronger than a mouse, nobler than a lettuce
>
>
------------------------------------------------------------------------------
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
