[Users] ML build broken?

[Luca Baiotti]

On 8/20/12 5:18 PM, Ian Hinder wrote:
>
> On 20 Aug 2012, at 07:21, Luca Baiotti wrote:
>
>> On 8/20/12 12:12 AM, Ian Hinder wrote:
>>>
>>> On 19 Aug 2012, at 15:59, Luca Baiotti wrote:
>>>
>>>> On 8/19/12 5:04 PM, Ian Hinder wrote:
>>>>>
>>>>> On 19 Aug 2012, at 09:23, Luca Baiotti wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I updated my Cactus tree and compiled on my laptop (with repository
>>>>>> simfactory osx-snow-leopard-macports-gcc.cfg) a thornlist containing
>>>>>> McLachlan. The error is:
>>>>>>
>>>>>> COMPILING
>>>>>> /Users/baiotti/Cactus/arrangements/McLachlan/ML_BSSN/src/ML_BSSN_convertFromADMBaseGamma.cc
>>>>>> /Users/baiotti/Cactus/arrangements/McLachlan/ML_BSSN/src/ML_BSSN_convertFromADMBaseGamma.cc:
>>>>>> In function 'void ML_BSSN_convertFromADMBaseGamma_Body(const cGH*, int,
>>>>>> int, const double*, const double*, const double*, const int*, const
>>>>>> int*, int, double* const __restrict__*)':
>>>>>> /Users/baiotti/Cactus/arrangements/McLachlan/ML_BSSN/src/ML_BSSN_convertFromADMBaseGamma.cc:486:22:
>>>>>> error: cannot convert '__m128d {aka __vector(2) double}' to 'double' for
>>>>>> argument '1' to 'double sgn(double)'
>>>>>> /Users/baiotti/Cactus/arrangements/McLachlan/ML_BSSN/src/ML_BSSN_convertFromADMBaseGamma.cc:488:22:
>>>>>> error: cannot convert '__m128d {aka __vector(2) double}' to 'double' for
>>>>>> argument '1' to 'double sgn(double)'
>>>>>> /Users/baiotti/Cactus/arrangements/McLachlan/ML_BSSN/src/ML_BSSN_convertFromADMBaseGamma.cc:490:22:
>>>>>> error: cannot convert '__m128d {aka __vector(2) double}' to 'double' for
>>>>>> argument '1' to 'double sgn(double)'
>>>>>> make[3]: *** [ML_BSSN_convertFromADMBaseGamma.cc.o] Error 1
>>>>>> make[2]: *** [make.checked] Error 2
>>>>>> make[1]: ***
>>>>>> [/Users/baiotti/Cactus/configs/GRHydro2/lib/libthorn_ML_BSSN.a] Error 2
>>>>>>
>>>>>> Do others see the same error?
>>>>>
>>>>> When did you update, and did you update everything at the same time?  We had an issue related to this but we thought it was fixed a few days ago.
>>>>
>>>> 10 hours ago, with GetComponents --update
>>>>
>>>>> On Datura, the tests all pass.  http://damiana2.aei.mpg.de/~ianhin/testreports/EinsteinToolkitTests/results.xml
>>>>>
>>>>> I will try using Snow Leopard and report back.
>>>>
>>>> Thanks,
>>>
>>> A fresh compile works for me.  Maybe GetComponents didn't do the update properly?  Can you try with a fresh checkout?
>>>
>>
>> Sorry, the previous email was sent before completion.
>>
>> Yes, a fresh checkout compiles. The problem was that the symbolic links in McLachlan and Carpet had become real files for some reason (I may have moved the Cactus tree around? May the links have been chamged by GetComponents?) and so they were not linked to the files in 'repos'. Interesting problem.
>
> How did you move the trees around?  Did you use a method which preserves symbolic links?  If you copy a Cactus tree using "cp -r", you will not get the symbolic links.  From the Mac OS cp man page:
>
>> COMPATIBILITY
>>       Historic versions of the cp utility had a -r option.  This implementation
>>       supports that option; however, its use is strongly discouraged, as it
>>       does not correctly copy special files, symbolic links, or fifo's.
>
>
> You should use "cp -a" which copies symlinks.  If instead you use rsync, be sure to use the -a option, which correctly copies everything.

Yes, Ian, that was it. I didn't remember about this default.

>> So, the problem is solved, but I post some (unrelated) warnings produced by GetComponents.
>
> I don't think these warnings are unrelated.
>
>>
>>
>> 1) bin/GetComponents --update --verbose
>>
>> [...]
>> -----------------------------------------------------------------
>>   Updating module: McLachlan/doc
>>   from repository: git://carpetcode.org/McLachlan
>>        located in: ./arrangements
>> Executing: git diff-files --quiet
>>        In: /Users/baiotti/Cactus/./repos/McLachlan
>> Executing: git stash
>>        In: /Users/baiotti/Cactus/./repos/McLachlan
>> No local changes to save
>
> I suspect that GetComponents is trying to work out whether it needs to stash changes.  Since it then goes on to stash, I assume the answer came back as "yes", even though "git stash" is reporting no changes.  Something is wrong here, maybe because of the symbolic links being corrupted?
>
>> Executing: git remote update origin
>>        In: /Users/baiotti/Cactus/./repos/McLachlan
>> Fetching origin
>> Executing: git branch
>>        In: /Users/baiotti/Cactus/./repos/McLachlan
>> * master
>> Executing: git pull --rebase origin master
>>        In: /Users/baiotti/Cactus/./repos/McLachlan && git checkout master
>> Already on 'master'
>>  From git://carpetcode.org/McLachlan
>> * branch            master     -> FETCH_HEAD
>> Current branch master is up to date.
>> Executing: git checkout master
>>        In: /Users/baiotti/Cactus/./repos/McLachlan
>> Already on 'master'
>> Executing: git stash pop
>>        In: /Users/baiotti/Cactus/./repos/McLachlan
>> No stash found.
>>
>> Warning: Could not update McLachlan. Could not pop stashed changes.
>
> This is also bad - the error was "no stash found" because there was nothing to stash in the first place.

It was a temporary problem, now I have no warning, neither in the fresh 
checkout, nor in the old checkout where I fixed the symbolic links by 
hand. I wonder if the cause could have been the server of the repository 
or my connection. The uninitialized value in concatenation remains.

>>
>> [...]
>>
>>
>> 2) bin/GetComponents --root=. ../einsteintoolkit20.th
>> Do you want to update all existing components? yes, no [no] : yes
>> Use of uninitialized value in concatenation (.) or string at bin/GetComponents line 2532, <STDIN> line 1.
>> Use of uninitialized value in concatenation (.) or string at bin/GetComponents line 2532, <STDIN> line 1.
>>
>> [...]


Cheers,
Luca