I'm attempting to build LDC for PowerPC64 on FreeBSD.  I've been initially successful in building, with some hacks, LDC 0.17.5.  Everything seems to be working, but some issues.

First, when executing the tests, several tests failed do to "Unable to unlock mutex".  Secondly, my attempted to build "dub" resulted in an app that segfaults with signal 11.  Below is the backtrace from debug:

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc64-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `dub'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libcurl.so.4...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libcurl.so.4
Reading symbols from /lib/libthr.so.3...Reading symbols from /usr/lib/debug//lib/libthr.so.3.debug...done.
done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done.
done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /usr/local/lib/gcc5/libgcc_s.so.1...Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/gcc5/libgcc_s.so.1]
Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done.
done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libnghttp2.so.14...done.
Loaded symbols for /usr/local/lib/libnghttp2.so.14
Reading symbols from /usr/local/lib/libssl.so.9...done.
Loaded symbols for /usr/local/lib/libssl.so.9
Reading symbols from /usr/local/lib/libcrypto.so.9...done.
Loaded symbols for /usr/local/lib/libcrypto.so.9
Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done.
done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done.
done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000010435d6c in .llrintl ()
[New Thread 51016000 (LWP 101120/<unknown>)]
(gdb) backtrace
#0  0x0000000010435d6c in .llrintl ()
#1  0x000000001043fa38 in .llrintl ()
#2  0x000000001041db88 in .llrintl ()
#3  0x000000001040daec in .llrintl ()
#4  0x00000000103fbdf0 in .inflate_fast ()
#5  0x000000001003c5c0 in ?? ()
(gdb) frame 4
#4  0x00000000103fbdf0 in .inflate_fast ()
(gdb)

Anyone have an idea of what I should look at?  Thanks in advance.

On Monday, 25 September 2017 at 12:47:29 UTC, Curtis wrote:
> I'm attempting to build LDC for PowerPC64 on FreeBSD.  I've been initially successful in building, with some hacks, LDC 0.17.5.  Everything seems to be working, but some issues.

I'd try to build the newest LDC with your 0.17.5 and then perform the tests with that one; LDC has seen countless fixes (and possibly some regressions ;)) since 0.17.x.

On Monday, 25 September 2017 at 14:02:58 UTC, kinke wrote:
> On Monday, 25 September 2017 at 12:47:29 UTC, Curtis wrote:
>> I'm attempting to build LDC for PowerPC64 on FreeBSD.  I've been initially successful in building, with some hacks, LDC 0.17.5.  Everything seems to be working, but some issues.
>
> I'd try to build the newest LDC with your 0.17.5 and then perform the tests with that one; LDC has seen countless fixes (and possibly some regressions ;)) since 0.17.x.

I successfully built LDC 1.4 with 0.17.5.  However, the tests
freezes when it gets to "core.atomic".  All tests prior to that
pass successfully.

The "atomic.d" modules successfully compile normally, but the
tests seems to choke on it.

Any ideas?

On Monday, 25 September 2017 at 14:37:56 UTC, Curtis wrote:
> On Monday, 25 September 2017 at 14:02:58 UTC, kinke wrote:
>> On Monday, 25 September 2017 at 12:47:29 UTC, Curtis wrote:
>>> I'm attempting to build LDC for PowerPC64 on FreeBSD.  I've been initially successful in building, with some hacks, LDC 0.17.5.  Everything seems to be working, but some issues.
>>
>> I'd try to build the newest LDC with your 0.17.5 and then perform the tests with that one; LDC has seen countless fixes (and possibly some regressions ;)) since 0.17.x.
>
> I successfully built LDC 1.4 with 0.17.5.  However, the tests
> freezes when it gets to "core.atomic".  All tests prior to that
> pass successfully.
>
> The "atomic.d" modules successfully compile normally, but the
> tests seems to choke on it.
>
> Any ideas?

I forgot to mention, i get the same results if I build "dub" with
the new version 1.4.

Regards

On Monday, 25 September 2017 at 14:37:56 UTC, Curtis wrote:
> On Monday, 25 September 2017 at 14:02:58 UTC, kinke wrote:
>> On Monday, 25 September 2017 at 12:47:29 UTC, Curtis wrote:
>>> I'm attempting to build LDC for PowerPC64 on FreeBSD.  I've been initially successful in building, with some hacks, LDC 0.17.5.  Everything seems to be working, but some issues.
>>
>> I'd try to build the newest LDC with your 0.17.5 and then perform the tests with that one; LDC has seen countless fixes (and possibly some regressions ;)) since 0.17.x.
>
> I successfully built LDC 1.4 with 0.17.5.  However, the tests
> freezes when it gets to "core.atomic".  All tests prior to that
> pass successfully.
>
> The "atomic.d" modules successfully compile normally, but the
> tests seems to choke on it.
>
> Any ideas?

I'd pass all druntime modules' names to the test runner manually and leave out core.atomic at first, to see how many other druntime modules have failing tests.  Once those are all working, run the Phobos tests and get those all working, then you can try dub, which builds on Phobos.

As for core.atomic, I see some checks for PPC64 in there.  I dont know anything about FreeBSD/PPC64, but I'd check to make sure that code is right, then run those tests through a debugger to see where it hangs.

On Monday, 25 September 2017 at 14:37:56 UTC, Curtis wrote:
> Any ideas?

Yep, I suspect it has something to do with the 2x64-bit doubledouble floating point format, as your segfault seems to happen in `llrintl()`. We compile the C++ parts of LDC with `-mlong-double-64` (double-precision long double) and use 64-bit D reals (at least with LDC master, not sure about ltsmaster/0.17.x). If your `libm.so` expects doubledoubles, the D real needs to be adapted. IIRC, it might even work out of the box for LDC master. See https://github.com/ldc-developers/ldc/blob/master/CMakeLists.txt#L213 for how to enable 'normal' C long doubles (=> D reals).

On Monday, 25 September 2017 at 19:01:24 UTC, kinke wrote:
> On Monday, 25 September 2017 at 14:37:56 UTC, Curtis wrote:
>> Any ideas?
>
> Yep, I suspect it has something to do with the 2x64-bit doubledouble floating point format, as your segfault seems to happen in `llrintl()`. We compile the C++ parts of LDC with `-mlong-double-64` (double-precision long double) and use 64-bit D reals (at least with LDC master, not sure about ltsmaster/0.17.x). If your `libm.so` expects doubledoubles, the D real needs to be adapted. IIRC, it might even work out of the box for LDC master. See https://github.com/ldc-developers/ldc/blob/master/CMakeLists.txt#L213 for how to enable 'normal' C long doubles (=> D reals).

Thanks! I'd noticed that code in CMakeLists.txt, but thought it was only appropriate for powerpc vice powerpc64.  I'll give it a try and report back.

On Monday, 25 September 2017 at 19:01:24 UTC, kinke wrote:
> On Monday, 25 September 2017 at 14:37:56 UTC, Curtis wrote:
>> Any ideas?
>
> Yep, I suspect it has something to do with the 2x64-bit doubledouble floating point format, as your segfault seems to happen in `llrintl()`. We compile the C++ parts of LDC with `-mlong-double-64` (double-precision long double) and use 64-bit D reals (at least with LDC master, not sure about ltsmaster/0.17.x). If your `libm.so` expects doubledoubles, the D real needs to be adapted. IIRC, it might even work out of the box for LDC master. See https://github.com/ldc-developers/ldc/blob/master/CMakeLists.txt#L213 for how to enable 'normal' C long doubles (=> D reals).

I've tried all of the above and still experiencing the same issues.

Any more thoughts?

Thanks in advance.