search

HenrikBengtsson / affxparser

🔬 R package: This is the Bioconductor devel version of the affxparser package.
http://bioconductor.org/packages/devel/bioc/html/affxparser.html
7 stars 3 forks source link

Rtools 4.4 updates to affxparser #49

Open kasperdanielhansen opened 4 months ago

kasperdanielhansen commented 4 months ago

Thomas Kalibra writes

affxparser should again be updated for the new Rtools (Rtools44, to appear soon) as it includes a modified copy of the MinGW-W64 headers, and MinGW-W64 has been updated. It seems it is not needed to pass the tests, but using an outdated version of an internal header is probably too fragile. I've created a patch (affxparser_defensive.diff) that does it the same way it has been done before.

However, this approach is no longer working with the LLVM 17 toolchain (which is used for aarch64). The C++ library headers are confused by that _MSC_VER is being set even though we are not using the MSVC runtime - they try to use MSVC runtime headers for some exception handling, which are indeed not available with non-MSVC runtime.

My understanding is that the approach of always copying _mingw.h and modifying it has only been needed to make sure that the MinGW-W64 does not attempt to use the Microsoft "__uuidof" operator, which otherwise would have been used with _MSC_VER. But, that is not enough anymore.

From reading the comments in NEWS, my impression is that _MSC_VER has only been defined to tell the bundled library that it should use Windows-specific code, rather than to attempt influencing MinGW-W64 that way. Would it be possible to simply use a custom replacement, say FUSION_MSC_VER, which would not collide with the MinGW-W64 headers?

I tried that in a another attached patch, affxparser_bigger.diff. All _MSC_VER uses are changed to FUSION_MSC_VER and the "_mingw" customization business is removed. With this patch applied, the package can be built and passes its checks on my Windows/x86_64 with gcc 13.2 (Rtools44) as well as on Windows/aarch64 with LLVM 17.0.6 (Rtools44). I understand it means you would have to do the rename when/if porting an update of the embedded library, but on the other hand you would not have to maintain the `"_mingw"` customizations. And, this works also with LLVM, where otherwise apparently one would also have to somehow customize C++ internal headers, which might be even harder to maintain. So unless I have missed something, this might probably be a better fix.

affxparser_bigger.diff.txt affxparser_defensive.diff.txt