Sort out MacOS problems #15
Comments
|
I "fixed" the cmake issue with Catch2 (mentioned in issue #1) by installing catch2 independently with FYI, Geant4 builds on my machine just fine. |
|
I made some progress here. I managed to install nain4 by changing the order in |
Sounds very plausible. Catch2 was originally entirely header-based. IIRC, v3 turns it into a library.
You mean from
Given that the tests are the sanity check that confirms that it's worth carrying on trying to use your current installation of n4 at all, and that getting people into the habit of writing automated tests for G4 is half of the point of n4's existence, I'm reluctant to spend resources on this. If anything, I'd prefer to spend the time on upgrading the catch2 version used by n4. But, in the immediate short-term ... you already have Nix, right? How about trying to get Catch2 v2 with one of the following?
All the above use the new 'experimental' nix command. There are equivalents for legacy Nix, but I don't remember them off the top of my head. Anyway, it's just a question of adding BTW, elsewhere you said that flakes are experimental. While this is strictly true, nothing significant has changed in them for years, and far too many people in the Nix world already depend on them for far too many things, and they are so much better than the old way of doing things, so it's almost guaranteed that flakes aren't going to change in any significant backwards-incompatible way. |
Can you show exactly what you have, or a diff, whichever is more concise? |
Still can't find The diff of what works for me right now is: < find_package(Catch2 REQUIRED)
< set(ALL_TEST_SOURCES
< test/catch2-main-test.cc
< # ${Nain4_SOURCES}
< # ${Nain4_HEADERS}
< ${Nain4_TESTS}
< )
---
> # find_package(Catch2 REQUIRED)
> # set(ALL_TEST_SOURCES
> # test/catch2-main-test.cc
> # # ${Nain4_SOURCES}
> # # ${Nain4_HEADERS}
> # ${Nain4_TESTS}
> # )
66,67c66,67
< # TODO including headers in add_executable apparently makes them show up in IDEs. Verify how?
< add_executable(nain4-tests ${ALL_TEST_SOURCES})
---
> # # TODO including headers in add_executable apparently makes them show up in IDEs. Verify how?
> # add_executable(nain4-tests ${ALL_TEST_SOURCES})
71c71
< nain4-tests
---
> Nain4
73c73
< Catch2::Catch2
---
> # Catch2::Catch2
75d74
< Nain4
86,87c85,86
< include(Catch)
< catch_discover_tests(nain4-tests)
---
> # include(Catch)
> # catch_discover_tests(nain4-tests) |
|
It doesn't look like it's a problem of an old build product, I cleared everything and I get the same error. One other thing is that, as you can see from the diff, I need to put "Nain4" as the first line in |
It may not be right now, but I'm pretty sure that some of the errors you showed around the time you were swapping between catch v2 and v3 looked very much like it. There are too many orthogonal differences between what you have and what we have, for me to be able to reason about anything: too many combinations to take into account. We're in the process of finalizing the Catch v3 version. I suggest you try again one we've merged that. It should remove at least one degree of freedom from the problem, making it more tractable. |
|
The Catch2 v3 version-using code has been merged, and tagged with
When I tried moving But your diff had irrelevant changes related to removal of Catch2. Could you try with the new version, which will hopefully give us a diff that only addresses a single, self-contained change. |
|
I have an increasing suspicion that all of these problems are related to inconsistencies between cmake on MacOS and cmake on Linux. Or rather, the need to do things differently in cmake on MacOS and Linux. Do we know anybody who has experience with this sort of thing? |
|
I've just realized that I overlooked something important/obvious here: I have fixed that now: before 3dcd208, the output of This should get us past the error linked above, but we have other problems beyond it. @soleti Could you please try This tries to compile and run G4's example
|
|
Ok, now I was able to install it with Nix (although it had to download 3GB of stuff...). I also get segmentation fault. Using lldb (which I am not familiar with, gdb is still not available on Silicon) I get: Process 7764 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0000000000000000
error: memory read failed for 0x0
Target 0: (exampleB1) stopped.Going (lldb) up
frame #1: 0x0000000102849bb8 libc++.1.0.dylib`std::__1::__stdinbuf<char>::imbue(std::__1::locale const&) + 52
libc++.1.0.dylib`std::__1::__stdinbuf<char>::imbue:
-> 0x102849bb8 <+52>: str w0, [x19, #0x58]
0x102849bbc <+56>: ldr x0, [x19, #0x48]
0x102849bc0 <+60>: ldr x8, [x0]
0x102849bc4 <+64>: ldr x8, [x8, #0x38]
(lldb) up
frame #2: 0x000000010284941c libc++.1.0.dylib`std::__1::DoIOSInit::DoIOSInit() + 148
libc++.1.0.dylib`std::__1::DoIOSInit::DoIOSInit:
-> 0x10284941c <+148>: add x0, sp, #0x10
0x102849420 <+152>: bl 0x10284b034 ; std::__1::locale::~locale()
0x102849424 <+156>: nop
0x102849428 <+160>: ldr x8, #0x6ed40 ; (void *)0x00000001031743d0: vtable for std::__1::basic_istream<char, std::__1::char_traits<char> >
(lldb)
frame #3: 0x000000010284a9d4 libc++.1.0.dylib`_GLOBAL__I_000100 + 72
libc++.1.0.dylib`:
-> 0x10284a9d4 <+72>: adr x0, #-0xf58 ; std::__1::DoIOSInit::~DoIOSInit()
0x10284a9d8 <+76>: nop
0x10284a9dc <+80>: adr x2, #-0x369dc
0x10284a9e0 <+84>: nop
(lldb)
frame #4: 0x00000001a0b4c1e0 dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
dyld`invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const:
-> 0x1a0b4c1e0 <+168>: add x0, sp, #0x10
0x1a0b4c1e4 <+172>: bl 0x1a0b2ba90 ; dyld3::ScopedTimer::endTimer()
0x1a0b4c1e8 <+176>: ldp x29, x30, [sp, #0xa0]
0x1a0b4c1ec <+180>: ldp x20, x19, [sp, #0x90]
(lldb)
frame #5: 0x00000001a0b8dc60 dyld`invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 172
dyld`invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const:
-> 0x1a0b8dc60 <+172>: add x21, x21, #0x8
0x1a0b8dc64 <+176>: cmp x21, x22
0x1a0b8dc68 <+180>: b.lo 0x1a0b8dbf0 ; <+60>
0x1a0b8dc6c <+184>: b 0x1a0b8dd2c ; <+376>
(lldb)
frame #6: 0x00000001a0b811a4 dyld`invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 528
dyld`invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const:
-> 0x1a0b811a4 <+528>: ldrb w8, [x19]
0x1a0b811a8 <+532>: cbnz w8, 0x1a0b81308 ; <+884>
0x1a0b811ac <+536>: add x8, x25, #0x50
0x1a0b811b0 <+540>: cmp x25, x23
(lldb)
frame #7: 0x00000001a0b2c2d8 dyld`dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 296
dyld`dyld3::MachOFile::forEachLoadCommand:
-> 0x1a0b2c2d8 <+296>: ldrb w8, [sp, #0x3f]
0x1a0b2c2dc <+300>: cbnz w8, 0x1a0b2c25c ; <+172>
0x1a0b2c2e0 <+304>: add w22, w22, #0x1
0x1a0b2c2e4 <+308>: ldr w8, [x20, #0x10]
(lldb)
frame #8: 0x00000001a0b801cc dyld`dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 192
dyld`dyld3::MachOFile::forEachSection:
-> 0x1a0b801cc <+192>: sub x0, x29, #0x38
0x1a0b801d0 <+196>: bl 0x1a0b2c354 ; Diagnostics::assertNoError() const
0x1a0b801d4 <+200>: add x0, sp, #0x48
0x1a0b801d8 <+204>: mov w1, #0x8
(lldb)
frame #9: 0x00000001a0b82cfc dyld`dyld3::MachOFile::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, bool&) block_pointer) const + 160
dyld`dyld3::MachOFile::forEachInitializerPointerSection:
-> 0x1a0b82cfc <+160>: ldp x29, x30, [sp, #0x60]
0x1a0b82d00 <+164>: ldp x20, x19, [sp, #0x50]
0x1a0b82d04 <+168>: ldp x22, x21, [sp, #0x40]
0x1a0b82d08 <+172>: add sp, sp, #0x70
(lldb)
frame #10: 0x00000001a0b8d904 dyld`dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 432
dyld`dyld3::MachOAnalyzer::forEachInitializer:
-> 0x1a0b8d904 <+432>: mov x8, sp
0x1a0b8d908 <+436>: adrp x16, 374721
0x1a0b8d90c <+440>: add x16, x16, #0xed8 ; _NSConcreteStackBlock
0x1a0b8d910 <+444>: mov x17, x8
(lldb)
frame #11: 0x00000001a0b48864 dyld`dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 448
dyld`dyld4::Loader::findAndRunAllInitializers:
-> 0x1a0b48864 <+448>: ldrb w8, [x21, #0x21]
0x1a0b48868 <+452>: cbz w8, 0x1a0b48924 ; <+640>
0x1a0b4886c <+456>: add x8, sp, #0x68
0x1a0b48870 <+460>: add x8, x8, #0x8
(lldb)
frame #12: 0x00000001a0b48c18 dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 220
dyld`dyld4::Loader::runInitializersBottomUp:
-> 0x1a0b48c18 <+220>: ldp x29, x30, [sp, #0x40]
0x1a0b48c1c <+224>: ldp x20, x19, [sp, #0x30]
0x1a0b48c20 <+228>: ldp x22, x21, [sp, #0x20]
0x1a0b48c24 <+232>: ldp x24, x23, [sp, #0x10]
(lldb)
frame #13: 0x00000001a0b48bf4 dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 184
dyld`dyld4::Loader::runInitializersBottomUp:
-> 0x1a0b48bf4 <+184>: add w23, w23, #0x1
0x1a0b48bf8 <+188>: cmp w23, w22
0x1a0b48bfc <+192>: b.ne 0x1a0b48b80 ; <+68>
0x1a0b48c00 <+196>: mov x0, x19
(lldb)
frame #14: 0x00000001a0b4c26c dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_1::operator()() const + 112
dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_1::operator()() const:
-> 0x1a0b4c26c <+112>: ldr x1, [x19]
0x1a0b4c270 <+116>: ldr x8, [x1, #0x30]
0x1a0b4c274 <+120>: lsl x12, x8, #3
0x1a0b4c278 <+124>: add x9, x12, #0x8
(lldb)
frame #15: 0x00000001a0b48d98 dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 304
dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks:
-> 0x1a0b48d98 <+304>: ldrb w8, [x19, #0x21]
0x1a0b48d9c <+308>: cbz w8, 0x1a0b48e58 ; <+496>
0x1a0b48da0 <+312>: add x8, sp, #0x8
0x1a0b48da4 <+316>: add x8, x8, #0x8
(lldb)
frame #16: 0x00000001a0b6c984 dyld`dyld4::APIs::runAllInitializersForMain() + 468
dyld`dyld4::APIs::runAllInitializersForMain:
-> 0x1a0b6c984 <+468>: mov x0, x20
0x1a0b6c988 <+472>: mov x1, x19
0x1a0b6c98c <+476>: bl 0x1a0b44b04 ; dyld4::Loader::analyzer(dyld4::RuntimeState&) const
0x1a0b6c990 <+480>: bl 0x1a0b7fea0 ; dyld3::MachOFile::isMainExecutable() const
(lldb)
frame #17: 0x00000001a0b312d0 dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3480
dyld`dyld4::prepare:
-> 0x1a0b312d0 <+3480>: bl 0x1a0b6aa7c ; dyld4::notifyMonitoringDyldMain()
0x1a0b312d4 <+3484>: mov w0, #0x4
0x1a0b312d8 <+3488>: movk w0, #0x1f07, lsl #16
0x1a0b312dc <+3492>: bl 0x1a0b2bdc0 ; dyld3::kdebug_trace_dyld_enabled(unsigned int)
(lldb)
frame #18: 0x00000001a0b2fe18 dyld`start + 1964
dyld`start:
-> 0x1a0b2fe18 <+1964>: mov x19, x0
0x1a0b2fe1c <+1968>: ldrb w8, [sp, #0xb1]
0x1a0b2fe20 <+1972>: cbnz w8, 0x1a0b2fe88 ; <+2076>
0x1a0b2fe24 <+1976>: ldrb w8, [sp, #0xb0]
(lldb)
error: Already at the top of the stack. |
|
Thanks. I don't find the output very illuminating, either. I'll try to look at it in more detail, later. If you can spare some time, maybe you can perform a sanity check: grab Footnotes
|
|
Compiling that example in my usual way doesn't give me segfault. The example runs fine. |
|
Thanks. Just to be absolutely sure, your usual way does actually use the cmake configuration supplied in the example, rather than, for example, a Nexus-supplied/inspired SCons approach? |
|
Yes, I do use the cmake configuration in the example. |
|
Hi @soleti, we are experimenting with macos. Can you try to compile and execute the following code using your non-nix G4 installation? CMakeLists.txt main.cc compile and execute: |
|
@gonzaponte that minimal example works on my machine |
Bizarre MacOS failures in
cmakeand in GHA, are diverting the time and energy of the only 2 people currently contributing to the project. As neither of these people have access to a machine running MacOS, it's difficult to make any progress on trying to fix these problems.Yes, getting
nain4to work smoothly for people using MacOS is crucial, but I don't think it's a good use of the 2 developers' time, at this very moment, to divert our limited resources away from all the other work that needs to be done urgently.I will therefore allow the GHA MacOS job to fail, and I will ignore all MacOS problems until some progress has been made in other areas, especially getting the most important parts of the documentation written and published.
If anyone who actually has a Mac wants to have a go at working on this, that would be very welcome, and we could offer help. But without access to a Mac, this simply has to be given a much lower priority, for a while.
The text was updated successfully, but these errors were encountered: