It might work, but there's no reason why you can't build with -g. From your sigsegv, it looks like a null pointer got freed. Try installing libudev-dbg (if available) and running again. It might give more detail.
This looks related:
https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=71543
edit: reading through that bug, it seems like you've built your own libsdl2 from source and it may have conflicts with the installed udev. Notice that you've got a libudev.so.0 and libudev.so.1. When building libsdl2, you probably need to use -Bsymbolic to avoid conflicts between those two libs. Or perhaps remove the system libudev (although that's likely to break things). Another option is to build libsdl2 and configure it to reference the installed libudev instead of building (what I assume) is a bundled copy.
It's the same set of symptoms, but a different root cause. You don't have Steam in this case, but your newer Mesa build causes the system libudev to get loaded first, then SDL brings its own copy to the party and things get confusing.
This looks related:
https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=71543
edit: reading through that bug, it seems like you've built your own libsdl2 from source and it may have conflicts with the installed udev. Notice that you've got a libudev.so.0 and libudev.so.1. When building libsdl2, you probably need to use -Bsymbolic to avoid conflicts between those two libs. Or perhaps remove the system libudev (although that's likely to break things). Another option is to build libsdl2 and configure it to reference the installed libudev instead of building (what I assume) is a bundled copy.
It's the same set of symptoms, but a different root cause. You don't have Steam in this case, but your newer Mesa build causes the system libudev to get loaded first, then SDL brings its own copy to the party and things get confusing.