www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - port to NetBSD

reply Nikolay <sibnick gmail.com> writes:
I am trying compile ldc (git master) on NetBSD 7.0 Currently I 
stuck on link error for ldc2:

/usr/pkg/bin/cmake -E cmake_link_script 
CMakeFiles/ldc2.dir/link.txt --verbose=1
/usr/bin/c++     CMakeFiles/ldc2.dir/driver/cl_options.cpp.o 
CMakeFiles/ldc2.dir/driver/codegenerator.cpp.o 
CMakeFiles/ldc2.dir/driver/configfile.cpp.o 
CMakeFiles/ldc2.dir/driver/exe_path.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.a /usr/pkg/lib/libconfig.so -lpthread -lterminfo 
-lLLVMOption -lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker 
-lLLVMIRReader -lLLVMInstrumentation -lLLVMBitWriter 
-lLLVMAsmParser -lLLVMR600CodeGen -lLLVMipo -lLLVMVectorize 
-lLLVMR600AsmParser -lLLVMR600Desc -lLLVMR600Info 
-lLLVMR600AsmPrinter -lLLVMSystemZDisassembler 
-lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc 
-lLLVMSystemZInfo -lLLVMSystemZAsmPrinter 
-lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonDesc 
-lLLVMHexagonInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc 
-lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMCppBackendCodeGen 
-lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc 
-lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler 
-lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo 
-lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen 
-lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo 
-lLLVMMipsAsmPrinter -lLLVMAArch64Disassembler 
-lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc 
-lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils 
-lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser 
-lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter 
-lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen 
-lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo 
-lLLVMPowerPCAsmPrinter -lLLVMSparcDisassembler 
-lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc 
-lLLVMSparcInfo -lLLVMSparcAsmPrinter -lLLVMX86Disassembler 
-lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG 
-lLLVMAsmPrinter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMProfileData 
-lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis 
-lLLVMTarget -lLLVMX86Desc -lLLVMObject -lLLVMMCParser 
-lLLVMBitReader -lLLVMMCDisassembler -lLLVMX86Info 
-lLLVMX86AsmPrinter -lLLVMMC -lLLVMX86Utils -lLLVMCore 
-lLLVMSupport -L/usr/pkg/lib -lz -lpthread -ledit -lterminfo -lm 
-lpthread -lterminfo -Wl,-rpath,/usr/pkg/lib:
CMakeFiles/ldc2.dir/driver/main.cpp.o: In function `main':
main.cpp:(.text.startup.main+0x146b): undefined reference to 
`Port::stricmp(char const*, char const*)'
main.cpp:(.text.startup.main+0x1c5b): undefined reference to 
`Port::stricmp(char const*, char const*)'
lib/libldc.a(builtin.c.o): In function `eval_sqrt(Loc, 
FuncDeclaration*, Array<Expression*>*)':


It looks like problem with dmd2/root/port.c 
CMakeFiles/LDCShared.dir/dmd2/root/port.c.o is not included into 
CMakeFiles/ldc2.dir/link.txt

Also I can not find any symbols inside port.c.o file

Can somebody give advice how to resolve this problem?
Jan 06
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Dear Nikolay,

On 6 Jan 2016, at 19:18, Nikolay via digitalmars-d-ldc wrote:
 It looks like problem with dmd2/root/port.c 
 CMakeFiles/LDCShared.dir/dmd2/root/port.c.o is not included into 
 CMakeFiles/ldc2.dir/link.txt
port.c is part of libldc.a, so this is not the issue. Instead, as you noted (absence of any symbols) port.c currently does not have an implementation for NetBSD. The file is designed to encapsulate all the functions used within the front-end that are not portable between operating systems. You'll need to implement it for NetBSD, although I suspect you can probably re-use most of the __FreeBSD__ and __OpenBSD__ code. Best, David
Jan 06
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 6 January 2016 at 18:36:10 UTC, David Nadlinger 
wrote:
 Dear Nikolay,

 On 6 Jan 2016, at 19:18, Nikolay via digitalmars-d-ldc wrote:
 It looks like problem with dmd2/root/port.c 
 CMakeFiles/LDCShared.dir/dmd2/root/port.c.o is not included 
 into CMakeFiles/ldc2.dir/link.txt
port.c is part of libldc.a, so this is not the issue. Instead, as you noted (absence of any symbols) port.c currently does not have an implementation for NetBSD. The file is designed to encapsulate all the functions used within the front-end that are not portable between operating systems. You'll need to implement it for NetBSD, although I suspect you can probably re-use most of the __FreeBSD__ and __OpenBSD__ code.
In addition, I see 14 more files which reference FreeBSD somewhere, so you will have to look at each of those and make sure you make the necessary changes for NetBSD. In most cases, all that should be necessary is adding the equivalent NetBSD check to the list of Posix-like OS's.
Jan 06
parent reply Kai Nacke <kai redstar.de> writes:
On Thursday, 7 January 2016 at 03:14:48 UTC, Joakim wrote:
 On Wednesday, 6 January 2016 at 18:36:10 UTC, David Nadlinger 
 wrote:
 Dear Nikolay,

 On 6 Jan 2016, at 19:18, Nikolay via digitalmars-d-ldc wrote:
 It looks like problem with dmd2/root/port.c 
 CMakeFiles/LDCShared.dir/dmd2/root/port.c.o is not included 
 into CMakeFiles/ldc2.dir/link.txt
port.c is part of libldc.a, so this is not the issue. Instead, as you noted (absence of any symbols) port.c currently does not have an implementation for NetBSD. The file is designed to encapsulate all the functions used within the front-end that are not portable between operating systems. You'll need to implement it for NetBSD, although I suspect you can probably re-use most of the __FreeBSD__ and __OpenBSD__ code.
In addition, I see 14 more files which reference FreeBSD somewhere, so you will have to look at each of those and make sure you make the necessary changes for NetBSD. In most cases, all that should be necessary is adding the equivalent NetBSD check to the list of Posix-like OS's.
After porting the compiler you also need to enhance druntime. In most cases you can simple duplicate the FreeBSD code I guess. I am happy to accept PR's for ldc code. druntime PR's should go upstream first. I will then cherry-pick them if necessary. Regards, Kai
Jan 07
parent reply Nikolay <sibnick gmail.com> writes:
On Thursday, 7 January 2016 at 23:22:45 UTC, Kai Nacke wrote:
 After porting the compiler you also need to enhance druntime. 
 In most cases you can simple duplicate the FreeBSD code I guess.
Life is not so simple. Currently I have following troubles with druntime: - For some reason static ctor std.stdiobase is not called. So I have to call std_stdio_static_this() manually. - I have troubles with floating point methods like llroundl, remainderl, ... As I can understand they are builtin in C compiler and there is no library for them. Also I have one failed assert in phobos std.internal.math.gammafunction.logmdigammaInverse : static assert(maxY > 0 && maxY <= real.max); My be it is related to the previous problem.
 I am happy to accept PR's for ldc code. druntime PR's should go 
 upstream first. I will then cherry-pick them if necessary.

 Regards,
 Kai
https://github.com/ldc-developers/ldc/pull/1247 My github: https://github.com/nrTQgc/ldc https://github.com/nrTQgc/druntime.git https://github.com/nrTQgc/phobos.git
Jan 08
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 8 January 2016 at 18:08:38 UTC, Nikolay wrote:
 On Thursday, 7 January 2016 at 23:22:45 UTC, Kai Nacke wrote:
 After porting the compiler you also need to enhance druntime. 
 In most cases you can simple duplicate the FreeBSD code I 
 guess.
Life is not so simple. Currently I have following troubles with druntime: - For some reason static ctor std.stdiobase is not called. So I have to call std_stdio_static_this() manually. - I have troubles with floating point methods like llroundl, remainderl, ... As I can understand they are builtin in C compiler and there is no library for them. Also I have one failed assert in phobos std.internal.math.gammafunction.logmdigammaInverse : static assert(maxY > 0 && maxY <= real.max); My be it is related to the previous problem.
Looks like you got pretty far, as most of those are problems in phobos, not druntime. For the last one, try turning maxY into a runtime variable, ie replace enum with real, and change that static assert to regular assert, ie remove static. That fixed the issue for me on ARM, which was due to CTFE. Are you cross-compiling or compiling on NetBSD itself?
 I am happy to accept PR's for ldc code. druntime PR's should 
 go upstream first. I will then cherry-pick them if necessary.

 Regards,
 Kai
https://github.com/ldc-developers/ldc/pull/1247 My github: https://github.com/nrTQgc/ldc https://github.com/nrTQgc/druntime.git https://github.com/nrTQgc/phobos.git
I'll take a look.
Jan 08
parent reply Nikolay <sibnick gmail.com> writes:
On Friday, 8 January 2016 at 19:09:09 UTC, Joakim wrote:
For the last one, try turning maxY into
 a runtime variable, ie replace enum with real, and change that 
 static assert to regular assert, ie remove static.  That fixed 
 the issue for me on ARM, which was due to CTFE.
Thanks It resolves problem
 Are you cross-compiling or compiling on NetBSD itself?
I installed NetBSD to VirtualBox and do not use cross-compiling
Jan 08
parent reply Nikolay <sibnick gmail.com> writes:
On Saturday, 9 January 2016 at 05:49:39 UTC, Nikolay wrote:
 On Friday, 8 January 2016 at 19:09:09 UTC, Joakim wrote:
 For the last one, try turning maxY into
 a runtime variable, ie replace enum with real, and change that 
 static assert to regular assert, ie remove static.  That fixed 
 the issue for me on ARM, which was due to CTFE.
Thanks It resolves problem
Ops I was wrong. It just move problem from compile-time to later. The source is undefined reference to symbols like llroundl, remainderl, ...
Jan 08
parent reply Nikolay <sibnick gmail.com> writes:
On Saturday, 9 January 2016 at 06:13:30 UTC, Nikolay wrote:
 On Saturday, 9 January 2016 at 05:49:39 UTC, Nikolay wrote:
 On Friday, 8 January 2016 at 19:09:09 UTC, Joakim wrote:
 For the last one, try turning maxY into
 a runtime variable, ie replace enum with real, and change 
 that static assert to regular assert, ie remove static.  That 
 fixed the issue for me on ARM, which was due to CTFE.
Thanks It resolves problem
Ops I was wrong. It just move problem from compile-time to later. The source is undefined reference to symbols like llroundl, remainderl, ...
I fixed core.stdc.math and now your solution is work for me.
Jan 09
parent Nikolay <sibnick gmail.com> writes:
On Saturday, 9 January 2016 at 09:56:09 UTC, Nikolay wrote:
 I fixed core.stdc.math and now your solution is work for me.
My current state for "make test" command: 660/663 Test #660: dmd-testsuite-debug .........................***Failed 0.01 sec Start 661: clean-dmd-testsuite 661/663 Test #661: clean-dmd-testsuite ......................... Passed 0.01 sec Start 662: dmd-testsuite 662/663 Test #662: dmd-testsuite ...............................***Failed 0.01 sec Start 663: llvm-ir-testsuite 663/663 Test #663: llvm-ir-testsuite ...........................***Failed 0.04 sec 99% tests passed, 3 tests failed out of 663 Total Test time (real) = 28.05 sec The following tests FAILED: 660 - dmd-testsuite-debug (Failed) 662 - dmd-testsuite (Failed) 663 - llvm-ir-testsuite (Failed) Errors while running CTest *** Error code 8
Jan 09
prev sibling next sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 8 Jan 2016, at 19:08, Nikolay via digitalmars-d-ldc wrote:
 - For some reason static ctor std.stdiobase is not called. So I have 
 to call std_stdio_static_this() manually.
Are the other (shared) static constructors being called? Which ones? — David
Jan 08
parent Nikolay <sibnick gmail.com> writes:
On Friday, 8 January 2016 at 19:18:56 UTC, David Nadlinger wrote:
 On 8 Jan 2016, at 19:08, Nikolay via digitalmars-d-ldc wrote:
 - For some reason static ctor std.stdiobase is not called. So 
 I have to call std_stdio_static_this() manually.
Are the other (shared) static constructors being called? Which ones? — David
No As I can undertand rt.sections_elf_shared._d_dso_registry is not called for all modules
Jan 08
prev sibling parent reply Kai Nacke <kai redstar.de> writes:
On Friday, 8 January 2016 at 18:08:38 UTC, Nikolay wrote:
    - For some reason static ctor std.stdiobase is not called.
Search in gen/module.cpp and gen/runtime.cpp for isLinux and add in the if clause: || globals.params.NetBSD I think this should fix the issue. Regards, Kai
Jan 09
parent reply Kai Nacke <kai redstar.de> writes:
On Saturday, 9 January 2016 at 19:39:51 UTC, Kai Nacke wrote:
 || globals.params.NetBSD
|| global.params.isNetBSD
Jan 09
parent reply Nikolay <sibnick gmail.com> writes:
On Saturday, 9 January 2016 at 19:45:33 UTC, Kai Nacke wrote:
 On Saturday, 9 January 2016 at 19:39:51 UTC, Kai Nacke wrote:
 || globals.params.NetBSD
|| global.params.isNetBSD
Thanks Now it works
Jan 11
parent Nikolay <sibnick gmail.com> writes:
On Monday, 11 January 2016 at 10:26:00 UTC, Nikolay wrote:
 On Saturday, 9 January 2016 at 19:45:33 UTC, Kai Nacke wrote:
 On Saturday, 9 January 2016 at 19:39:51 UTC, Kai Nacke wrote:
 || globals.params.NetBSD
|| global.params.isNetBSD
Thanks Now it works
Unfortunately after this fix I have 39 tests failed. I suppose previously they was not executed at all.
Jan 11