digitalmars.D.ldc - LDC build issues for PowerPC and kfreebsd-{i386,amd64} on Debian
- Konstantinos Margaritis via digitalmars-d-ldc (113/113) Jul 14 2014 Content-Disposition: inline
- Kai Nacke (16/79) Jul 14 2014 Hi Konstantinos!
- Konstantinos Margaritis via digitalmars-d-ldc (19/31) Jul 15 2014 Content-Disposition: inline
- Kai Nacke (10/43) Jul 15 2014 Hi Konstantinos!
- Konstantinos Margaritis via digitalmars-d-ldc (8/13) Jul 17 2014 Content-Disposition: inline
- Kai Nacke (7/19) Jul 19 2014 Hi Konstantinos,
- Konstantinos Margaritis via digitalmars-d-ldc (27/29) Jul 15 2014 Content-Disposition: inline
- Kai Nacke (8/45) Jul 15 2014 Is there a define which identifies kfreebsd? This could simply be
- Konstantinos Margaritis via digitalmars-d-ldc (81/86) Jul 15 2014 boundary="Multipart=_Tue__15_Jul_2014_22_01_18_+0300_v7qObXNgsKEYmxoX"
- David Nadlinger (10/13) Jul 17 2014 This seems like a promising direction as we have a very similar
- Konstantinos Margaritis via digitalmars-d-ldc (9/22) Jul 17 2014 Content-Disposition: inline
- Joakim (14/37) Jul 19 2014 I thought about mentioning the Android connection, but didn't
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, The ldc package on Debian has just reported 3 build failures: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D754689 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D754690 One is for PowerPC: | /=C2=ABPKGBUILDDIR=C2=BB/bin/ldc2 --output-o -c | -I/=C2=ABPKGBUILDDIR=C2=BB/runtime/druntime/src | -I/=C2=ABPKGBUILDDIR=C2=BB/runtime/druntime/src/gc /=C2=ABPKGBUILDDIR=C2= =BB/runtime/druntime/src/core/thread.d | -of/=C2=ABPKGBUILDDIR=C2=BB/runtime/src/core/thread.o -w -d -O3 -release | -disable-invariants /=C2=ABPKGBUILDDIR=C2=BB/runtime/druntime/src/core/th= read.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/li= bLLVMTableGen.a /usr/lib/llvm-3.4/lib/libLLVMInstrumentation.a /usr/lib/llv= m-3.4/lib/libLLVMipo.a /usr/lib/llvm-3.4/lib/libLLVMVectorize.a /usr/lib/ll= vm-3.4/lib/libLLVMLinker.a /usr/lib/llvm-3.4/lib/libLLVMBitWriter.a /usr/li= b/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/libLLVMR600A= smPrinter.a /usr/lib/llvm-3.4/lib/libLLVMSystemZDisassembler.a /usr/lib/llv= m-3.4/lib/libLLVMSystemZCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMSystemZAsmPa= rser.a /usr/lib/llvm-3.4/lib/libLLVMSystemZDesc.a /usr/lib/llvm-3.4/lib/lib= LLVMSystemZInfo.a /usr/lib/llvm-3.4/lib/libLLVMSystemZAsmPrinter.a /usr/lib= /llvm-3.4/lib/libLLVMHexagonCodeGen.a /usr/lib/llvm-3.4/lib/libLLVMHexagonA= smPrinter.a /usr/lib/llvm-3.4/lib/libLLVMHexagonDesc.a /usr/lib/llvm-3.4/li= b/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/libLLVM= CppBackendCodeGen.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/libLLVMM= SP430AsmPrinter.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/libLLVMXCo= reAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMMipsDisassembler.a /usr/lib/llv= m-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/libLLVMMipsI= nfo.a /usr/lib/llvm-3.4/lib/libLLVMMipsAsmPrinter.a /usr/lib/llvm-3.4/lib/l= ibLLVMARMDisassembler.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/libLLVMARMAsmPr= inter.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/libLLVM= AArch64Info.a /usr/lib/llvm-3.4/lib/libLLVMAArch64AsmPrinter.a /usr/lib/llv= m-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/li= bLLVMPowerPCDesc.a /usr/lib/llvm-3.4/lib/libLLVMPowerPCInfo.a /usr/lib/llvm= -3.4/lib/libLLVMPowerPCAsmPrinter.a /usr/lib/llvm-3.4/lib/libLLVMSparcCodeG= en.a /usr/lib/llvm-3.4/lib/libLLVMSparcDesc.a /usr/lib/llvm-3.4/lib/libLLVM= SparcInfo.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/libLLVMAsmPrin= ter.a /usr/lib/llvm-3.4/lib/libLLVMMCParser.a /usr/lib/llvm-3.4/lib/libLLVM= CodeGen.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/llv= m-3.4/lib/libLLVMTransformUtils.a /usr/lib/llvm-3.4/lib/libLLVMipa.a /usr/l= ib/llvm-3.4/lib/libLLVMAnalysis.a /usr/lib/llvm-3.4/lib/libLLVMX86Desc.a /u= sr/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/libLLVMM= C.a /usr/lib/llvm-3.4/lib/libLLVMObject.a /usr/lib/llvm-3.4/lib/libLLVMX86U= tils.a /usr/lib/llvm-3.4/lib/libLLVMCore.a /usr/lib/llvm-3.4/lib/libLLVMSup= port.a | -L/usr/lib/llvm-3.4/lib -lpthread -lffi -ltinfo -ldl -lm -lpthread | -ltinfo -Wl,-rpath,/=C2=ABPKGBUILDDIR=C2=BB/lib: | CMakeFiles/ldc2.dir/driver/main.cpp.o: In function | `main': /=C2=ABPKGBUILDDIR=C2=BB/driver/main.cpp:1055: undefined referenc= e to | `Port::stricmp(char const*, char | const*)' /=C2=ABPKGBUILDDIR=C2=BB/driver/main.cpp:1056: undefined referen= ce 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=3Dldc&suite=3Dsqueeze
Jul 14 2014
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 statusThis 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=squeezeRegards, Kai
Jul 14 2014
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 supposed to work. But there is an issue with 0.13.0 release which=20 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=20 are missing then the conditions to choose the implementation are=20 not complete.=20 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 =20 They try to fix some parts and comment out not yet working=20 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
Jul 15 2014
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: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, KaiPowerPC 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?
Jul 15 2014
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 doubledouble. Basically, 2 64-bit doubles are combined to give=20 roughly the precision of a 128-bit double. In this case the=20 mantissa has a precision of 106 digits. The assertion simply=20 states that the case "real.mant_dig=3D=3D106" is not implemented.Hi Kai, Is there any way I can help with that? Regards Konstantinos
Jul 17 2014
"Kai Nacke" <kai redstar.de> On Thursday, 17 July 2014 at 10:58:59 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:On Tue, 15 Jul 2014 10:35:22 +0000 Kai Nacke via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> wrote:Hi Konstantinos, you can have a look at std.math source. I am not an expert in PPC double-double type so every help here is welcome. Regards, KaiNo. 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
Jul 19 2014
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 15 Jul 2014 10:13:31 +0300 Konstantinos Margaritis via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> wrote: =20Ok, 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/r= untime/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
Jul 15 2014
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: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, KaiOk, 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
Jul 15 2014
boundary="Multipart=_Tue__15_Jul_2014_22_01_18_+0300_v7qObXNgsKEYmxoX" --Multipart=_Tue__15_Jul_2014_22_01_18_+0300_v7qObXNgsKEYmxoX Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 added to the __FreeBSD__ branch. =20 (With the host-independent implementation of real this will go=20 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 --Multipart=_Tue__15_Jul_2014_22_01_18_+0300_v7qObXNgsKEYmxoX Content-Type: text/x-diff; name="ldc-kfreebsd.patch" Content-Disposition: attachment; filename="ldc-kfreebsd.patch" Content-Transfer-Encoding: quoted-printable diff -ruN ldc-0.13.0.orig/dmd2/root/man.c ldc-0.13.0/dmd2/root/man.c --- ldc-0.13.0.orig/dmd2/root/man.c 2014-02-10 12:08:36.000000000 +0000 +++ ldc-0.13.0/dmd2/root/man.c 2014-07-15 10:12:04.000000000 +0000 -26,7 +26,7 =20 #endif =20 -#if __linux__ || __FreeBSD__ || __OpenBSD__ || __sun +#if __linux__ || __FreeBSD__ || __FreeBSD_kernel__ || __OpenBSD__ || __sun =20 #include <sys/types.h> #include <sys/wait.h> diff -ruN ldc-0.13.0.orig/dmd2/root/port.c ldc-0.13.0/dmd2/root/port.c --- ldc-0.13.0.orig/dmd2/root/port.c 2014-05-10 13:47:06.000000000 +0000 +++ ldc-0.13.0/dmd2/root/port.c 2014-07-15 10:10:03.000000000 +0000 -432,10 +432,10 =20 #endif =20 -#if __linux__ || __APPLE__ || __FreeBSD__ || __OpenBSD__ || __HAIKU__ +#if __linux__ || __APPLE__ || __FreeBSD__ || __FreeBSD_kernel__ || __OpenB= SD__ || __HAIKU__ =20 #include <math.h> -#if __linux__ +#if __linux__ || __GLIBC__ #include <bits/nan.h> #include <bits/mathdef.h> #endif diff -ruN ldc-0.13.0.orig/driver/main.cpp ldc-0.13.0/driver/main.cpp --- ldc-0.13.0.orig/driver/main.cpp 2014-06-23 16:27:55.000000000 +0000 +++ ldc-0.13.0/driver/main.cpp 2014-07-15 10:42:18.000000000 +0000 -693,6 +693,11 VersionCondition::addPredefinedGlobalIdent("FreeBSD"); VersionCondition::addPredefinedGlobalIdent("Posix"); break; + case llvm::Triple::KFreeBSD: + VersionCondition::addPredefinedGlobalIdent("freebsd"); // For = backwards compatibility. + VersionCondition::addPredefinedGlobalIdent("FreeBSD"); + VersionCondition::addPredefinedGlobalIdent("Posix"); + break; case llvm::Triple::Solaris: VersionCondition::addPredefinedGlobalIdent("solaris"); // For = backwards compatibility. VersionCondition::addPredefinedGlobalIdent("Solaris"); --Multipart=_Tue__15_Jul_2014_22_01_18_+0300_v7qObXNgsKEYmxoX--
Jul 15 2014
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
Jul 17 2014
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 via digitalmars-d-ldc wrote: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. KonstantinosSo, I guess in most cases where "version( linux )" is used, an equivalent "version ( glibc )" might be used that would cater=20 for both OSes.=20 This seems like a promising direction as we have a very similar=20 problem with Android, although it's the other way round there=20 (Linux Kernel, but Bionic instead of glibc). =20 If anybody is interested in taking this up, please be sure to=20 coordinate this with upstream druntime, as all compilers would=20 benefit from that.
Jul 17 2014
On Thursday, 17 July 2014 at 12:25:19 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:On Thu, 17 Jul 2014 11:38:07 +0000 David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> wrote:I thought about mentioning the Android connection, but didn't because I figured you probably didn't want to do that work. Replacing linux with glibc might work for kfreebsd, but it's not going to be accepted upstream, because right now "linux" really means "linux kernel and glibc." Simply renaming it to "glibc" doesn't really solve the problem, that we need to separate out the linux kernel APIs from the glibc APIs. Since I've been working on an Android port of D, I've offered to help with this a couple times, by separating the bionic APIs that are currently lumped with linux kernel APIs, if someone else pitched in on separating linux+glibc, but never found anyone who was interested. If you are, let me know.On Tuesday, 15 July 2014 at 19:01:49 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote: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.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.
Jul 19 2014