Working with Macs is not without it's challenges. I now have my
workstation and laptop (both ML) both working with full stacks built
against GCC and Clang without any special compiler options or other libMesh
flag hacks ;) However, Apple, not wanting us to get bored has created
another minor hurdle for us. It appears that Clang no longer links with
the current version of the Apple Command Line tools package! It turns out
that this issue is not a clang problem directly, but rather a linker (ld)
problem which is failing with a seg fault. Some bizarre combination of
flags is causing the issue but the link lines are different enough between
the way GCC and Clang invoke the linker that I really don't feel like
diving in right now. There is a workaround though, the slightly older
(August 7th, 2012) version of the command line tools which works just fine
without any further changes.
Good luck!
Cody
On Mon, Oct 22, 2012 at 5:25 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> That error is eerily familiar to what I get on OSX when I use boost.unit
> in my app code. No resolution yet, but definitely let me know if you figure
> it out!
>
>
>
> On Oct 22, 2012, at 4:00 PM, "Cody Permann" <codyperm...@gmail.com> wrote:
>
>
>
> On Mon, Oct 22, 2012 at 4:50 PM, Paul T. Bauman <ptbau...@gmail.com>wrote:
>
>> Sorry I haven't been able to be more helpful in reproducing the errors.
>> Is the pretty much settled at this point (i.e. ditching the non-release
>> version of fparser) or is there still some more stuff y'all would like me
>> to try?
>
>
> Don't know - libMesh may be off the hook! I have a patch ready to go that
> will support both the release and development versions of fparser and it
> seems to be working fine. I was able to configure and run libmesh 4.7 in
> debug mode and run the examples with my patch.
>
> MOOSE however is another story I'll have to continue to debug but I'm
> still running into some very bizarre errors that occur only in debug mode
> that simply don't make sense. I'll do a little more testing tomorrow and
> will probably commit this patch. For the record, the error I'm receiving
> (pointer being freed was not allocated) was one of the errors I saw
> repeatedly with the fparser stuff. Still investigating...
>
> Thanks,
> Cody
>
>
>>
>> Isn't the retina display bad ass?
>>
>>
>> On Fri, Oct 19, 2012 at 10:32 AM, Cody Permann <codyperm...@gmail.com>wrote:
>>
>>>
>>>
>>> On Thu, Oct 18, 2012 at 9:39 AM, Paul T. Bauman <ptbau...@gmail.com>wrote:
>>>
>>>> On Thu, Oct 18, 2012 at 10:29 AM, Cody Permann
>>>> <codyperm...@gmail.com>wrote:
>>>>
>>>>>
>>>>> Haven't really had much time to work on these issues this week but
>>>>> Jason did try the automake branch and it worked flawlessly with GCC 4.6.
>>>>> Interestingly on the same system in a different directory we were still
>>>>> able to reproduce the same issue when using HEAD. This gives me a little
>>>>> hope, I'm going to start looking at flags and other things to see what
>>>>> differences there might be between the two branches.
>>>>>
>>>>
>>>> OK, great. This was on my TODO list to look at this difference because
>>>> the hiccup I was seeing in ex6 was fixed with using the the automake branch
>>>> which means libtool is probably stripping out some incompatible flags or
>>>> something at link time. I'll try and look at this tomorrow and let y'all
>>>> know if I find anything.
>>>>
>>>
>>> Well I'm the proud new owner of a new MacBook Pro (Retina Display) which
>>> will be nice to play around with while I figure out these compiler issues.
>>> Yesterday, Jason installed GCC 4.6 on it from source and it still failed
>>> to build libMesh in debug mode. I also had very weird issues with Clang
>>> for the first time ever so that wasn't a very nice start. As usual the
>>> hard drive comes from Apple partitioned with a case-insensitive filesystem
>>> so I'm going to blow it away, repartition the drive and start from scratch
>>> again today. This time I'm going to do all of the work myself to make sure
>>> Jason isn't introducing some odd bug in the process somewhere but at this
>>> point I don't think he is doing anything wrong. I'm debating on trying Mac
>>> Ports first to see if I can get something to work since I still haven't had
>>> time to look at those flags yet. If you learn anything keep me posted.
>>>
>>> For fun Derek and I did some compile time comparisons with GCC4.6 (opt
>>> mode) versus Apples GCC4.2 compilers on his Macbook pro (last year's
>>> model). It turns out that Apple's compilers are quite a bit faster than
>>> GCC even against my new hardware. I don't think he'll win though when I
>>> get clang going again. It's too bad that Apple had to break 'em.
>>>
>>> Thanks,
>>> Cody
>>>
>>>
>>>> Best,
>>>>
>>>> Paul
>>>>
>>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
