Nimporter fails to import due to undefined symbol "__builtin_ssubll_overflow" when using GCC on CentOS 7.5
So, I got this really ugly stack trace when trying to import the basic `nim_math.nim` example code into my python project. The relevant sections of the project tree look like:

```
root/
    nim/
        nim_math.nim
        __pycache__/
            nim_math.nim.hash
            nim_math.so
    src/
        app.py
```

And the relevant contents of `app.py` are: 

```
...
import nimporter
import nim.nim_math
...
```

Here's some more data about the environment that isn't available in the stack trace: I'm using a CentOS 7.5 base docker image with GCC version 4.8.5. I've also replicated this same failure with the same docker image on GCC versions 7.x and 8.x.

```
/pyenv/versions/3.8.0/envs/my-new-project/lib/python3.8/site-packages/nimporter.py:1117: in find_spec
    return Nimporter.import_nim_code(fullname, path, library=False)
/pyenv/versions/3.8.0/envs/my-new-project/lib/python3.8/site-packages/nimporter.py:819: in import_nim_code
    cls.__validate_spec(spec)
/pyenv/versions/3.8.0/envs/my-new-project/lib/python3.8/site-packages/nimporter.py:887: in __validate_spec
    raise NimporterException(error_message) from import_error
E   nimporter.NimporterException: Error importing /app/nim/__pycache__/nim_math.so
E   Error Message:
E
E       /app/nim/__pycache__/nim_math.so: undefined symbol: __builtin_ssubll_overflow
E
E   Python Version:
E
E       3.8.0 (default, Dec 16 2019, 22:06:06) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]
E
E   Nim Version:
E
E       Nim Compiler Version 1.2.0 [Linux: amd64]
E
E   CC Version:
E
E       <Error getting version>
E
E   Installed CCs:
E
E       {'gcc': PosixPath('/usr/bin/gcc')}
E
E   Please help improve Nimporter by opening a bug report at: https://github.com/Pebaz/nimporter/issues/new and submit the above information along with your description of the issue.
```

I'm not sure if the issue is with nimporter, nimpy, the nim compiler, or gcc itself. It _looks_ like this is an issue with the compiled output, so nimporter might be off the hook here. If that's the case, I'll have to file this same issue one layer deeper down the stack - which I guess would involve pestering the folks who develop nimpy.

I'm hoping this is an easy fix though - maybe there's some compiler switch I'm missing that could make this all go away. Thanks for the help (and the awesome project!)