Re: Warning, ABI breakage from 2.074 to 2.075
On May 26, 2017 at 12:11:09 AM, Nick Sabalausky (Abscissa) via Digitalmars-d (digitalmars-d@puremagic.com) wrote: On 05/25/2017 01:04 PM, Jason King via Digitalmars-d wrote: > > I have no problems with an unstable ABI, what I have a problem is with > claiming to be a systems programming language AND not having a stable ABI. > You realistically cannot have both Why? Unless it’s a completely self contained system, if you are operating at the systems level, you are going to be providing the foundations for other people’s code to build on (vs. application level stuff where you’re already at the top). Just imagine if every time you applied Windows updates or applied a security fix to your OS of choice you had to rebuild every piece of software you have, and if providing it to others, provide corresponding versions of your code with every update and fix that was released with your OS — not because anything of yours changed, but because just because you wanted to fix a problem with the underlying system. Trying to build something on top of an unstable ABI is building your foundations on sand. All I’m saying is if no attention is going to be paid to this (it doesn’t mean you can’t change the ABI, but it needs to be managed it better than ‘whoops!’), just stop claiming the systems bit and stay up stack where this isn’t a problem.
Re: Warning, ABI breakage from 2.074 to 2.075
And how many of those are claiming to be a systems programming language? I have no problems with an unstable ABI, what I have a problem is with claiming to be a systems programming language AND not having a stable ABI. You realistically cannot have both — it seems like D is trying to have it’s cake and eat it too and I’m just pointing out that it’s going to lead to sadness. If there are no plans to ever have a stable ABI, that’s fine (may even be good for the long term usage of the language), just drop the whole systems programming language bit and focus more on application level, but I’ve not really seen any recognition of that. On May 25, 2017 at 11:41:52 AM, Joakim via Digitalmars-d ( digitalmars-d@puremagic.com) wrote: On Thursday, 25 May 2017 at 15:36:38 UTC, Jason King wrote: > Yes it is a lot of work, which I strongly suspect is a big > reason why C still reigns supreme at the systems level — > because it does have a stable ABI which solves a lot of > headaches from a systems point of view (obviously momentum and > history are also very big reasons). > > If that’s the direction D wants to go in, there’s nothing wrong > with that, > but it needs to be setting the correct expectations for users. > Not having > a stable ABI is perfectly fine for application level stuff, but > it can be > rather (in some cases extremely) problematic for systems level > stuff--that > needs to be understood both by the users and the people working > on D (and I > haven’t really seen much recognition of it). > > On May 25, 2017 at 10:25:59 AM, Jack Stouffer via Digitalmars-d > ( > digitalmars-d@puremagic.com) wrote: > > On Thursday, 25 May 2017 at 15:02:00 UTC, Jason King wrote: >> That’s a fairly important requirement if it’s supposed to be a >> systems programming language, less so for application focused >> stuff. I would hope it’s at least an eventual goal even if >> it’s not quite the case today. > > The reason we don't have ABI compatibility is the same reason > neither Rust or Go does, it's a lot of work for a minority of > users and it stops the language from progressing. > > Maybe D will have it eventually due to pressure from large D > using companies, but I highly doubt it. There was a long thread last month about getting dmd into Debian, that discussed the ABI stability issue among others: https://forum.dlang.org/thread/hhefnnighbowonxsn...@forum.dlang.org ABI stability is not promised, not now or anytime soon, not just from D but many languages, as Jack said. It just doesn't make sense.
Re: Warning, ABI breakage from 2.074 to 2.075
Yes it is a lot of work, which I strongly suspect is a big reason why C still reigns supreme at the systems level — because it does have a stable ABI which solves a lot of headaches from a systems point of view (obviously momentum and history are also very big reasons). If that’s the direction D wants to go in, there’s nothing wrong with that, but it needs to be setting the correct expectations for users. Not having a stable ABI is perfectly fine for application level stuff, but it can be rather (in some cases extremely) problematic for systems level stuff--that needs to be understood both by the users and the people working on D (and I haven’t really seen much recognition of it). On May 25, 2017 at 10:25:59 AM, Jack Stouffer via Digitalmars-d ( digitalmars-d@puremagic.com) wrote: On Thursday, 25 May 2017 at 15:02:00 UTC, Jason King wrote: > That’s a fairly important requirement if it’s supposed to be a > systems programming language, less so for application focused > stuff. I would hope it’s at least an eventual goal even if > it’s not quite the case today. The reason we don't have ABI compatibility is the same reason neither Rust or Go does, it's a lot of work for a minority of users and it stops the language from progressing. Maybe D will have it eventually due to pressure from large D using companies, but I highly doubt it.
Re: Warning, ABI breakage from 2.074 to 2.075
That’s a fairly important requirement if it’s supposed to be a systems programming language, less so for application focused stuff. I would hope it’s at least an eventual goal even if it’s not quite the case today. On May 25, 2017 at 8:26:04 AM, Joakim via Digitalmars-d ( digitalmars-d@puremagic.com) wrote: On Thursday, 25 May 2017 at 10:42:44 UTC, Basile B. wrote: > Static libraries that are > - compiled with dmd 2.074 (maybe previous versions too) > - call format() in their API > > will be responsible for strange errors when used by programs > compiled with dmd 2.075. People will see their software raising > a FormatException (orphan argument) for no reason. When the > static library will be recompiled with dmd 2.075 the errors > will disappear. > > I haven't investigated much since there's been a non trivial > amount of change in std.format() during the this spring. I > don't know what to do with this facts except to report them > here. Why is this unexpected? D has never committed to ABI stability across compiler versions or the different D compilers.
Re: Building DMD on SmartOS
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!
Re: Building DMD on SmartOS
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, 0xFD7FFFDFFC88, 0xFD7FFFDFFC98) argc = 1
sysinfo(SI_MACHINE, i86pc, 257) = 6
mmap(0x, 56, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
4294967295, 0) = 0xFD7FFF39
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF38
mmap(0x, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON,
4294967295, 0) = 0xFD7FFF37
mmap(0x, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON,
4294967295, 0) = 0xFD7FFF36
memcntl(0xFD7FFF398000, 96976, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF35
memcntl(0x0040, 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, 0xFD7FFFDFF960) = 0
open(/var/ld/64/ld.config, O_RDONLY) = 3
fstat(3, 0xFD7FFFDFF6C0)= 0
mmap(0x, 160, PROT_READ, MAP_SHARED, 3, 0) = 0xFD7FFF34
close(3)= 0
stat(/opt/local/lib//libpthread.so.1, 0xFD7FFFDFF050) Err#2 ENOENT
Re: Building DMD on SmartOS
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.
Re: Building DMD on SmartOS
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!
Re: Building DMD on SmartOS
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.
Re: Building DMD on SmartOS
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
Re: Building DMD on SmartOS
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:zhcduibirwprgbzqk...@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.
Re: Any libunwind experts n da house?
I believe pretty much anything *ix on 64-bit(at least) x86 (32-bit gets a bit murkier due to historical issues) is using the same exception handling ABI (which itself was based off the Itanic ABI): http://www.x86-64.org/documentation/abi.pdf On Tue, Sep 23, 2014 at 1:31 PM, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 9/23/2014 11:03 AM, David Nadlinger wrote: On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei Alexandrescu wrote: We need a libunwind expert to figure out a good approach for handling exceptions thrown by C++ code into D. Is anyone fluent with libunwind? More or less. What exactly are your goals? I thought the options we have are fairly clear, as discussed a few days ago. At least, Amaury and I seemed to agree (both of us worked on EH recently). The main question to decide is whether you want to go down the catch-C++-exceptions-in-D rabbit hole. One goal is to have dmd use the g++ exception handling mechanism. But googling how that works, I find dead links, specs that are 15 years old accompanied by vague comments about it being extended and look at the g++ source code, etc. Are there any actual docs about how it works for x86? Or is it the usual take apart the output of g++ and figure it out that I usually wind up doing :-( ?
Re: SImple C++ code to D
On Monday, 14 July 2014 at 14:50:36 UTC, Alexandre wrote: Yes yes, I did it, I used the anonymous type Look the complete code: https://gist.github.com/bencz/3576dfc8a217a34c05a9 I know, has several things that can be improved Now that you've done that, can you build us a linker that reads COFF libs so we can lose optlink:)
Re: DMDScript
My idea is to use (at least test) DMDScript for server side JS. I don't mean to sound like a D-hater here, but V8 has had about 2 years more work on it than DMDScript. At one time they were. IIRC, quite close performance-wise but lots of work and support by Google have probably levered past the advantages of being coded in D. My 2c only.
Re: DMDScript
On Friday, 11 July 2014 at 15:45:42 UTC, Chris wrote: Tried to compile on linux, got this error message (I guess I can fix it): dmd -c textgen.d textgen.d(36): Error: cannot implicitly convert expression (DMDScript fatal runtime error: ) of type string to char[] .. bunch more errors. You might try https://github.com/DmitryOlshansky/DMDScript which, according to it's notes has changes to make it compatible with D2.
Re: implib and system dlls, oh my
You may want to spearhead the effort to get Win32 support of MSVC into D, if you care enough about it. Rainer has done most of the work, you'd just have to turn his patches into pull requests, shepherd them through the review process, and maybe add some polish: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com I'd love to, but that might be a little over my head. I see he forked from 2.060 and now we're almost in 2.066. I'd have to radically improve my git fu and my D fu to be able to bring the patches up to 2.066. I'm on some extended time off in a couple of weeks for some surgery, this might be a project to while away the recovery days.
Re: implib and system dlls, oh my
Let me see what I can do for time. There's the above, it's also possible to link mixed coff and omf with jwlink (http://www.japheth.de/JWlink/JWlink.htm). There's a couple of paths and while win32 isn't leading edge, I think enhancing it is a worthwhile project for lesser lights like myself. I've tried the above and get a horde of errors. Some seem to be weak link __symbol doesn't match the library's _symbol (two leading underbars on one side, one on the other). Some seem to be some utterly missing capitalized symbols like GETLONG, GETPOINTER and STRLEN2. The underbar mismatches I should be able to fix with a def file or maybe there's a (j)wlink option I missed to resolve those. As I make progress, such as it is, I'll report. Anybody who sees something I've missed feel free to chime in. While I'm learning I have no pride, I save it for pride in having learned.
Re: implib and system dlls, oh my
You may want to spearhead the effort to get Win32 support of MSVC into D, if you care enough about it. Rainer has done most of the work, you'd just have to turn his patches into pull requests, shepherd them through the review process, and maybe add some polish: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com Let me see what I can do for time. There's the above, it's also possible to link mixed coff and omf with jwlink (http://www.japheth.de/JWlink/JWlink.htm). There's a couple of paths and while win32 isn't leading edge, I think enhancing it is a worthwhile project for lesser lights like myself.
Re: Why is the Win32 boilerplate the way it is?
On Monday, 30 June 2014 at 05:30:23 UTC, Jeremy Sorensen wrote: Assuming the nCmdShow thing isn't a problem I see no reason why the wiki should tell people to use WinMain at all. If MSDN is to be believed VOID WINAPI GetStartupInfo( _Out_ LPSTARTUPINFO lpStartupInfo ); will get you nCmdShow and lots of other goodies.
Re: Why is the Win32 boilerplate the way it is?
On Monday, 30 June 2014 at 15:19:39 UTC, Adam D. Ruppe wrote: On Monday, 30 June 2014 at 15:14:24 UTC, Jeremy Sorensen wrote: documentation means import core.sys.windows.windwos The Windows headers that come with D are pathetically minimal. You'll need to grab a more complete win32 header OR copy/paste the individual prototypes off MSDN and use them that way. This is a more complete set of windows api headers https://github.com/AndrejMitrovic/WindowsAPI
Re: rehabilitating Juno
FYI after running coffimplib over SDK versions of oleaut32.lib and gdiplus.lib I've gotten all the examples in the makefile to run. Next up for me is to get tlbimpld compiling and I'll fork and do a pull request to add that to the makefile.
system dlls + implib
I just (with Rikki Catermolle's kind help) worked out a problem who's genesis was an old version of oleaut32.lib in the dmd directories. I wound up creating the missing entry via coffimplib and the windows sdk. Were I less hard-headed that would have stopped me in my tracks. If we can include newer windows system libs with DMD I'll be happy to generate them. If copyrights prevent distributing new libs but we can distribute the defs (so then all that's necessary is implib + the original system dll) I can do that, too. My preferred solution would be to take all the system libs in %D_HOME%\dmd2\windows\lib and replace them with the output of coffimplib vs. the corresponding libs in the Windows 8.1 SDK. 2nd solution (if first fails a copyright issue) would be to create those same def files so that then a person with windows and implib can fix the problem w/o the SDK.
Re: system dlls + implib
On Tuesday, 24 June 2014 at 13:55:27 UTC, Kagamin wrote: Windows SDK EULA prohibits redistribution. You can get defs from mingw project. I know I can get headers, but headers aren't the problem. The problem is that the libs already being distributed are woefully out of date.
implib and system dlls, oh my
On Tuesday, 24 June 2014 at 04:37:56 UTC, Rikki Cattermole wrote: On 24/06/2014 1:13 p.m., Jason King wrote: This is me trying to link with Juno and getting tantalizingly close to success. DMD home is d:\d so binaries are d:\d\dmd2\windows\bin (on path) Juno is in D:\dlang\Juno-Windows-Class-Library D:\dlang\Juno-Windows-Class-Library\juno.lib exists sc.ini is untouched D:\dlang\Juno-Windows-Class-Library\examples\comdmd -L+d:\dlang\Juno-Windows-Cl ass-Library\juno.lib -Id:\dlang\Juno-Windows-Class-Library events.d OPTLINK (R) for Win32 Release 8.00.15 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html d:\dlang\Juno-Windows-Class-Library\juno.lib(core) Error 42: Symbol Undefined _VarCmp@16 --- errorlevel 1 Looks like that's a Windows API function [0]. Get it to link with OleAut32 and it should work, if I'm correct. Thanks, Rikki There was a pragma(lib,oleaut32.lib) in one of the source files, so it should have been linking. The problem now is that the DM oleaut32.lib doesn't include a _VarCmp@16. I ran lib -l oleaut32.lib to get a list file. No exported _VarCmp@16. There were 400-odd lines of exports so I believe lib -l worked. If I run implib /s oleaut32.lib oleaut32.dll vs. a windows XP oleaut32.dll I get an oleaut32.lib that includes a _VarCmp (not _VarCmp@16). What's the secret sauce to creating an oleaut32.lib that's fully decorated? Is there a way to get a newer oleaut32.lib into the d distributions. The full dmc oleaut32.lib is also missing _VarCmp@16 so no joy there either.
Re: implib and system dlls, oh my
I don't know enough about implib to explain it. But another method that I believe should work is to use linker definition files. It'll allow optlink to work. Just add it to dmd, actually I believe it needs to be passed to Optlink (so -L it). Another fix, might be to use 64bit, but shouldn't be required. [0] http://www.dsource.org/projects/bindings/wiki/DefFiles/OleAut32 Rikki, Thank you for your kind attention. I spewed to the newsgroup and googled for an answer in the wrong order. It appears the solution to this problem is the combination of coffimplib + windows SDK. After using those on the SDK's oleaut32.lib I got a library with the properly decorated _VarCmp@16. Not your job, but this could probably be made simpler.
Missed it by THIS much
This is me trying to link with Juno and getting tantalizingly close to success. DMD home is d:\d so binaries are d:\d\dmd2\windows\bin (on path) Juno is in D:\dlang\Juno-Windows-Class-Library D:\dlang\Juno-Windows-Class-Library\juno.lib exists sc.ini is untouched D:\dlang\Juno-Windows-Class-Library\examples\comdmd -L+d:\dlang\Juno-Windows-Cl ass-Library\juno.lib -Id:\dlang\Juno-Windows-Class-Library events.d OPTLINK (R) for Win32 Release 8.00.15 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html d:\dlang\Juno-Windows-Class-Library\juno.lib(core) Error 42: Symbol Undefined _VarCmp@16 --- errorlevel 1 I'm pretty sure I've got the -L+ part right because when I didn't I got about 20 Symbol Undefined errors and if I leave out the -I part it doesn't even compile. What's the trick to get the link to work?
Bug 8859: Solaris port of the toolchain questions
So I've been working on Bug 8859 (really on Illumos which is the fork of the source that remained open after Oracle bought Sun, though for X86, they're still similar enough that this should for now work on either). To date, I've been doing my work with GDC (DMD was generating objects with some invalid ELF sections, so I figured I'd come back to that when I have more alcohol handy to put on my linker alien hat). After a few evenings of work, I've managed to get GDC to produce working binaries and to pass all the Druntime unit tests. I'm still working on getting the Phobos unit tests to pass, so it's not 100% ready yet. I have a couple of questions: 1. As there was a decent amount of added code (and a few fixes of the existing bits of Solaris support), would it be preferred to file individual bugs for each issue, or just put it all under 8859 once it's all working? 2. I noticed a lot of declarations that are identical and duplicated for all the *ix platforms, even when they are implementing a standard of some sort (e.g. the AF_ values are IANA assigned, one should expect them to have the same value everywhere, just perhaps some platforms perhaps not always having the latest list). Is the rationale to just match the corresponding system's .h files as close as possible vs. a more consolidated version using version blocks to contain the variation or implementation-defined portions?
rehabilitating Juno
This is specifically for Jesse K Phillips, Jesse, It appears we're both interested in Juno. You lack time and I lack D experience. What could a D clown do for your juno repository to get it functional again. The last time I grabbed the code and ran it vs. current D compiler I got a whole bunch of errors for what appear to be base D packages. Feel free to give me scutwork if that will help get Juno back into orbit.
Re: DIP61: Add namespaces to D
extern (C++, N.M) { void foo(); }
extern (C++) namespace N { namespace M { void foo(); }}
Excellent. Solves the problem, doesn't add new language elements.
Re: DIP61: Add namespaces to D
Is there some reason why
extern(c++, std::printf);
is rejected?
If the purpose here is to map c++ code and we are only worried
about namespaces in the c++ context, why not just make it
identical to the c++ declaration?
A pragma to indicate the name mangling scheme since MS and GCC
use different algorithms and possibly a block element to say
everything under here is in this namespace, may
extern(c++namespace, std) {
extern(c++,printf);
extern(c++,open);
}
I know my examples in real code would be extern(c) but this is
just for example purposes.
Having both namespaces and modules available in general D code is
needless complexity IMHO.
Re: My D book is now officially coming soon
On Monday, 3 March 2014 at 16:37:49 UTC, Adam D. Ruppe wrote: As some of you might know, I've been working on a D book over the last few months. It is now available as coming soon on the publisher's website: Packt is having a 1/2 price ebooks sale, so if you haven't gotten this yet, now would be the time. I just did.
