www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Building DMD on SmartOS

reply "flamencofantasy" <flamencofantasy gmail.com> writes:
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

Thanks!
Apr 30 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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
dmd git HEAD requires a host D compiler to build dmd because it's moving files from C++ to D, ie the compiler is becoming self-hosted. This is a problem for new platforms like SmartOS, as dmd doesn't really support cross-compiling yet. However, you can roll back to the last release branch, 2.067, and try compiling that on SmartOS with just a C++ compiler. Of course, the Solaris support in dmd/druntime/phobos is not really tested, so you may need to fill in some gaps for SmartOS.
Apr 30 2015
next sibling parent "Kai Nacke" <kai redstar.de> writes:
On Thursday, 30 April 2015 at 17:54:00 UTC, Joakim wrote:
 compiling that on SmartOS with just a C++ compiler.  Of course, 
 the Solaris support in dmd/druntime/phobos is not really 
 tested, so you may need to fill in some gaps for SmartOS.
I compiled dmd on OpenIndiana (Illumos based like SmartOS). The main issue was that binutils >= 2.20 were required otherwise the compiled application did not run. Of course, ldc runs on Solaris, too. Regards, Kai
Apr 30 2015
prev sibling parent reply "Jens Bauer" <doctor who.no> writes:
 On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy 
 wrote:
 I would like to use D on SmartOS.
SmartOS looks pretty interesting. [see docker.com] :) {snip}
 Unfortunately I get this error;
{snip} On Thursday, 30 April 2015 at 17:54:00 UTC, Joakim wrote:
 dmd git HEAD requires a host D compiler to build dmd
{snip} Would it work to first build GDC or LDC ? (I can build GDC on my PowerMac without having a D compiler already)
May 01 2015
next sibling parent "Jason King \(Gmail\) via Digitalmars-d" <digitalmars-d puremagic.com> writes:
The last version in c++ should build. 

On May 1, 2015, at 3:58 PM, Jens Bauer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy wrote:
 I would like to use D on SmartOS.
SmartOS looks pretty interesting. [see docker.com] :) {snip}
 Unfortunately I get this error;
{snip}
 On Thursday, 30 April 2015 at 17:54:00 UTC, Joakim wrote:
 dmd git HEAD requires a host D compiler to build dmd
{snip} Would it work to first build GDC or LDC ? (I can build GDC on my PowerMac without having a D compiler already)
May 01 2015
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Friday, 1 May 2015 at 20:58:57 UTC, Jens Bauer wrote:
 Would it work to first build GDC or LDC ?
 (I can build GDC on my PowerMac without having a D compiler 
 already)
If you can build either of those on a SmartOS host, why bother with dmd? I don't know if it would work, but I don't believe it's been tested, so probably not.
May 01 2015
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"flamencofantasy"  wrote in message 
news:zhcduibirwprgbzqkpvy forum.dlang.org...

 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

 Thanks!
The last release (2.067) is the last one that can be build without a host D compiler. If you build 2.067 first, you should be able to use it to then build master.
May 01 2015
parent Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
Note that phobos hasn't been fully tested -- there's probably some fixes
that'll need to happen in there.

On Sat, May 2, 2015 at 1:14 AM, Daniel Murphy via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 "flamencofantasy"  wrote in message
 news:zhcduibirwprgbzqkpvy forum.dlang.org...

  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

 Thanks!
The last release (2.067) is the last one that can be build without a host D compiler. If you build 2.067 first, you should be able to use it to then build master.
May 02 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
May 03 2015
next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 3 May 2015 at 07:04:17 UTC, Joakim wrote:
 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.
Alright, increasing the RAM in my VM got phobos to build. However, linking sample files and the tests still fail because of that linker issue. Jason, it appears that you are familiar with the peculiar ELF linking issues: https://www.illumos.org/issues/308 I'm uninterested in digging into these ELF binary issues, so it's all yours, if you want it. I can verify any fix you come up with in this zone that's eating up a ton of disk space on my SSD.
May 03 2015
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
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
May 03 2015
next sibling parent reply "flamencofantasy" <flamencofantasy gmail.com> writes:
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.
May 03 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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?
May 03 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
May 03 2015
parent Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
May 03 2015
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
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
May 04 2015
next sibling parent reply "flamencofantasy" <flamencofantasy gmail.com> writes:
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!
May 05 2015
parent Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
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!
May 05 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
May 05 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
 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.
Before I chuck this large SmartOS VM on my external backup, I thought I'd take another shot at getting the phobos tests running. Turned out to be pretty easy and I started hacking around the test failures until it got too tedious, when the std.path tests wouldn't run because "Memory allocation failed." Here's the last patch I used: https://gist.github.com/joakim-noah/6094789851ba1db1170b Some notes: - I disabled the tests for std.datetime and std.parallelism in the test runner because they were both failing somewhere. - All it took to get the phobos test runner linked was to add all the additional necessary libraries that curl needed on Solaris to posix.mak. - getcwd will not accept a zero size on Solaris. - Solaris seems to have similar issues to Android with formatting NaN and hex in std.format.
May 17 2015
next sibling parent Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
The NaN and hex formatting are a matter of enabling C99 versions of
*printf() functions.  Normally the C compiler does this by linking in the
appropriate /usr/lib/values-*.o file based on the desired compilation mode
(ansi C, c89, c99, etc.) standards(5) goes into more detail on that.

Passing 0 for the size argument to getcwd() is undefined, though probably
reasonable enough to file a bug w/ Illumos to match the BSD and Linux
behavior/


On Sun, May 17, 2015 at 2:36 PM, Joakim via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:

 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.
Before I chuck this large SmartOS VM on my external backup, I thought I'd take another shot at getting the phobos tests running. Turned out to be pretty easy and I started hacking around the test failures until it got too tedious, when the std.path tests wouldn't run because "Memory allocation failed." Here's the last patch I used: https://gist.github.com/joakim-noah/6094789851ba1db1170b Some notes: - I disabled the tests for std.datetime and std.parallelism in the test runner because they were both failing somewhere. - All it took to get the phobos test runner linked was to add all the additional necessary libraries that curl needed on Solaris to posix.mak. - getcwd will not accept a zero size on Solaris. - Solaris seems to have similar issues to Android with formatting NaN and hex in std.format.
May 18 2015
prev sibling parent reply "flamencofantasy" <flamencofantasy gmail.com> writes:
On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:
 On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
 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.
Before I chuck this large SmartOS VM on my external backup, I thought I'd take another shot at getting the phobos tests running. Turned out to be pretty easy and I started hacking around the test failures until it got too tedious, when the std.path tests wouldn't run because "Memory allocation failed." Here's the last patch I used: https://gist.github.com/joakim-noah/6094789851ba1db1170b Some notes: - I disabled the tests for std.datetime and std.parallelism in the test runner because they were both failing somewhere. - All it took to get the phobos test runner linked was to add all the additional necessary libraries that curl needed on Solaris to posix.mak. - getcwd will not accept a zero size on Solaris. - Solaris seems to have similar issues to Android with formatting NaN and hex in std.format.
Hello, This is my test program; import std.stdio; void main() { try { writeln("Hello"); } catch (Exception e) { import core.stdc.stdio; printf(e.msg.ptr); } } The output is; Bad file number It has to do with stdout not being valid but I am unable to figure out why by reading the source code. I am new to unix in general and SmartOS/Solaris in particular. Long story short my fairly large project which builds and runs flawlessly on Windows and Linux, compiles successfully on SmartOS with no warnings but any invocation of writeln (and relatives) throws the exception above. If anyone is willing to help I have a smart zone with ssh access I can provide you with so you can play. Thanks!
Jun 25 2015
parent reply Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
The first thing I would suggest running the program via truss and see if
any calls to write() are returning EBADF.. If so, see what fd# is being
passed (or if something is calling close() on fd1).

On Thu, Jun 25, 2015 at 2:57 PM, flamencofantasy via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:

 On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:

 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.
Before I chuck this large SmartOS VM on my external backup, I thought I'd take another shot at getting the phobos tests running. Turned out to be pretty easy and I started hacking around the test failures until it got too tedious, when the std.path tests wouldn't run because "Memory allocation failed." Here's the last patch I used: https://gist.github.com/joakim-noah/6094789851ba1db1170b Some notes: - I disabled the tests for std.datetime and std.parallelism in the test runner because they were both failing somewhere. - All it took to get the phobos test runner linked was to add all the additional necessary libraries that curl needed on Solaris to posix.mak. - getcwd will not accept a zero size on Solaris. - Solaris seems to have similar issues to Android with formatting NaN and hex in std.format.
Hello, This is my test program; import std.stdio; void main() { try { writeln("Hello"); } catch (Exception e) { import core.stdc.stdio; printf(e.msg.ptr); } } The output is; Bad file number It has to do with stdout not being valid but I am unable to figure out why by reading the source code. I am new to unix in general and SmartOS/Solaris in particular. Long story short my fairly large project which builds and runs flawlessly on Windows and Linux, compiles successfully on SmartOS with no warnings but any invocation of writeln (and relatives) throws the exception above. If anyone is willing to help I have a smart zone with ssh access I can provide you with so you can play. Thanks!
Jun 25 2015
parent reply "flamencofantasy" <flamencofantasy gmail.com> writes:
On Thursday, 25 June 2015 at 20:26:05 UTC, Jason King wrote:
 The first thing I would suggest running the program via truss 
 and see if
 any calls to write() are returning EBADF.. If so, see what fd# 
 is being
 passed (or if something is calling close() on fd1).

 On Thu, Jun 25, 2015 at 2:57 PM, flamencofantasy via 
 Digitalmars-d < digitalmars-d puremagic.com> wrote:

 On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:

 On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:

 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.
Before I chuck this large SmartOS VM on my external backup, I thought I'd take another shot at getting the phobos tests running. Turned out to be pretty easy and I started hacking around the test failures until it got too tedious, when the std.path tests wouldn't run because "Memory allocation failed." Here's the last patch I used: https://gist.github.com/joakim-noah/6094789851ba1db1170b Some notes: - I disabled the tests for std.datetime and std.parallelism in the test runner because they were both failing somewhere. - All it took to get the phobos test runner linked was to add all the additional necessary libraries that curl needed on Solaris to posix.mak. - getcwd will not accept a zero size on Solaris. - Solaris seems to have similar issues to Android with formatting NaN and hex in std.format.
Hello, This is my test program; import std.stdio; void main() { try { writeln("Hello"); } catch (Exception e) { import core.stdc.stdio; printf(e.msg.ptr); } } The output is; Bad file number It has to do with stdout not being valid but I am unable to figure out why by reading the source code. I am new to unix in general and SmartOS/Solaris in particular. Long story short my fairly large project which builds and runs flawlessly on Windows and Linux, compiles successfully on SmartOS with no warnings but any invocation of writeln (and relatives) throws the exception above. If anyone is willing to help I have a smart zone with ssh access I can provide you with so you can play. Thanks!
Thanks, I've been trying truss and gdb but I wasn't able to spot anything useful. The exception is checked and thrown in user space so I don't think truss sees anything. But here is the full truss dump of the program above; [root smartDmachine ~]# truss ./main execve("main", 0xFFFFFD7FFFDFFC88, 0xFFFFFD7FFFDFFC98) argc = 1 sysinfo(SI_MACHINE, "i86pc", 257) = 6 mmap(0x00000000, 56, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF390000 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF380000 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF370000 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF360000 memcntl(0xFFFFFD7FFF398000, 96976, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF350000 memcntl(0x00400000, 6040, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 resolvepath("/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18 getcwd("/root", 1018) = 0 resolvepath("/root/main", "/root/main", 1023) = 10 stat("/root/main", 0xFFFFFD7FFFDFF960) = 0 open("/var/ld/64/ld.config", O_RDONLY) = 3 fstat(3, 0xFFFFFD7FFFDFF6C0) = 0 mmap(0x00000000, 160, PROT_READ, MAP_SHARED, 3, 0) = 0xFFFFFD7FFF340000 close(3) = 0 stat("/opt/local/lib//libpthread.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libpthread.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/lib/amd64/libpthread.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/lib/64/libpthread.so.1", 0xFFFFFD7FFFDFF050) = 0 resolvepath("/lib/64/libpthread.so.1", "/lib/amd64/libpthread.so.1", 1023) = 26 open("/lib/64/libpthread.so.1", O_RDONLY) = 3 mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFD7FFF350C80, 0xFFFFFD7FFFDFEBAC, 0x00000000) = 0 close(3) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF330000 stat("/opt/local/lib//libm.so.2", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libm.so.2", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/lib/amd64/libm.so.2", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/lib/64/libm.so.2", 0xFFFFFD7FFFDFF050) = 0 resolvepath("/lib/64/libm.so.2", "/lib/amd64/libm.so.2", 1023) = 20 open("/lib/64/libm.so.2", O_RDONLY) = 3 mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFD7FFF3309A0, 0xFFFFFD7FFFDFEBAC, 0x00000000) = 0 close(3) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF320000 memcntl(0xFFFFFD7FFEED0000, 89056, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 stat("/opt/local/lib//libc.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libc.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/lib/amd64/libc.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/lib/64/libc.so.1", 0xFFFFFD7FFFDFF050) = 0 resolvepath("/lib/64/libc.so.1", "/lib/amd64/libc.so.1", 1023) = 20 open("/lib/64/libc.so.1", O_RDONLY) = 3 mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFD7FFF320A68, 0xFFFFFD7FFFDFEBAC, 0x00000000) = 0 close(3) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF170000 memcntl(0xFFFFFD7FFF180000, 465912, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFFFFFD7FFF160000 getcontext(0xFFFFFD7FFFDFF3B0) getrlimit(RLIMIT_STACK, 0xFFFFFD7FFFDFF710) = 0 getpid() = 23127 [23126] lwp_private(0, 0, 0xFFFFFD7FFF162A80) = 0x00000000 setustack(0xFFFFFD7FFF162B28) lwp_cond_broadcast(0xFFFFFD7FFF1701A8) = 0 lwp_cond_broadcast(0xFFFFFD7FFF3201A8) = 0 lwp_cond_broadcast(0xFFFFFD7FFF3501A8) = 0 lwp_cond_broadcast(0xFFFFFD7FFF3301A8) = 0 sysi86(SI86FPSTART, 0xFFFFFD7FFFDFFC3C, 0x0000133F, 0x00001F80) = 0x00000001 brk(0x0063E270) = 0 brk(0x00642270) = 0 time() = 1435265935 time() = 1435265935 sigfillset(0xFFFFFD7FFF319500) = 0 schedctl() = 0xFFFFFD7FFF15D000 sigaction(SIGUSR1, 0xFFFFFD7FFFDFF8E0, 0x00000000) = 0 sigaction(SIGUSR2, 0xFFFFFD7FFFDFF8E0, 0x00000000) = 0 sysconfig(_CONFIG_SEM_VALUE_MAX) = 2147483647 mmap(0x00000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF05C000 brk(0x00642270) = 0 brk(0x00646270) = 0 brk(0x00646270) = 0 brk(0x0064A270) = 0 brk(0x0064A270) = 0 brk(0x0064E270) = 0 clock_getres(4, 0xFFFFFD7FFFDFF940) = 0 clock_getres(4, 0xFFFFFD7FFFDFF920) = 0 clock_gettime(4, 0xFFFFFD7FFFDFF930) = 0 priocntlsys(1, 0xFFFFFD7FFFDFF7B0, 3, 0xFFFFFD7FFFDFF8E8, 0) = 23127 priocntlsys(1, 0xFFFFFD7FFFDFF7B0, 1, 0xFFFFFD7FFFDFF918, 0) = 4 sysconfig(_CONFIG_PAGESIZE) = 4096 sigaction(SIGSEGV, 0xFFFFFD7FFFDFF950, 0xFFFFFD7FFFDFFA58) = 0 sigaction(SIGBUS, 0xFFFFFD7FFFDFF950, 0xFFFFFD7FFFDFFA78) = 0 sigaction(SIGSEGV, 0xFFFFFD7FFFDFF940, 0x00000000) = 0 sigaction(SIGBUS, 0xFFFFFD7FFFDFF940, 0x00000000) = 0 mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, 4294967295, 0) = 0xFFFFFD7FFF040000 ioctl(1, TCGETA, 0xFFFFFD7FFFDFE670) = 0 fstat(1, 0xFFFFFD7FFFDFE5F0) = 0 brk(0x0064E270) = 0 brk(0x00652270) = 0 munmap(0xFFFFFD7FFF05C000, 1048576) = 0 munmap(0x00000000, 0) Err#22 EINVAL lseek(0, 0, SEEK_CUR) = 6056 (Bad file number)write(1, " ( B a d f i l e n".., 18) = 18 _exit(0) [root smartDmachine ~]#
Jun 25 2015
parent Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
It appears no syscall is generating EBADF.

Does writeln call into libc's printf() function?  That can return EBADF
(bad file number) if the stream isn't enabled for writing.

I didn't look too closely (work issues) at the D code, but I did notice the
D libraries are trying to define the internal structure of FILE.  It should
be treated as an opaque structure.  I didn't look close enough to see if
any D library code is trying to manipulate any of its fields (IF it is,
that's very wrong).

On Thu, Jun 25, 2015 at 4:03 PM, flamencofantasy via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Thursday, 25 June 2015 at 20:26:05 UTC, Jason King wrote:

 The first thing I would suggest running the program via truss and see if
 any calls to write() are returning EBADF.. If so, see what fd# is being
 passed (or if something is calling close() on fd1).

 On Thu, Jun 25, 2015 at 2:57 PM, flamencofantasy via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

  On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:
  On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
  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.
Before I chuck this large SmartOS VM on my external backup, I thought I'd take another shot at getting the phobos tests running. Turned out to be pretty easy and I started hacking around the test failures until it got too tedious, when the std.path tests wouldn't run because "Memory allocation failed." Here's the last patch I used: https://gist.github.com/joakim-noah/6094789851ba1db1170b Some notes: - I disabled the tests for std.datetime and std.parallelism in the test runner because they were both failing somewhere. - All it took to get the phobos test runner linked was to add all the additional necessary libraries that curl needed on Solaris to posix.mak. - getcwd will not accept a zero size on Solaris. - Solaris seems to have similar issues to Android with formatting NaN and hex in std.format.
Hello, This is my test program; import std.stdio; void main() { try { writeln("Hello"); } catch (Exception e) { import core.stdc.stdio; printf(e.msg.ptr); } } The output is; Bad file number It has to do with stdout not being valid but I am unable to figure out why by reading the source code. I am new to unix in general and SmartOS/Solaris in particular. Long story short my fairly large project which builds and runs flawlessly on Windows and Linux, compiles successfully on SmartOS with no warnings but any invocation of writeln (and relatives) throws the exception above. If anyone is willing to help I have a smart zone with ssh access I can provide you with so you can play. Thanks!
Thanks, I've been trying truss and gdb but I wasn't able to spot anything useful. The exception is checked and thrown in user space so I don't think truss sees anything. But here is the full truss dump of the program above; [root smartDmachine ~]# truss ./main execve("main", 0xFFFFFD7FFFDFFC88, 0xFFFFFD7FFFDFFC98) argc = 1 sysinfo(SI_MACHINE, "i86pc", 257) = 6 mmap(0x00000000, 56, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF390000 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF380000 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF370000 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF360000 memcntl(0xFFFFFD7FFF398000, 96976, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF350000 memcntl(0x00400000, 6040, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 resolvepath("/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18 getcwd("/root", 1018) = 0 resolvepath("/root/main", "/root/main", 1023) = 10 stat("/root/main", 0xFFFFFD7FFFDFF960) = 0 open("/var/ld/64/ld.config", O_RDONLY) = 3 fstat(3, 0xFFFFFD7FFFDFF6C0) = 0 mmap(0x00000000, 160, PROT_READ, MAP_SHARED, 3, 0) = 0xFFFFFD7FFF340000 close(3) = 0 stat("/opt/local/lib//libpthread.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libpthread.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/lib/amd64/libpthread.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/lib/64/libpthread.so.1", 0xFFFFFD7FFFDFF050) = 0 resolvepath("/lib/64/libpthread.so.1", "/lib/amd64/libpthread.so.1", 1023) = 26 open("/lib/64/libpthread.so.1", O_RDONLY) = 3 mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFD7FFF350C80, 0xFFFFFD7FFFDFEBAC, 0x00000000) = 0 close(3) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF330000 stat("/opt/local/lib//libm.so.2", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libm.so.2", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/lib/amd64/libm.so.2", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/lib/64/libm.so.2", 0xFFFFFD7FFFDFF050) = 0 resolvepath("/lib/64/libm.so.2", "/lib/amd64/libm.so.2", 1023) = 20 open("/lib/64/libm.so.2", O_RDONLY) = 3 mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFD7FFF3309A0, 0xFFFFFD7FFFDFEBAC, 0x00000000) = 0 close(3) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF320000 memcntl(0xFFFFFD7FFEED0000, 89056, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 stat("/opt/local/lib//libc.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libc.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/opt/local/gcc47/lib/amd64/libc.so.1", 0xFFFFFD7FFFDFF050) Err#2 ENOENT stat("/lib/64/libc.so.1", 0xFFFFFD7FFFDFF050) = 0 resolvepath("/lib/64/libc.so.1", "/lib/amd64/libc.so.1", 1023) = 20 open("/lib/64/libc.so.1", O_RDONLY) = 3 mmapobj(3, MMOBJ_INTERPRET, 0xFFFFFD7FFF320A68, 0xFFFFFD7FFFDFEBAC, 0x00000000) = 0 close(3) = 0 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF170000 memcntl(0xFFFFFD7FFF180000, 465912, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFFFFFD7FFF160000 getcontext(0xFFFFFD7FFFDFF3B0) getrlimit(RLIMIT_STACK, 0xFFFFFD7FFFDFF710) = 0 getpid() = 23127 [23126] lwp_private(0, 0, 0xFFFFFD7FFF162A80) = 0x00000000 setustack(0xFFFFFD7FFF162B28) lwp_cond_broadcast(0xFFFFFD7FFF1701A8) = 0 lwp_cond_broadcast(0xFFFFFD7FFF3201A8) = 0 lwp_cond_broadcast(0xFFFFFD7FFF3501A8) = 0 lwp_cond_broadcast(0xFFFFFD7FFF3301A8) = 0 sysi86(SI86FPSTART, 0xFFFFFD7FFFDFFC3C, 0x0000133F, 0x00001F80) = 0x00000001 brk(0x0063E270) = 0 brk(0x00642270) = 0 time() = 1435265935 time() = 1435265935 sigfillset(0xFFFFFD7FFF319500) = 0 schedctl() = 0xFFFFFD7FFF15D000 sigaction(SIGUSR1, 0xFFFFFD7FFFDFF8E0, 0x00000000) = 0 sigaction(SIGUSR2, 0xFFFFFD7FFFDFF8E0, 0x00000000) = 0 sysconfig(_CONFIG_SEM_VALUE_MAX) = 2147483647 mmap(0x00000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF05C000 brk(0x00642270) = 0 brk(0x00646270) = 0 brk(0x00646270) = 0 brk(0x0064A270) = 0 brk(0x0064A270) = 0 brk(0x0064E270) = 0 clock_getres(4, 0xFFFFFD7FFFDFF940) = 0 clock_getres(4, 0xFFFFFD7FFFDFF920) = 0 clock_gettime(4, 0xFFFFFD7FFFDFF930) = 0 priocntlsys(1, 0xFFFFFD7FFFDFF7B0, 3, 0xFFFFFD7FFFDFF8E8, 0) = 23127 priocntlsys(1, 0xFFFFFD7FFFDFF7B0, 1, 0xFFFFFD7FFFDFF918, 0) = 4 sysconfig(_CONFIG_PAGESIZE) = 4096 sigaction(SIGSEGV, 0xFFFFFD7FFFDFF950, 0xFFFFFD7FFFDFFA58) = 0 sigaction(SIGBUS, 0xFFFFFD7FFFDFF950, 0xFFFFFD7FFFDFFA78) = 0 sigaction(SIGSEGV, 0xFFFFFD7FFFDFF940, 0x00000000) = 0 sigaction(SIGBUS, 0xFFFFFD7FFFDFF940, 0x00000000) = 0 mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, 4294967295, 0) = 0xFFFFFD7FFF040000 ioctl(1, TCGETA, 0xFFFFFD7FFFDFE670) = 0 fstat(1, 0xFFFFFD7FFFDFE5F0) = 0 brk(0x0064E270) = 0 brk(0x00652270) = 0 munmap(0xFFFFFD7FFF05C000, 1048576) = 0 munmap(0x00000000, 0) Err#22 EINVAL lseek(0, 0, SEEK_CUR) = 6056 (Bad file number)write(1, " ( B a d f i l e n".., 18) = 18 _exit(0) [root smartDmachine ~]#
Jun 25 2015
prev sibling parent Jason King via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
May 03 2015