Thread overview
ldmd2 isn't built for ldc 1.8.0-beta1
Feb 25, 2018
Thomas Mader
Feb 25, 2018
kinke
Feb 26, 2018
Thomas Mader
Feb 26, 2018
kinke
Feb 26, 2018
Thomas Mader
Feb 26, 2018
kinke
Mar 03, 2018
Thomas Mader
Mar 04, 2018
Thomas Mader
February 25, 2018
The package build script for ldc for the Nix package manager produced the ldmd2 binary in the bin directory next to the ldc binary.
With this beta the binary is missing. Don't have a clue why it isn't build anymore.

February 25, 2018
On Sunday, 25 February 2018 at 18:37:52 UTC, Thomas Mader wrote:
> The package build script for ldc for the Nix package manager produced the ldmd2 binary in the bin directory next to the ldc binary.
> With this beta the binary is missing. Don't have a clue why it isn't build anymore.

I don't remember any relevant changes. The make/ninja target is 'ldmd2' and it's included in the 'all' target.
February 26, 2018
On Sunday, 25 February 2018 at 20:26:03 UTC, kinke wrote:
> On Sunday, 25 February 2018 at 18:37:52 UTC, Thomas Mader wrote:
>> The package build script for ldc for the Nix package manager produced the ldmd2 binary in the bin directory next to the ldc binary.
>> With this beta the binary is missing. Don't have a clue why it isn't build anymore.
>
> I don't remember any relevant changes. The make/ninja target is 'ldmd2' and it's included in the 'all' target.

I looked more into it and the ldmd2 binary is produced but some tests fail because they use another path to ldmd2 which is not available anymore.
Now I wonder why those tests don't use the ldmd2 I am using to build everything and all other tests use which are successful.

788/790 Test #788: druntime-test-typeinfo ......................................................***Failed    0.01 sec
make: Entering directory '/private/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/runtime/druntime/test/typeinfo'
/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/bin/ldmd2   -w -I../../src -I../../import -Isrc -defaultlib= -debuglib= -dip1000 -L/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/lib/libdruntime-ldc.a -O -release -of/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/runtime/druntime-test-typeinfo/comparison src/comparison.d
make: /tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/bin/ldmd2: Command not found
make: *** [Makefile:14: /tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/runtime/druntime-test-typeinfo/comparison] Error 127
make: Leaving directory '/private/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/runtime/druntime/test/typeinfo'

789/790 Test #790: druntime-test-unittest ......................................................***Failed    0.01 sec
make: Entering directory '/private/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/runtime/druntime/test/unittest'
Testing good
/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/bin/ldmd2   -w -I../../src -I../../import -Isrc -defaultlib= -debuglib= -dip1000 -L/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/lib/libdruntime-ldc.a -O -release -of/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/runtime/druntime-test-unittest/tester_good customhandler.d -version=PassNoPrintout
make: /tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/bin/ldmd2: Command not found
make: *** [Makefile:37: /tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/build/runtime/druntime-test-unittest/good.done] Error 127
make: Leaving directory '/private/tmp/nix-build-ldcUnittests-1.8.0-beta1.drv-2/ldc-1.8.0-beta1-src/runtime/druntime/test/unittest'

790/790 Test #754: std.socket-debug ............................................................   Passed    4.90 sec

99% tests passed, 10 tests failed out of 790

Total Test time (real) =  34.61 sec

The following tests FAILED:
	772 - druntime-test-allocations (Failed)
	774 - druntime-test-coverage (Failed)
	776 - druntime-test-cycles (Failed)
	778 - druntime-test-exceptions (Failed)
	780 - druntime-test-imports (Failed)
	782 - druntime-test-init_fini (Failed)
	784 - druntime-test-profile (Failed)
	786 - druntime-test-thread (Failed)
	788 - druntime-test-typeinfo (Failed)
	790 - druntime-test-unittest (Failed)
Errors while running CTest

February 26, 2018
On Monday, 26 February 2018 at 18:16:50 UTC, Thomas Mader wrote:
> I looked more into it and the ldmd2 binary is produced but some tests fail because they use another path to ldmd2 which is not available anymore.
> Now I wonder why those tests don't use the ldmd2 I am using to build everything and all other tests use which are successful.

Those druntime standalone tests have been introduced in v1.8. They use the same ldmd2 executable as dmd-testsuite, i.e., not the one in the installation dir, but the one in the build dir. See runtime/StandaloneDRuntimeTests.cmake.
All other tests use the ldc2 executable (in the build dir).
February 26, 2018
On Monday, 26 February 2018 at 18:31:29 UTC, kinke wrote:
> Those druntime standalone tests have been introduced in v1.8. They use the same ldmd2 executable as dmd-testsuite, i.e., not the one in the installation dir, but the one in the build dir. See runtime/StandaloneDRuntimeTests.cmake.
> All other tests use the ldc2 executable (in the build dir).

Ok this is the problem. I need to run the druntime and phobos tests independently from the main build and the other tests and this way the ldmd2 binary isn't produced.
Any way to work around that?
In the second stage I am doing this:

make -j$NIX_BUILD_CORES DMD=${ldcBuild.out}/bin/ldc2 druntime-test-runner druntime-test-runner-debug phobos2-test-runner phobos2-test-runner-debug

ctest -j$NIX_BUILD_CORES --output-on-failure -E \"dmd-testsuite|lit-tests|ldc2-unittest\"

For completeness, here are the checks I am doing in the first stage which should include all other tests:

        # Build and run LDC D unittests.
        ctest --output-on-failure -R "ldc2-unittest"
        # Run LIT testsuite.
        ctest -V -R "lit-tests"
        # Run DMD testsuite.
        DMD_TESTSUITE_MAKE_ARGS=-j$NIX_BUILD_CORES ctest -V -R "dmd-testsuite"

February 26, 2018
On Monday, 26 February 2018 at 19:20:42 UTC, Thomas Mader wrote:
> Ok this is the problem. I need to run the druntime and phobos tests independently from the main build and the other tests and this way the ldmd2 binary isn't produced.
> Any way to work around that?
> In the second stage I am doing this:
>
> make -j$NIX_BUILD_CORES DMD=${ldcBuild.out}/bin/ldc2 druntime-test-runner druntime-test-runner-debug phobos2-test-runner phobos2-test-runner-debug
>
> ctest -j$NIX_BUILD_CORES --output-on-failure -E \"dmd-testsuite|lit-tests|ldc2-unittest\"
>
> For completeness, here are the checks I am doing in the first stage which should include all other tests:
>
>         # Build and run LDC D unittests.
>         ctest --output-on-failure -R "ldc2-unittest"
>         # Run LIT testsuite.
>         ctest -V -R "lit-tests"
>         # Run DMD testsuite.
>         DMD_TESTSUITE_MAKE_ARGS=-j$NIX_BUILD_CORES ctest -V -R "dmd-testsuite"

Well then try moving the druntime standalone tests to the first stage by adjusting the regex - something like `ctest -R "^druntime-test-"` as extra step in the first stage and excluding it via `ctest -E "...|^druntime-test-"` in the 2nd.
March 03, 2018
On Monday, 26 February 2018 at 21:08:43 UTC, kinke wrote:
> Well then try moving the druntime standalone tests to the first stage by adjusting the regex - something like `ctest -R "^druntime-test-"` as extra step in the first stage and excluding it via `ctest -E "...|^druntime-test-"` in the 2nd.

First stage ran through just fine, the second one though ran the druntime unittests too and deadlocked at the core.atomic tests.

(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff54fbdd8a libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff5517e824 libsystem_pthread.dylib`_pthread_join + 626
    frame #2: 0x0000000105c947b6 druntime-test-runner`_D4core6thread6Thread4joinMFbZC6object9Throwable + 22
    frame #3: 0x0000000105be0b8b druntime-test-runner`_D4core6atomic29__unittest_core_atomic_1842_5FZv + 203
    frame #4: 0x0000000105be24f4 druntime-test-runner`_D4core6atomic10__unittestZ + 100
    frame #5: 0x0000000105bdf754 druntime-test-runner`_D11test_runner6doTestFPS6object10ModuleInfoKS4core7runtime14UnitTestResultZv + 68
    frame #6: 0x0000000105bdf638 druntime-test-runner`_D11test_runner11testModulesFZS4core7runtime14UnitTestResult + 152
    frame #7: 0x0000000105bdf542 druntime-test-runner`_D11test_runner6testerFZS4core7runtime14UnitTestResult + 34
    frame #8: 0x0000000105c8d2a1 druntime-test-runner`runModuleUnitTests + 113
    frame #9: 0x0000000105cf426f druntime-test-runner`_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 31
    frame #10: 0x0000000105cf4173 druntime-test-runner`_d_run_main + 435
    frame #11: 0x00007fff54e6d015 libdyld.dylib`start + 1
  thread #2
    frame #0: 0x0000000105be0bd0 druntime-test-runner`_D4core6atomic29__unittest_core_atomic_1842_5FZ9__lambda1MFZv + 32
    frame #1: 0x0000000105c93bdd druntime-test-runner`thread_entryPoint + 173
    frame #2: 0x00007fff5517a661 libsystem_pthread.dylib`_pthread_body + 340
    frame #3: 0x00007fff5517a50d libsystem_pthread.dylib`_pthread_start + 377
    frame #4: 0x00007fff55179bf9 libsystem_pthread.dylib`thread_start + 13


March 04, 2018
On Saturday, 3 March 2018 at 16:51:50 UTC, Thomas Mader wrote:
> On Monday, 26 February 2018 at 21:08:43 UTC, kinke wrote:
>> Well then try moving the druntime standalone tests to the first stage by adjusting the regex - something like `ctest -R "^druntime-test-"` as extra step in the first stage and excluding it via `ctest -E "...|^druntime-test-"` in the 2nd.
>
> First stage ran through just fine, the second one though ran the druntime unittests too and deadlocked at the core.atomic tests.

I can't get a pure phobos test running in the second stage without some druntime tests failing.
Now I just link the ldmd2 binary to build/bin/ to fix the package build.