Improve compatibility with other Compilers like MinGW #8387
Conversation
Mellich
requested review from
rozumx,
xfreid,
jvillarre,
stsoe,
uday610,
chvamshi-xilinx and
AShivangi
as code owners
|
Mellich - is not a collaborator |
|
Can one of the admins verify this patch? |
Mellich
force-pushed
the
mingw-compat
branch
from
c1e0d5d
to
b4f21ab
Compare
|
Mellich - is not a collaborator |
At least for Clang, this seems also to be available: https://clang.llvm.org/docs/LTOVisibility.html, so it is not GNU specific. |
There was a problem hiding this comment.
This looks good. @Mellich please signoff your commits.
@manikandan-xilinx, we will need to get CI to kick in and validate this PR, what's the trick to run CI for outside contributors?
|
Mellich - is not a collaborator |
Mellich
force-pushed
the
mingw-compat
branch
from
b4f21ab
to
7302a7e
Compare
|
Mellich - is not a collaborator |
The __GNU__ flag is used in situations where an OS dependent flag should be used instead because the changes in the source files are not compiler dependent Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Signed-off-by: Marius Meyer <mariusme@mail.upb.de>
Mellich
force-pushed
the
mingw-compat
branch
from
7302a7e
to
7320313
Compare
|
@Mellich . Thank you very much for this effort. |
* Make preprocessor conditions depend on os The __GNU__ flag is used in situations where an OS dependent flag should be used instead because the changes in the source files are not compiler dependent Signed-off-by: Marius Meyer <mariusme@mail.upb.de> * Fix upper case in include Signed-off-by: Marius Meyer <mariusme@mail.upb.de> * Fix libxrt_core windows link dependencies Signed-off-by: Marius Meyer <mariusme@mail.upb.de> * Fix xbutil2 windows link dependencies Signed-off-by: Marius Meyer <mariusme@mail.upb.de> * Fix xclbinutil windows link dependencies Signed-off-by: Marius Meyer <mariusme@mail.upb.de> * Only define types if GCC is not used Signed-off-by: Marius Meyer <mariusme@mail.upb.de> * Remove DLL exports and imports from header-defined methods Signed-off-by: Marius Meyer <mariusme@mail.upb.de> --------- Signed-off-by: Marius Meyer <mariusme@mail.upb.de> Co-authored-by: Marius Meyer <mariusme@mail.upb.de>
Problem solved by the commit
I am working on an integration of XRT into Julia. However, the current Windows build does only support MSVC and the packages for Julia are build using MinGW, so I XRT to improve the compatibility with MinGW. I ported back some of the patches because they should not affect the currently supported toolchains and could be useful to support further toolchains in the future. No features are added or removed to XRT with this PR - it only affects the build process.
Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered
Currently, some preprocessor defines are used in non-standard ways, increasing the difficulty to compile the code on Windows with GCC. Also, some library dependencies seem to be missing for some of the Windows binaries.
How problem was solved, alternative solutions (if any) and why they were rejected
I changed some occurrences of
__GNU__to__linux__because the contained codes rather depend on the used OS than on the compiler.The missing libraries were added as link dependency.
Risks (if any) associated the changes in the commit
I was not able to test the build on a native Windows machine with MSVC, because I have no access to one.
The proposed changes should only affect the build and linking of binaries, and not the functionality.
What has been tested and how, request additional testing if necessary
Build on Red Head Enterprise Linux and Alpine Linux using GCC 9.1 as well as MinGW on Alpine Linux with GCC 9.1 and some additional minor patches.
Documentation impact (if any)
Should not affect documentation, because this PR only applies changes to the build process.