On Sunday, 3 May 2015 at 07:04:17 UTC, Joakim wrote:
> On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy wrote:
>> Hello,
>>
>> I would like to use D on SmartOS.
>>
>> Since there is no binary installer I tried to build DMD from source by
>> following the instructions on this page; http://wiki.dlang.org/Building_DMD
>>
>> Unfortunately I get this error;
>> [~/d/dmd/src]# make -f posix.mak MODEL=64
>>
>> no cpu specified, assuming X86
>> dmd idgen.d
>> make: dmd: Command not found
>> posix.mak:320: recipe for target 'idgen' failed
>> make: *** [idgen] Error 127
>
> I spent a couple hours and installed SmartOS in a VM, my first time ever messing with SmartOS though I've run and developed for Solaris before, to see what the status of building dmd is.  While it was a pain getting SmartOS configured, I was finally able to build dmd 2.067 and druntime without a problem, using gcc 4.7 (the clang from pkgin tried to use some linker config that wouldn't work to link even basic test C++ files).  Phobos now keeps failing to build on me, but only because I'm low on disk space and it keeps running out of swap.
>
> However, linking a small sample file against druntime alone fails, some issue with the deh_beg/deh_end sections:
>
> gcc sieve.o ./lib/libdruntime-solaris64.a -o sieve -m64 -lpthread -lm
> ld: fatal: symbol '_deh_beg' in file sieve.o: section [15].deh_beg: size 0: symbol (address 0, size 0x4) lies outside of containing section
> ld: fatal: symbol '_deh_end' in file sieve.o: section [17].deh_end: size 0: symbol (address 0, size 0x4) lies outside of containing section
> ld: fatal: file processing errors. No output written to sieve
> collect2: error: ld returned 1 exit status
>
> I'll finish building phobos and mess around a bit with fixing those sections.  I'll let you know if I get it to work.

I got the some error. You need a more recent binutils version.

Regards,
Kai

Thanks everyone for spending the time on this!

I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously.

My version of binutils is;
binutils-2.24nb3;GNU binary utilities

The latest version seems to be 2.25.

On Sunday, 3 May 2015 at 15:06:24 UTC, flamencofantasy wrote:
> Thanks everyone for spending the time on this!
>
> I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously.
>
> My version of binutils is;
> binutils-2.24nb3;GNU binary utilities

Same here.  Kai, do we need to get 2.25 or is 2.24 good enough?

As I recall, the problem is the size of the segment (as created by DMD) is smaller sum of the sizes of the objects in it (which is by ld complains). You could try binutils, though usually the use of GNU ld on Illumos platforms is discouraged (as it tends to get lots of things wrong).  You can use elfedit, or I think I have a patch that makes things happy around here somewhere I can try to dig up.

GDC should also probably work, though you'll need to apply the patches that everyone else does on any Solaris derived platforms (which for unknown reasons, the gcc folks have refused to accept for the past 10+ years).

On Sun, May 3, 2015 at 5:49 AM, Kai Nacke via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 3 May 2015 at 07:04:17 UTC, Joakim wrote:
>
>> On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy wrote:
>>
>>> Hello,
>>>
>>> I would like to use D on SmartOS.
>>>
>>> Since there is no binary installer I tried to build DMD from source by following the instructions on this page; http://wiki.dlang.org/Building_DMD
>>>
>>> Unfortunately I get this error;
>>> [~/d/dmd/src]# make -f posix.mak MODEL=64
>>>
>>> no cpu specified, assuming X86
>>> dmd idgen.d
>>> make: dmd: Command not found
>>> posix.mak:320: recipe for target 'idgen' failed
>>> make: *** [idgen] Error 127
>>>
>>
>> I spent a couple hours and installed SmartOS in a VM, my first time ever messing with SmartOS though I've run and developed for Solaris before, to see what the status of building dmd is.  While it was a pain getting SmartOS configured, I was finally able to build dmd 2.067 and druntime without a problem, using gcc 4.7 (the clang from pkgin tried to use some linker config that wouldn't work to link even basic test C++ files). Phobos now keeps failing to build on me, but only because I'm low on disk space and it keeps running out of swap.
>>
>> However, linking a small sample file against druntime alone fails, some issue with the deh_beg/deh_end sections:
>>
>> gcc sieve.o ./lib/libdruntime-solaris64.a -o sieve -m64 -lpthread -lm
>> ld: fatal: symbol '_deh_beg' in file sieve.o: section [15].deh_beg: size
>> 0: symbol (address 0, size 0x4) lies outside of containing section
>> ld: fatal: symbol '_deh_end' in file sieve.o: section [17].deh_end: size
>> 0: symbol (address 0, size 0x4) lies outside of containing section
>> ld: fatal: file processing errors. No output written to sieve
>> collect2: error: ld returned 1 exit status
>>
>> I'll finish building phobos and mess around a bit with fixing those sections.  I'll let you know if I get it to work.
>>
>
> I got the some error. You need a more recent binutils version.
>
> Regards,
> Kai
>

On Sunday, 3 May 2015 at 16:02:54 UTC, Joakim wrote:
> On Sunday, 3 May 2015 at 15:06:24 UTC, flamencofantasy wrote:
>> Thanks everyone for spending the time on this!
>>
>> I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously.
>>
>> My version of binutils is;
>> binutils-2.24nb3;GNU binary utilities
>
> Same here.  Kai, do we need to get 2.25 or is 2.24 good enough?

Hmm, looking at the linker command invoked by gcc, it says it's calling collect2, but it also spits out a version string for the Solaris linker, so maybe it's really using that.  I'm not interested in debugging the broken Solaris toolchain, so I'll leave it here.

It's not broken, dmd is emitting an arguably invalid elf section.

On Sun, May 3, 2015 at 12:34 PM, Joakim via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 3 May 2015 at 16:02:54 UTC, Joakim wrote:
>
>> On Sunday, 3 May 2015 at 15:06:24 UTC, flamencofantasy wrote:
>>
>>> Thanks everyone for spending the time on this!
>>>
>>> I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously.
>>>
>>> My version of binutils is;
>>> binutils-2.24nb3;GNU binary utilities
>>>
>>
>> Same here.  Kai, do we need to get 2.25 or is 2.24 good enough?
>>
>
> Hmm, looking at the linker command invoked by gcc, it says it's calling collect2, but it also spits out a version string for the Solaris linker, so maybe it's really using that.  I'm not interested in debugging the broken Solaris toolchain, so I'll leave it here.
>

On Sunday, 3 May 2015 at 16:02:54 UTC, Joakim wrote:
> On Sunday, 3 May 2015 at 15:06:24 UTC, flamencofantasy wrote:
>> Thanks everyone for spending the time on this!
>>
>> I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously.
>>
>> My version of binutils is;
>> binutils-2.24nb3;GNU binary utilities
>
> Same here.  Kai, do we need to get 2.25 or is 2.24 good enough?

Can't tell yet. I crashed my OpenIndiana VM and currently don't know how to repair it. But: I used the "normal" package repository and the sfe package repository. Both have a gcc + binutils and one of them worked.

BTW: You can by-pass the Solaris ld by setting environment variable LD_ALTEXEC to the ld binary you want to use.

Regards,
Kai

Thanks for the tip!
I pointed LD_ALTEXEC to the gnu ld like this;
LD_ALTEXEC=/opt/local/x86_64-sun-solaris2.11/bin/ld

Now I can compile and build and run a simple D program with no imports.
I do get a link error but ld apparently auto corrects it;

[root@smartmachine ~]# dmd hello.d
/opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created.
[root@smartmachine ~]#

However once I import std.stdio and make use of writeln the build fails with the error below;

[root@smartmachine ~]# dmd hello.d
/opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created.
/opt/local/dmd/lib/libphobos2.a(file_8e0_5fb.o): In function `_D3std4file15DirIteratorImpl4nextMFZb':
std/file.d:(.text._D3std4file15DirIteratorImpl4nextMFZb+0x7d): undefined reference to `readdir64'
collect2: error: ld returned 1 exit status
--- errorlevel 1
[root@smartmachine ~]#

I did rebuild dmd, druntime and phobos with the binutils ld.

Should I give up?

Thanks!

It looks like std/file.d needs to be updated to not use the largefile definition on 64-bit mode.

On Tue, May 5, 2015 at 9:18 AM, flamencofantasy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
>
> Thanks for the tip!
> I pointed LD_ALTEXEC to the gnu ld like this;
> LD_ALTEXEC=/opt/local/x86_64-sun-solaris2.11/bin/ld
>
> Now I can compile and build and run a simple D program with no imports. I do get a link error but ld apparently auto corrects it;
>
> [root@smartmachine ~]# dmd hello.d
> /opt/local/x86_64-sun-solaris2.11/bin/ld: error in
> /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame);
> no .eh_frame_hdr table will be created.
> [root@smartmachine ~]#
>
> However once I import std.stdio and make use of writeln the build fails with the error below;
>
> [root@smartmachine ~]# dmd hello.d
> /opt/local/x86_64-sun-solaris2.11/bin/ld: error in
> /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame);
> no .eh_frame_hdr table will be created.
> /opt/local/dmd/lib/libphobos2.a(file_8e0_5fb.o): In function
> `_D3std4file15DirIteratorImpl4nextMFZb':
> std/file.d:(.text._D3std4file15DirIteratorImpl4nextMFZb+0x7d): undefined
> reference to `readdir64'
> collect2: error: ld returned 1 exit status
> --- errorlevel 1
> [root@smartmachine ~]#
>
> I did rebuild dmd, druntime and phobos with the binutils ld.
>
> Should I give up?
>
> Thanks!
>
>

On Tuesday, 5 May 2015 at 05:42:33 UTC, Kai Nacke wrote:
> BTW: You can by-pass the Solaris ld by setting environment variable LD_ALTEXEC to the ld binary you want to use.

Thanks for the tip: I set that to the binutils ld and got almost all of druntime's tests to pass with a 64-bit binary.  I only had to comment out the additional druntime tests having to do with exceptions.  Maybe that's related to the link error flamencofantasy pasted.

I also tried running the phobos unit tests, but I got a ton of link errors, seemingly for stuff that should be there.  I'll let someone else track those down.

On Tuesday, 5 May 2015 at 14:19:00 UTC, flamencofantasy wrote:
> However once I import std.stdio and make use of writeln the build fails with the error below;
>
> [root@smartmachine ~]# dmd hello.d
> /opt/local/x86_64-sun-solaris2.11/bin/ld: error in /opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.4/crtend.o(.eh_frame); no .eh_frame_hdr table will be created.
> /opt/local/dmd/lib/libphobos2.a(file_8e0_5fb.o): In function `_D3std4file15DirIteratorImpl4nextMFZb':
> std/file.d:(.text._D3std4file15DirIteratorImpl4nextMFZb+0x7d): undefined reference to `readdir64'
> collect2: error: ld returned 1 exit status
> --- errorlevel 1
> [root@smartmachine ~]#

Hmm, I get no output when building and running the sample file sieve.d.  If I use core.stdc.stdio.printf instead, it works fine, just not with std.stdio.writefln.

> I did rebuild dmd, druntime and phobos with the binutils ld.

The linker will only be used for dmd, which won't matter since it's C++ anyway.  Druntime and phobos are libraries, so the linker is unused until you build an executable that links against them.

> Should I give up?

Obviously dmd and phobos still have some issues to be fixed on Solaris.  It all depends on whether you'd like to pitch in on fixing those.  Alternatively, you can try building ldc, which Kai has put some effort into getting working on Solaris/x86.