You need a build before you can break it. You're already using Jenkins? Great! Now add a Linux box as a build slave, and create a build for Linux that mirrors your Windows builds.
Note that your requirements – breakage must be prevented, but you don't want gated commits – are a bit contradictory. But testing doesn't have to be all-or-nothing. Instead, alerting developers about breakage is still valuable when it happens after the fact. They can then fix the breakage.
Unfortunately, this only works if
- you start with a build that works on Linux, and
- whenever the build breaks, it is fixed before other commits are made.
If developers can commit on top of a bad build, they'll learn to ignore the Linux build result, rendering it nearly worthless.
It is also in your interest to enable easy testing on Linux before committing, as that can avoid much breakage. E.g. this could be virtual machines or SSH logins that are pre-configured with a build environment, or a tool to trigger custom jobs on Jenkins. This is different from forcing the devs to build on Linux. Instead, they can weigh the risks whether a change should be tested by the Jenkins build after the commit, or whether the change is more risky and should be tested manually first. If using the Linux environment is sufficiently convenient, this is a no-brainer.
While you are still transitioning to multi-platform support, it may be best to avoid automated alerts, and instead let a separate team do the porting using their own workflow. Whenever they achieve some sub-goal, it is sensible to immediately add that as a Jenkins job to avoid future regressions. E.g. intermediate steps could be that one component can be compiled on Linux, or that the build works using MinGW (i.e., still on Windows but with a non-MSVC compiler), or that an extra warning could be enabled.
Of course, none of this is an entirely technical solution. Tools alone can't solve your problems, but they can help by notifying developers about problems as they arise. More important than the tools is that the developers use their tools (because they find them genuinely useful), and that you have someone who can build and configure the tools the devs actually need.