Skip to content

Allow MinGW builds#189

Merged
Swatinem merged 38 commits intogetsentry:masterfrom
Amphaal:master_mingw
Mar 25, 2020
Merged

Allow MinGW builds#189
Swatinem merged 38 commits intogetsentry:masterfrom
Amphaal:master_mingw

Conversation

@Amphaal
Copy link
Copy Markdown
Contributor

@Amphaal Amphaal commented Mar 20, 2020

Once getsentry/crashpad#5 validated, i'll modify submodules dependencies accordingly. Please note that Clang is required for testing MinGW builds since .pdb files are mandatory, and only Clang can produce these files for now.

Copy link
Copy Markdown
Contributor

@Swatinem Swatinem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very promising so far. I noted some things. If its not too much of a hassle, maybe add this to our CI matrix as well?

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 23, 2020

I'm not that experienced with the merging system of github, and it seems that some of my modifications here (sync of some files with master) makes the whole pull request quite messy, let me try to fix that before giving it another look ;)

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 23, 2020

Alright, now it is cleaner.

I'm now working on the CI implementation on another branch (https://github.com/Amphaal/sentry-native/blob/mingw_ci/azure-pipelines.yml / https://dev.azure.com/gvara/sentry-native/_build?definitionId=1&_a=summary), I'll commit here once I get a working run.
The issue rn is that the whole installation/prewarm process take ~5min, and I cannot get the cache tasks working to speed things up.

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 23, 2020

@Swatinem Please check this CI report : https://dev.azure.com/gvara/sentry-native/_build/results?buildId=24&view=logs&j=cabecbaf-ef53-5b05-6522-b652bd51d68f&t=2ccb8d92-b2e3-55af-4ad2-88895670b330. I faced the same "issue" locally, which consists of passing tests but with an error in the output ! Is this expected and normal ?

@Swatinem
Copy link
Copy Markdown
Contributor

@Amphaal Azure gives me a 401, I don’t have permission to view that report.

And don’t bother too much with azure caching. I played around with caching stuff needed for android. And the cache tasks were actually slower than fetching all that stuff from scratch.

Also, just do a normal merge / rebase on the CLI with git. I don’t like the github merge UI either.

Copy link
Copy Markdown
Contributor

@Swatinem Swatinem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm now ;-)

lets see how the tests are looking…

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 23, 2020

@Amphaal Azure gives me a 401, I don’t have permission to view that report.

My bad, the fork project was in private mode, it should be ok now.

Just in case, this is the output :

Test background_worker...                       [ OK ]
Test basic_consent_tracking...                  [6480:3420:20200323,114641.425:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[6480:3420:20200323,114641.489:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[6480:3420:20200323,114641.520:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[6480:3420:20200323,114641.536:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[6480:3420:20200323,114641.645:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test basic_function_transport...                [4616:6984:20200323,114641.692:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test basic_http_request_preparation_for_event... [5568:1188:20200323,114641.725:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test basic_http_request_preparation_for_event_with_attachment... [2384:420:20200323,114641.756:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test basic_http_request_preparation_for_minidump... [1016:2380:20200323,114641.803:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test dsn_parsing_complete...                    [ OK ]
Test dsn_parsing_invalid...                     [ OK ]
Test dsn_store_url_without_path...              [ OK ]
Test dsn_store_url_with_path...                 [ OK ]
Test enumerating_database...                    [3056:2972:20200323,114641.897:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[3056:2972:20200323,114641.912:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test lazy_attachments...                        [1088:3508:20200323,114641.959:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test module_finder...                           [ OK ]
Test page_allocator...                          [ OK ]
Test path_basics...                             [ OK ]
Test path_current_exe...                        [ OK ]
Test path_joining_unix...                       [ OK ]
Test path_joining_windows...                    [ OK ]
Test path_relative_filename...                  [ OK ]
Test procmaps_parser...                         [ OK ]
Test serialize_envelope...                      [436:4720:20200323,114642.131:ERROR registration_protocol_win.cc:84] TransactNamedPipe: The pipe has been ended. (109)
[ OK ]
Test slice...                                   [ OK ]
Test symbolizer...                              [ OK ]
Test value_object...                            [ OK ]
Test value_string...                            [ OK ]
Test value_unicode...                           [ OK ]
SUCCESS: All unit tests have passed.

@Swatinem
Copy link
Copy Markdown
Contributor

So the tests themselves are passing. It’s just that the unit tests do a few init/shutdown internally, which can’t be done cleanly with crashpad. Ideally, the unit tests should be built without a backend, so this becomes irrelevant.

Please sync up with the latest master, and try to integrate the building into the new pipelines/pytest matrix. Both authoring the tests this way, and the output it generates is a bit meh, but it would be nice to streamline that stuff.

Co-Authored-By: Arpad Borsos <arpad.borsos@googlemail.com>
@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 23, 2020

https://dev.azure.com/gvara/sentry-native/_build/results?buildId=32&view=logs&j=cabecbaf-ef53-5b05-6522-b652bd51d68f&t=85420cc0-f9b9-57e6-bc8b-bf21b882814e

Well, the pytest tests seems to be built automatically with Visual Studio which is not what we want... And sentry_exemple.exe fails too, I guess I have to do more local testing.

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 24, 2020

https://dev.azure.com/gvara/sentry-native/_build/results?buildId=58&view=logs&j=3e1f1b51-d184-5f5a-906a-d9e9ce13cd6b Yeeeeeepa ! Let's see the automatic tests here, but we should be good to go !

@Amphaal Amphaal marked this pull request as ready for review March 24, 2020 10:46
@Swatinem
Copy link
Copy Markdown
Contributor

Nice! Can you add the new supported platform to the README as well?

@jan-auer WDYT?

@Swatinem Swatinem merged commit 8d1eb0d into getsentry:master Mar 25, 2020
@Swatinem
Copy link
Copy Markdown
Contributor

@Amphaal We have a few problems lately with mingw builds hanging and timing out after an hour. Not quite sure whats the problem there…

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 25, 2020

@Amphaal We have a few problems lately with mingw builds hanging and timing out after an hour. Not quite sure whats the problem there…

It must be related with the LLVM linker msys2/MINGW-packages#6126. Let me find a workaround.

@Amphaal
Copy link
Copy Markdown
Contributor Author

Amphaal commented Mar 25, 2020

Well since LLVM 10 is officially out (and might fix our issue), it's a question of time before it gets ported on MSYS2. Maybe we should disable the MinGW CI until https://packages.msys2.org/package/mingw-w64-x86_64-lld v10.0.0 goes live ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants