www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC for PowerPC64 on FreeBSD

reply Curtis <clhamilto gmail.com> writes:
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.
Sep 25
parent reply kinke <kinke gmx.net> writes:
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.
Sep 25
parent reply Curtis <clhamilto gmail.com> writes:
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?
Sep 25
next sibling parent Curtis <clhamilto gmail.com> writes:
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
Sep 25
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
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.
Sep 25
prev sibling parent reply kinke <noone nowhere.com> writes:
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).
Sep 25
next sibling parent Curtis <clhamilto gmail.com> writes:
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.
Sep 25
prev sibling parent Curtis <clhamilto gmail.com> writes:
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.
Sep 29