Hi Denis,
I don't have the build folders any more so I can not post the error log.
But the error (using spack) occurred with both boost versions. I will post
something once I will find a solution.
At any rate, thank you for your help.
Best,
Konrad
--
The deal.II project is located at http://
Hi Alberto,
Looks like the issue is known to Spack
community: https://github.com/spack/spack/issues/11224 where there is also
a possible source of the problem you can try as a fix (un-do on-line PR).
Regards,
Denis.
On Wednesday, October 2, 2019 at 3:14:46 PM UTC+2, Bruno Turcksin wrote:
>
> A
On Wednesday, October 2, 2019 at 11:50:53 AM UTC+2, Konrad Simon wrote:
>
> Thank you, Denis. I use a pretty stupid (but simple) workaround: I setup
>>> and compile deal.ii myself since all dependencies are compiled and use the
>>> cmake command used by spack. That works. And I do not get the ser
>
>
>> I guess I have a clue why I get the error. My backend nodes run on a
>> different architecture. The openmpi version (i.e. mpirun) is the correct
>> one. This is made sure in the slurm script.
>>
> That's always a pain to deal with. If you can, I would get an interactive
> session on a co
Alberto,
So what happens is that spack is using gcc 9.2 like you want but it
usess the libstdc++ from gcc 4.8.5 I usually spack to install a new
compiler and my compilers.yaml looks like your *but* I have the path
to the correct libstdc++ in my LD_LIBRARY_PATH when I load the module.
So I guess yo
Bruno, I guess the point is that cmake invokes /lib64/libstdc++.so.6
rather than /usr/local/lib64/libstdc++.so.6
Is it correct?
*Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
(DIMI)
Universita` di Brescia, via Branze 43, 25123 Brescia
Italy
tel 030 3711239
fax 030 371
Thank you, Bruno. In fact, my aim was to use my system compiler.
Here is my .spack/linux/packages.yaml:
packages:
all:
compiler: [gcc]
providers:
mpi: [openmpi]
openmpi:
version: [3.1.4]
paths:
openmpi@3.1.4%gcc@9.2.0: /usr/local/
buildable: False
p
Alberto,
On Wednesday, October 2, 2019 at 7:24:32 AM UTC-4, Alberto Salvadori wrote:
>
>
> Thank you so much W and D,
> As you pointed out there seems to be a mistake in the most recent version
> of perl during installation.
> I will propagate this to the proper communities.
>
> As Denis propose
Konrad
On Wednesday, October 2, 2019 at 5:50:53 AM UTC-4, Konrad Simon wrote:
>
>
>
>>
>>> However, now my code runs on the machine I installed it on. But once I
>>> use slurm to distribute the job across nodes I get "illegal instruction"
>>> erros. Frustrating.
>>>
>>
>> With HPC I used to ha
Thank you so much W and D,
As you pointed out there seems to be a mistake in the most recent version
of perl during installation.
I will propagate this to the proper communities.
As Denis proposed, I went on simply tell Spack to use Perl from system:
perl:
paths:
perl@5.26.2%
Thank you so much W and D,
As you pointed out there seems to be a mistake in the most recent version
of perl during installation.
I will point this out in the proper communities.
As Denis proposed
*Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
(DIMI)
Universita` di B
>
> Thank you, Denis. I use a pretty stupid (but simple) workaround: I setup
>> and compile deal.ii myself since all dependencies are compiled and use the
>> cmake command used by spack. That works. And I do not get the serialization
>> error.
>>
>
>
> now that is strange. Are you sure you pick
12 matches
Mail list logo
