On Sunday, 12 June 2016 at 05:08:12 UTC, Mike Parker wrote:
On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:
1. I had an older distro(I think) of ldc. The ldc2.exe is 18MB
while the "new" one is 36MB. I copied the old ldc bin dir to
the new one and didn't change anything and everything compiled
EXCEPT
That's just asking for problems. You may get lucky and find
that it works, but in general you don't want to go around
swapping compiler executables like that.
2. I got an error that I don't get with dmd:
Error: incompatible types for ((ScreenPainter) !is (null)):
cannot use '!is' with types
and I have defined ScreenPainter in my code. It is also in
arsd's simpledisplay. I do not import simpledisplay directly:
The code is
import arsd.gamehelpers;
auto window = create2dWindow(cast(int)width, cast(int)height,
cast(int)ViewportWidth, cast(int)ViewportHeight, title);
// Let the gui handle painting the screen
window.redrawOpenGlScene = {
if (ScreenPainter !is null || !ScreenPainter()) <--- error
...
};
I have defined ScreenPainter elsewhere in the module.
So ScreenPainter is a *type* and not an instance of a type?
That *should* be an error, no matter which compiler you use.
You can't compare a type against null. What does that even
mean? And if SimpleDisplay already defines the type, why have
you redefined it?
Assuming ScreenPainter is a class, then:
if(ScreenPainter !is null) <-- Invalid
auto sp = new ScreenPainter;
if(sp !is null) <-- valid
I can fix this by avoiding the import... but the point is that
it's different than dmd.
If ScreenPainter is defined as a type, it shouldn't ever
compile. How have you defined it?
So ldc parses things differently than dmd... I imagine this is
a bug!
LDC and DMD share the same front end, meaning they parse code
the same. I really would like to see your code, particularly
your definition of ScreenPainter.
Although, If I set the subsystem to windows I then get the
error
error LNK2019: unresolved external symbol WinMain referenced
in function "int __cdecl __scrt_common_main_seh(void)"
(?__scrt_common_main_seh@@YAHXZ)>
Which looks like it's not linking to runtime and/or phobos?
No, this has nothing to do with DRuntime, Phobos, or even D.
It's a Windows thing. By default, when you compile a D program,
you are creating a console system executable so your primary
entry point is an extern(C) main function that is generated by
the compiler. This initializes DRuntime, which in turn calls
your D main function.
When using OPTLINK with DMD, the linker will ensure that the
generated extern(C) main remains the entry point when you set
the subsystem to Windows. When using the MS linker, this is not
the case. The linker will expect WinMain to be the entry point
when the subsystem is set to Windows. If you do not have a
WinMain, you will see the error above. In order to keep the
extern(C) main as your entry point, you have to pass the /ENTRY
option to the linker (see[1]). LDC should provide a means for
passing linker options. You can probably set in VisualD's
project settings, but if there's no field for it then ldc2
--help may tell you what you need.
Alternatively, you can create a WinMain, but then you need to
initialize DRuntime yourself. See [2], but ignore the .def file
requirement since you are already setting the subsystem.
I seriously don't know how anyone gets anything done with all
these problems ;/ The D community can't expect to get people
interested in things don't work. If it wasn't because the D
language was so awesome I wouldn't stick around! It's as if no
one does any real testing on this stuff before it's released ;/
Then I would ask you to stop and think. There are a number of
people using D without problems every day, including several
companies. Obviously, they aren't having the same difficulties
you are, else they wouldn't be successfully using D. You seem
to be very quick to blame the tools rather than considering you
might not fully understand how to use them. I don't mean that
in a disparaging way. I've been there myself, trying to get
something I wanted to use working and failing, then getting
frustrated and blaming the tools. These days, I always blame
yourself first. Sure, the tools sometimes have bugs and other
issues, but more often than not it's because I'm using them the
wrong way.
Right now, documentation on getting up to speed with LDC is
sorely lacking. That's a valid criticism to make. For people
who aren't familiar with it, or who aren't well versed in
working with ahead of time compilers, whichever the case may
be, it may not be the best choice for getting started with D.
Since you seem to be having difficulties using LDC and since
you've already told me that DMD is working for you, I strongly
recommend that you use DMD instead for now. Once you are
comfortable with D and the ecosystem, then look into using LDC.
1. LDC has a bug in it. Simple as that. Replacing ldc2's bin
dir with older ldc2 version essentially solved the
problem(that being it not parsing paths correctly).
2. LDC has a discontinuity with dmd. Maybe fixed in the latest
version... but I can't tell.
LDC may have bugs, but I don't believe the problem you talked
about above is one of them. I would really like to see all of
the code you are trying to compile. The error you saw was what
I would expect to see when trying to compare a type to null.
3. LDC x64 cannot find "winmain" or whatever while DMD does.
This is if the subsystem is set to windows. If set to console
it works but then windows app has console that pops up, which
is not acceptable. This too may have been fixed in the latest
ldc.
As I explained above, this is not a problem with LDC. The
compile-link process in D is the same as it is in C and C++ and
the generated Windows executables have the same requirements.
As it is not D specific, there are a number of pages on the
internet dealing with compiling and linking on Windows. Those
will help you when using D compilers as well. You just have to
adapt any compiler-specific command line arguments to the
compiler you are using. I strongly recommend you familiarize
yourself with the MS linker options, since it is prominent in
the D toolchain on Windows now.
[1] https://msdn.microsoft.com/en-us/library/f9t8842e.aspx
[2] https://wiki.dlang.org/D_for_Win32
1. Your mixing up my problems(maybe my fault, but that's not the
point). The phobo's errors are
simpledisplay.obj : error LNK2001: unresolved external symbol
__D10TypeInfo_w6__initZ
winmain.obj : error LNK2019: unresolved external symbol
__D4core6memory2GC7collectFNbZv (nothrow void
core.memory.GC.collect()) referenced in function __Dmain
winmain.obj : error LNK2019: unresolved external symbol
__d_run_main referenced in function _main
winmain.obj : error LNK2001: unresolved external symbol
__D4core7runtime12__ModuleInfoZ
LINK : error LNK2001: unresolved external symbol
__load_config_used
../ldc2/bin/../lib64\phobos2-ldc.lib : warning LNK4272: library
machine type 'x64' conflicts with target machine type 'X86'
.../ldc2/bin/../lib64\druntime-ldc.lib : warning LNK4272: library
machine type 'x64' conflicts with target machine type 'X86'
This happens only when I compile to x86. X64 works fine. The dir
is the ldc dir, not mine. This suggests druntim-ldc.lib is x64
and not x86. (As one can see from lib64, why it is being used
instead of lib32 is beyond me... but I don't see that in any of
my configurable settings)
The best I can tell is that ldc:
// This configuration file uses libconfig.
// See http://www.hyperrealm.com/libconfig/ for syntax details.
// The default group is required
default:
{
// 'switches' holds array of string that are appends to the
command line
// arguments before they are parsed.
switches = [
"-I%%ldcbinarypath%%/../include/d/ldc",
"-I%%ldcbinarypath%%/../include/d",
"-L-L%%ldcbinarypath%%/../lib64",
"-defaultlib=phobos2-ldc,druntime-ldc",
"-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
];
};
i686-pc-windows-msvc:
{
// 'switches' holds array of string that are appends to the
command line
// arguments before they are parsed.
switches = [
"-I%%ldcbinarypath%%/../include/d/ldc",
"-I%%ldcbinarypath%%/../include/d",
"-L-L%%ldcbinarypath%%/../lib32",
"-defaultlib=phobos2-ldc,druntime-ldc",
"-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
];
};
is defaulting to x64 and not using the lib32 dir like it should.
Getting it to should lib32 should fix the compilation problem.
The -L/Entry thing did fix the x64 windows subsystem problem...
so everything is working now for x64.
2. The type bug seems to be a change in dmd/ldc. It is an import
issue. I used the same name as Adam and for some reason ldc
imports his into my project and dmd does not. See his post for
that.
3. There is definitely a bug in the latest ldc... Swapping
binaries may be a bad thing to you but it's the only way I could
quickly diagnose the problem. I'd rather pack a wound with mud
then let someone bleed out and die because mud is unsanitary. It
proves there is a problem with ldc since the "correct"
installation doesn't work in the first place and simply swapping
the binaries makes it work. (basic math here)
