On Wed, Jan 16, 2013 at 9:19 PM, Jeremy Huddleston Sequoia
<jerem...@macports.org> wrote:
>
> On Jan 16, 2013, at 17:49, Sean Farley <s...@macports.org> wrote:
>
>> On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia
>> <jerem...@apple.com> wrote:
>>>
>>> On Jan 15, 2013, at 8:52 AM, Sean Farley <s...@macports.org> wrote:
>>>
>>>> On Mon, Jan 14, 2013 at 8:32 AM, David Barto <dba...@visionpro.com> wrote:
>>>>> fails because the /usr/lib/libstdc++.so is found first. What can I do to
>>>>> find the proper /opt/local/lib/libstdc++.so?
>>>>>
>>>>> I've not modified the search paths in any way, I'm just trying to compile
>>>>> a
>>>>> c++ program using the newer standard features.
>>>>
>>>> Hmm, I can't reproduce this error. Using no special environment
>>>> variables and just a vanilla install of gcc47 on Mountain Lion, I get:
>>>
>>> <snip />
>>>
>>> Yeah, all of the MacPorts gcc compilers should be using
>>> /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib. This
>>> should "just work" … if you're seeing something differnet, it would be
>>> helpful to see how ld is being called by the compiler. Run:
>>>
>>> g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v
>>>
>>> ---
>>>
>>> That being said, is there something wrong with clang++ that is causing you
>>> to try g++ instead?
>>
>> Jeremy, please understand that this is a frustrating position / stance
>> to have from the perspective of the user. In the scientific community,
>> it is *expected* to try out all the compilers you have access to.
>> Usually, this just means Intel, Portland Group, IBM, and gcc; but now
>> it also includes clang.
>
> Whoa … I'm simply asking if you're using g++ because you came across a bug in
> clang++ … there's no reason to get jumpy. I, myself, test with a huge
> variety of compilers in order to discover potential code generation issues
> before they effect average developers. Don't bite me for asking.
Apologies if that was too harsh. I didn't mean to sound like I was
biting back, but rather was trying to start a dialogue / point out a
different reasoning for multiple compilers. No offense / attack was
meant; sorry.
>> Also, there are _tons_ of reasons that
>> projects use different compilers. The most common is fortran (don't
>> even get me started on Apple stripping out gfortran from gcc 4.2 AND
>> THEN providing a bogus mpif{77,90} wrapper). If your project has both
>> C++ and Fortran dependencies, then the only way to compile the Fortran
>> is to install gcc4X. Well, that usually means your configure script
>> will also pick up gcc4X's C/C++ compiler.
>>
>> The second most common reason I've seen is the one you mention: errors
>> in the C++ compiler. If Apple decides to update their Xcode clang
>> version to 3.1 or later anytime soon
>
> XCode 4.5 (and I think 4.4) was based on llvm 3.1
>
>> , then everyone on a mac will run into this bug,
>>
>> http://llvm.org/bugs/show_bug.cgi?id=14768
>
> The compiler distributed with Xcode has assertions disabled by default, so
> end users are likely to not trip over that assertion. What affect that
> actually has on generated code, I don't know… but thanks for pointing that
> out to me.
Ah, that would explain why there's no crash for the Apple compiler.
Thanks for explaining that.
>> I personally have had clang++ bugs with libmesh, moose, armadillo, and
>> dolfin.
>
> There are plenty of g++ bugs as well ;) … have you filed radars (or at least
> llvm bugzilla reports) about all of the clang issues you are finding? Can
> you point me to them?
Unfortunately, 1) I didn't report them at the time (and can't
reproduce) and 2) some of the repos are private :-(
>> What makes this sentiment frustrating is the whole "use this
>> one version of the library with no optimization or debug control"
>> which is at odds with "try this library with {gcc,clang,etc.}'s
>> -O{1,2,3} and then write a paper about the results."
>
> I'm not really sure I know what you're referring to with the above sentence.
Ah, I meant to explain the need for having multiple versions of a
library / program with different optimization levels for numerical
computation.
>> This actually was
>> my whole motivation for writing scienceports: provide a way to use a
>> library with gcc4X or clang3X and somehow manage the combinatorial
>> explosion of variants (the correct data structure, by the way, is a
>> DAG).
>
> How are you planning to manage the inherent difficulty with some clients
> using libstdc++ and libc++? It's possible for two separate libraries to use
> different C++ runtime versions so long as they're not passing objects back
> and forth, but most of the time, libraries that are implemented in C++
> provide C++ APIs to that library.
You are right to point out that a DAG alone won't solve compatibility
issues. I just meant that it's impossible to do correct dependency
analysis without having (or having something isomorphic to) a DAG.
>> Ok, this rant is too long now. I hope no one is offended as I tried to
>> explain some of the science community's frustration.
>
> Please try to be specific about issues you are concerned with.
Agreed, I'll try to be more specific.
> The bug you mentioned earlier was just reported two weeks ago, so you can't
> reasonably expect it to have been triaged and fixed by now unless you're
> willing to hack on the compiler yourself. Additionally, you have the option
> of disabling assertions in clang if you want to get past it (although I don't
> know what the result would be since the assertion may actually be reasonable,
> or it may just be a bad assert … I haven't investigated).
Sorry for the miscommunication, I just meant it as a real world bug I
ran into with using clang and that might be why someone needs to use
gcc. I wasn't expecting it to be fixed this soon.
> Can you please provide the information I requested regarding libstdc++
> linkage?
I thought you were talking to the guy that reported the error?
> What other issues are you specifically frustrated with?
Pretty much just the ability to easily manage ports compiled with
different compilers.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
