The most likely issue will be a "symbol clash" either due to ABI
incompatible versions of the same external shared library linked into
the executable, or due to the matlab shared library you are linking
against containing these.

Can you send us the output of $ ldd executable  (for a faulty one)?

Furthermore, have you tried running the startup in a debugger such as
gdb? If possible, the stacktrace for the segfault will be very
illuminating:

  $ gdb executable
  > run
  > bt

Best,
Matthias



On Thu, Jun 22, 2023, at 14:46 CDT, Mathieu <mathieu....@gmail.com> wrote:

> Thanks Matthias for clarification. 
> But as I said, I do not have this problem using the default compiler on my 
> system. 
>
> Since I have no experience with a debugger, I let valgrind run on the 
> program:
> valgrind --tool=memcheck --leak-check=full --track-origins=yes ./step-1
> (see the attachment for the output). 
>
> From the memcheck, I can not deduce anything that would bring me closer to 
> the bottom.
> Do you have any suggestions based on the memcheck?
> I could imagine there is a mismatch between some deal.II dependencies (TBB 
> ?) and the 
> corresponding versions shipped with matlab.
>
> Best,
> Math
>
>
>
> Matthias Maier schrieb am Donnerstag, 22. Juni 2023 um 20:14:02 UTC+2:
>
>
> On Thu, Jun 22, 2023, at 04:13 CDT, Mathieu <mathi...@gmail.com> wrote: 
>
>> Good point to narrow down the problem. 
>> I modified step-1 so that the main function only calls matlab via 
>> callFevalsqrt(). 
>> This works fine, even if I use the mpi compiler mentioned in my original 
>> post. 
>> However, if I just add a second line in the main function, 
>> dealii::Triangulation<2> triangulation, 
>> I run again into the segfault. 
>
> What happens when you include this statement in yourr main function is 
> that your main.cc compilation unit now contains a symbol to the deal.II 
> library. The linker will then keep libdeal_ii.so as a shared object 
> dependency. If you do not actually use any symbol from the deal.II 
> library itself then the linker might drop the shared object altogether 
> and the final result is as if you never linked to deal.II in the first 
> place. You can verify this by running "ldd" on the executable: 
>
> $ ldd executable 
> libdeal_II.so.9999 => /usr/lib64/libdeal_II.so 
>
> Best, 
> Matthias 

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/87ilbf89w5.fsf%4043-1.org.

Reply via email to