What's up with GDC?
Joerg Joergonson via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun Jun 12 06:01:55 PDT 2016
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)
More information about the Digitalmars-d-learn
mailing list