> Hmmm, when I connect gdb to the process, I get an immediate > > 0x00007f9480ca33ff in __GI___poll (fds=0x55943c327d50, nfds=2, timeout=-1) at > ../sysdeps/unix/sysv/linux/poll.c:29 > 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
gdb automatically breaks on all signals, and this might be a SIGALRM or some other non-aborting signal. You can probably ignore it safely. > boost::nowide::setenv(char const*, char const*, int)@plt > > and sliced AK_Bed.stl > > gdb did halt on the breakpoint, and got > Thread 73 "perl" hit Breakpoint 1, 0x00007f948024f700 in > boost::nowide::setenv(char const*, char const*, int)@plt () > from /usr/lib/slic3r/auto/Slic3r/XS/XS.so I suppose a "cont" will crash the program here, correct? The @plt symbol is actually *not* the routine being called, but a stub generated by the compiler that takes care of runtime linking. If the dynamic linker can't find the symbol in any loaded library, it will crash. I compiled a quick test program, linked it against libboost_nowide.so.1.74.0 and it works as expected. The dynamic symbol being called is the same as the one you reported: _ZN5boost6nowide6setenvEPKcS2_i This leads me to the conclusion that nothing is with boost_nowide per se. Can you do a ldd /usr/lib/slic3r/auto/Slic3r/XS/XS.so and check if you see /usr/lib/x86_64-linux-gnu/libboost_nowide.so.1.74.0 somewhere in there?