Hi all,

The ldc package on Debian has just reported 3 build failures:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754689 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754690

One is for PowerPC:

| /«PKGBUILDDIR»/bin/ldc2 --output-o -c
| -I/«PKGBUILDDIR»/runtime/druntime/src
| -I/«PKGBUILDDIR»/runtime/druntime/src/gc /«PKGBUILDDIR»/runtime/druntime/src/core/thread.d
| -of/«PKGBUILDDIR»/runtime/src/core/thread.o -w -d -O3 -release
| -disable-invariants /«PKGBUILDDIR»/runtime/druntime/src/core/thread.d
| (2101): Error: static assert  "Architecture not supported." make[3]:
| *** [runtime/src/core/thread.o] Error 1

And the other for kfreebsd-i386/kfreebsd-amd64:

| /usr/bin/c++   -g -O2     CMakeFiles/ldc2.dir/driver/cl_options.cpp.o
| CMakeFiles/ldc2.dir/driver/configfile.cpp.o
| CMakeFiles/ldc2.dir/driver/targetmachine.cpp.o
| CMakeFiles/ldc2.dir/driver/toobj.cpp.o
| CMakeFiles/ldc2.dir/driver/tool.cpp.o
| CMakeFiles/ldc2.dir/driver/linker.cpp.o
| CMakeFiles/ldc2.dir/driver/main.cpp.o
| CMakeFiles/ldc2.dir/driver/ldc-version.cpp.o  -o bin/ldc2
| lib/libldc.so -lconfig++ -lpthread -ldl
| -ltinfo /usr/lib/llvm-3.4/lib/libLLVMAsmParser.a /usr/lib/llvm-3.4/lib/libLLVMTableGen.a /usr/lib/llvm-3.4/lib/libLLVMInstrumentation.a /usr/lib/llvm-3.4/lib/libLLVMipo.a /usr/lib/llvm-3.4/lib/libLLVMVectorize.a /usr/lib/llvm-3.4/lib/libLLVMLinker.a /usr/lib/llvm-3.4/lib/libLLVMBitWriter.a /usr/lib/llvm-3.4/lib/libLLVMR600CodeGen.a /usr/lib/llvm-3.4/lib/libLLVMR600Desc.a /usr/lib/llvm-3.4/lib/libLLVMR600Info.a /usr/lib/llvm-3.4/lib/libLLVMR600AsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMSystemZDisassembler.a /usr/lib/llvm-3.4/lib/libLLVMSystemZCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMSystemZAsmParser.a /usr/lib/llvm-3.4/lib/libLLVMSystemZDesc.a /usr/lib/llvm-3.4/lib/libLLVMSystemZInfo.a /usr/lib/llvm-3.4/lib/libLLVMSystemZAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMHexagonCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMHexagonAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMHexagonDesc.a /usr/lib/llvm-3.4/lib/libLLVMHexagonInfo.a /usr/lib/llvm-3.4/lib/libLLVMNVPTXCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMNVPTXDesc.a /usr/lib/llvm-3.4/lib/libLLVMNVPTXInfo.a /usr/lib/llvm-3.4/lib/libLLVMNVPTXAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMCppBackendCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMCppBackendInfo.a /usr/lib/llvm-3.4/lib/libLLVMMSP430CodeGen.a /usr/lib/llvm-3.4/lib/libLLVMMSP430Desc.a /usr/lib/llvm-3.4/lib/libLLVMMSP430Info.a /usr/lib/llvm-3.4/lib/libLLVMMSP430AsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMXCoreDisassembler.a /usr/lib/llvm-3.4/lib/libLLVMXCoreCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMXCoreDesc.a /usr/lib/llvm-3.4/lib/libLLVMXCoreInfo.a /usr/lib/llvm-3.4/lib/libLLVMXCoreAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMMipsDisassembler.a /usr/lib/llvm-3.4/lib/libLLVMMipsCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMMipsAsmParser.a /usr/lib/llvm-3.4/lib/libLLVMMipsDesc.a /usr/lib/llvm-3.4/lib/libLLVMMipsInfo.a /usr/lib/llvm-3.4/lib/libLLVMMipsAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMARMDisassembler.a /usr/lib/llvm-3.4/lib/libLLVMARMCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMARMAsmParser.a /usr/lib/llvm-3.4/lib/libLLVMARMDesc.a /usr/lib/llvm-3.4/lib/libLLVMARMInfo.a /usr/lib/llvm-3.4/lib/libLLVMARMAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMAArch64Disassembler.a /usr/lib/llvm-3.4/lib/libLLVMAArch64CodeGen.a /usr/lib/llvm-3.4/lib/libLLVMAArch64AsmParser.a /usr/lib/llvm-3.4/lib/libLLVMAArch64Desc.a /usr/lib/llvm-3.4/lib/libLLVMAArch64Info.a /usr/lib/llvm-3.4/lib/libLLVMAArch64AsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMAArch64Utils.a /usr/lib/llvm-3.4/lib/libLLVMPowerPCCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMPowerPCAsmParser.a /usr/lib/llvm-3.4/lib/libLLVMPowerPCDesc.a /usr/lib/llvm-3.4/lib/libLLVMPowerPCInfo.a /usr/lib/llvm-3.4/lib/libLLVMPowerPCAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMSparcCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMSparcDesc.a /usr/lib/llvm-3.4/lib/libLLVMSparcInfo.a /usr/lib/llvm-3.4/lib/libLLVMX86Disassembler.a /usr/lib/llvm-3.4/lib/libLLVMX86AsmParser.a /usr/lib/llvm-3.4/lib/libLLVMX86CodeGen.a /usr/lib/llvm-3.4/lib/libLLVMSelectionDAG.a /usr/lib/llvm-3.4/lib/libLLVMAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMMCParser.a /usr/lib/llvm-3.4/lib/libLLVMCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMObjCARCOpts.a /usr/lib/llvm-3.4/lib/libLLVMScalarOpts.a /usr/lib/llvm-3.4/lib/libLLVMInstCombine.a /usr/lib/llvm-3.4/lib/libLLVMTransformUtils.a /usr/lib/llvm-3.4/lib/libLLVMipa.a /usr/lib/llvm-3.4/lib/libLLVMAnalysis.a /usr/lib/llvm-3.4/lib/libLLVMX86Desc.a /usr/lib/llvm-3.4/lib/libLLVMX86Info.a /usr/lib/llvm-3.4/lib/libLLVMTarget.a /usr/lib/llvm-3.4/lib/libLLVMX86AsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMMC.a /usr/lib/llvm-3.4/lib/libLLVMObject.a /usr/lib/llvm-3.4/lib/libLLVMX86Utils.a /usr/lib/llvm-3.4/lib/libLLVMCore.a /usr/lib/llvm-3.4/lib/libLLVMSupport.a
| -L/usr/lib/llvm-3.4/lib  -lpthread -lffi -ltinfo -ldl -lm -lpthread
| -ltinfo -Wl,-rpath,/«PKGBUILDDIR»/lib:
| CMakeFiles/ldc2.dir/driver/main.cpp.o: In function
| `main': /«PKGBUILDDIR»/driver/main.cpp:1055: undefined reference to
| `Port::stricmp(char const*, char
| const*)' /«PKGBUILDDIR»/driver/main.cpp:1056: undefined reference to
| `Port::stricmp(char const*, char const*)' lib/libldc.so: undefined
| reference to `Port::memicmp(char const*, char const*, int)'
| lib/libldc.so: undefined reference to `Port::ldbl_max' lib/libldc.so:
| undefined reference to `Port::strtod(char const*, char**)'
| lib/libldc.so: undefined reference to `Port::isNan(long double)'
| lib/libldc.so: undefined reference to `Port::strtof(char
| const*,ExternStackShell char**)' lib/libldc.so: undefined reference
| to `Port::isInfinity (double)' lib/libldc.so: undefined reference to
| `Port::fequal(long double, long double)' lib/libldc.so: undefined
| reference to `Port::strtold(char const*, char**)' lib/libldc.so:
| undefined reference to `Port::fmodl(long double, long double)'
| lib/libldc.so: undefined reference to `Port::ldbl_nan' lib/libldc.so:
| undefined reference to `Port::ldbl_infinity' lib/libldc.so: undefined
| reference to `Port::snan' collect2: error: ld returned 1 exit status

I can work on the PowerPC one as I do have access to a Power7
Debian system -in fact I tried to fix the missing ExternStackShell
callee-save code (just tried saving GPR13-30 and GPR1) by adding some
inline asm, but the compiler failed to parse this file complaining that
I cannot use inline asm in PowerPC. Any ideas?

I guess the PowerPC port is easy to fix, and probably the kfreebsd-* ports as well. In fact looking at past build history of the package, I see that it was built on all architectures before ([1] no idea if it was actually working on all of them, but it was built). If there is no interest in fixing support for some ports, I can just remove them from the architecture list and be done with it, but if there is a case that ldc may be working again on them, then I'd be happy to give it a shot.

Regards

Konstantinos

[1] https://buildd.debian.org/status/package.php?p=ldc&suite=squeeze

Hi Konstantinos!

On Monday, 14 July 2014 at 17:23:33 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
>
> Hi all,
>
> The ldc package on Debian has just reported 3 build failures:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754689
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754690
>
> One is for PowerPC:
> [...]

PowerPC 32bit is still work in progress. PowerPC64 bit is supposed to work. But there is an issue with 0.13.0 release which is fixed in master branch.

>
> And the other for kfreebsd-i386/kfreebsd-amd64:
> [...]
> | `main': /«PKGBUILDDIR»/driver/main.cpp:1055: undefined reference to
> | `Port::stricmp(char const*, char
> | const*)' /«PKGBUILDDIR»/driver/main.cpp:1056: undefined reference to
> | `Port::stricmp(char const*, char const*)' lib/libldc.so: undefined
> | reference to `Port::memicmp(char const*, char const*, int)'
> | lib/libldc.so: undefined reference to `Port::ldbl_max' lib/libldc.so:
> | undefined reference to `Port::strtod(char const*, char**)'
> | lib/libldc.so: undefined reference to `Port::isNan(long double)'
> | lib/libldc.so: undefined reference to `Port::strtof(char
> | const*,ExternStackShell char**)' lib/libldc.so: undefined reference
> | to `Port::isInfinity (double)' lib/libldc.so: undefined reference to
> | `Port::fequal(long double, long double)' lib/libldc.so: undefined
> | reference to `Port::strtold(char const*, char**)' lib/libldc.so:
> | undefined reference to `Port::fmodl(long double, long double)'
> | lib/libldc.so: undefined reference to `Port::ldbl_nan' lib/libldc.so:
> | undefined reference to `Port::ldbl_infinity' lib/libldc.so: undefined
> | reference to `Port::snan' collect2: error: ld returned 1 exit status

This seems to be an issue with root/port.c. If these functions are missing then the conditions to choose the implementation are not complete.

> I can work on the PowerPC one as I do have access to a Power7
> Debian system -in fact I tried to fix the missing ExternStackShell
> callee-save code (just tried saving GPR13-30 and GPR1) by adding some
> inline asm, but the compiler failed to parse this file complaining that
> I cannot use inline asm in PowerPC. Any ideas?
>
> I guess the PowerPC port is easy to fix, and probably the kfreebsd-*
> ports as well. In fact looking at past build history of the package, I
> see that it was built on all architectures before ([1] no idea if it was
> actually working on all of them, but it was built). If there is no
> interest in fixing support for some ports, I can just remove them from
> the architecture list and be done with it, but if there is a case that
> ldc may be working again on them, then I'd be happy to give it a shot.

I have some patches for PowerPC 32 bit:
http://www.redstar.de/ldc/ppc_druntime.diff
http://www.redstar.de/ldc/ppc_phobos.diff

They try to fix some parts and comment out not yet working asserts. std.math is notorius here.

>
> Regards
>
> Konstantinos
>
> [1] https://buildd.debian.org/status/package.php?p=ldc&suite=squeeze

Regards,
Kai

On Tue, 15 Jul 2014 06:02:16 +0000
Kai Nacke via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:

> PowerPC 32bit is still work in progress. PowerPC64 bit is supposed to work. But there is an issue with 0.13.0 release which is fixed in master branch.

Ok, since the machine I have access to is a Power7, I guess I could try a powerpc64 build after that as well.

> This seems to be an issue with root/port.c. If these functions are missing then the conditions to choose the implementation are not complete.

Ok, I will try to get access to a kfreebsd-* system to try to figure it
out.

> I have some patches for PowerPC 32 bit: http://www.redstar.de/ldc/ppc_druntime.diff http://www.redstar.de/ldc/ppc_phobos.diff
> 
> They try to fix some parts and comment out not yet working asserts. std.math is notorius here.

Ok, these seemed to do the trick, but another std.math build failure in
floor():

/home/markos/ldc-0.13.0/runtime/phobos/std/math.d(3199): Error: static
assert  "Only 64-bit, 80-bit, and 128-bit reals are supported by floor
()"

Does this mean that the powerpc32 port does not have support for 64-bit floats?

Anyways thanks for your help.

Regards

Konstantinos

On Tue, 15 Jul 2014 10:13:31 +0300
Konstantinos Margaritis via digitalmars-d-ldc
<digitalmars-d-ldc@puremagic.com> wrote:

> Ok, I will try to get access to a kfreebsd-* system to try to figure it out.

Ok, I think I understand what's wrong here. Debian kfreeBSD-* ports don't define __FreeBSD__ which means all those port-specific code is never executed. I checked in some kfreebsd-* port wikis and found that I should instead check for __FreeBSD_kernel__ instead of plain __FreeBSD__. So I did that and the compile moved further, however when building runtime I got this:

[ 12%] Generating src/core/bitop.o
/home/markos/ldc-0.13.0/bin/ldc2 --output-o -c
-I/home/markos/ldc-0.13.0/runtime/druntime/src
-I/home/markos/ldc-0.13.0/runtime/druntime/src/gc /home/markos/ldc-0.13.0/runtime/druntime/src/core/bitop.d
-of/home/markos/ldc-0.13.0/runtime/src/core/bitop.o -w -d -O3 -release
-disable-invariants Error: target 'x86_64-pc-kfreebsd-gnu' is not yet
supported

Now, if there is interest to support kfreebsd-* I'll go ahead and ask some of its porters for help, if not, I only have as much time available and I'd rather help the ports that I actually use (like powerpc* and arm), and in that case, I'll just remove the port names from the package's architecture list.

Regards

Konstantinos

Hi Konstantinos!

On Tuesday, 15 July 2014 at 07:14:02 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> On Tue, 15 Jul 2014 06:02:16 +0000
> Kai Nacke via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:
>
>> PowerPC 32bit is still work in progress. PowerPC64 bit is supposed to work. But there is an issue with 0.13.0 release which is fixed in master branch.
>
> Ok, since the machine I have access to is a Power7, I guess I could try
> a powerpc64 build after that as well.
>
>> This seems to be an issue with root/port.c. If these functions are missing then the conditions to choose the implementation are not complete.
> 
> Ok, I will try to get access to a kfreebsd-* system to try to figure it
> out.
>
>> I have some patches for PowerPC 32 bit:
>> http://www.redstar.de/ldc/ppc_druntime.diff
>> http://www.redstar.de/ldc/ppc_phobos.diff
>> 
>> They try to fix some parts and comment out not yet working asserts. std.math is notorius here.
>
> Ok, these seemed to do the trick, but another std.math build failure in
> floor():
>
> /home/markos/ldc-0.13.0/runtime/phobos/std/math.d(3199): Error: static
> assert  "Only 64-bit, 80-bit, and 128-bit reals are supported by floor
> ()"
>
> Does this mean that the powerpc32 port does not have support for 64-bit
> floats?

No. The real type with maximum precision on PowerPC is called doubledouble. Basically, 2 64-bit doubles are combined to give roughly the precision of a 128-bit double. In this case the mantissa has a precision of 106 digits. The assertion simply states that the case "real.mant_dig==106" is not implemented.

Regards,
Kai

On Tuesday, 15 July 2014 at 10:26:23 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> On Tue, 15 Jul 2014 10:13:31 +0300
> Konstantinos Margaritis via digitalmars-d-ldc
> <digitalmars-d-ldc@puremagic.com> wrote:
> 
>> Ok, I will try to get access to a kfreebsd-* system to try to figure
>> it out.
>
> Ok, I think I understand what's wrong here. Debian kfreeBSD-* ports
> don't define __FreeBSD__ which means all those port-specific code is
> never executed. I checked in some kfreebsd-* port wikis and found that
> I should instead check for __FreeBSD_kernel__ instead of plain
> __FreeBSD__. So I did that and the compile moved further, however when
> building runtime I got this:
>
> [ 12%] Generating src/core/bitop.o
> /home/markos/ldc-0.13.0/bin/ldc2 --output-o -c
> -I/home/markos/ldc-0.13.0/runtime/druntime/src
> -I/home/markos/ldc-0.13.0/runtime/druntime/src/gc /home/markos/ldc-0.13.0/runtime/druntime/src/core/bitop.d
> -of/home/markos/ldc-0.13.0/runtime/src/core/bitop.o -w -d -O3 -release
> -disable-invariants Error: target 'x86_64-pc-kfreebsd-gnu' is not yet
> supported
>
> Now, if there is interest to support kfreebsd-* I'll go ahead and ask
> some of its porters for help, if not, I only have as much time
> available and I'd rather help the ports that I actually use (like
> powerpc* and arm), and in that case, I'll just remove the port names
> from the package's architecture list.
>
> Regards
>
> Konstantinos

Is there a define which identifies kfreebsd? This could simply be added to the __FreeBSD__ branch.

(With the host-independent implementation of real this will go away. But I still need to finish the implementation.)

Regards,
Kai

On Tue, 15 Jul 2014 10:37:48 +0000
Kai Nacke via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:

> Is there a define which identifies kfreebsd? This could simply be added to the __FreeBSD__ branch.
> 
> (With the host-independent implementation of real this will go away. But I still need to finish the implementation.)

Ok, at first sight seems the fix was rather easy, I created a simple patch that enabled the build, note the __GLIBC__ added in #ifdef __linux__. This is because kfreeBSD also uses glibc instead of FreeBSD's libc. I attached this patch, however, that didn't enable ldc to build working binaries because of lots of undefined pthread and stdoutp references. Since kfreeBSD uses glibc, such definitions assumed for FreeBSD are not valid for kFreeBSD (don't ask me why, I have no idea why glibc was chosen instead of FreeBSD's libc).

So, I guess in most cases where "version( linux )" is used, an equivalent "version ( glibc )" might be used that would cater for both OSes. But I think that's too intrusive and I'm not even sure where kfreebsd performs like glibc and where it's expected to perform like normal FreeBSD. So I'm not going to perform this time consuming change now. However, I'd be willing to ask some kfreebsd maintainer to do that, if there is interest on behalf of you core LDC developers to integrate such an intrusive patch. Otherwise, as I said before that, I'm just going to list the ports as unsupported and be done with it -or at least revisit it at a later date or wait for some porter to do that effort.

Regards

Konstantinos

On Tue, 15 Jul 2014 10:35:22 +0000
Kai Nacke via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:
> No. The real type with maximum precision on PowerPC is called doubledouble. Basically, 2 64-bit doubles are combined to give roughly the precision of a 128-bit double. In this case the mantissa has a precision of 106 digits. The assertion simply states that the case "real.mant_dig==106" is not implemented.

Hi Kai,

Is there any way I can help with that?

Regards

Konstantinos

On Tuesday, 15 July 2014 at 19:01:49 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> So, I guess in most cases where "version( linux )" is used, an
> equivalent "version ( glibc )" might be used that would cater for both OSes.

This seems like a promising direction as we have a very similar problem with Android, although it's the other way round there (Linux Kernel, but Bionic instead of glibc).

If anybody is interested in taking this up, please be sure to coordinate this with upstream druntime, as all compilers would benefit from that.

Cheers,
David

On Thu, 17 Jul 2014 11:38:07 +0000
David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com>
wrote:

> On Tuesday, 15 July 2014 at 19:01:49 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> > So, I guess in most cases where "version( linux )" is used, an
> > equivalent "version ( glibc )" might be used that would cater
> > for both OSes.
> 
> This seems like a promising direction as we have a very similar problem with Android, although it's the other way round there (Linux Kernel, but Bionic instead of glibc).
> 
> If anybody is interested in taking this up, please be sure to coordinate this with upstream druntime, as all compilers would benefit from that.

I can give it a shot locally and at least find out if it works at all, by replacing linux with glibc. If it does work on kfreebsd, I could attempt to send a patch upstream.

Konstantinos