try build mingw from linux, get this error:

ldc2 -mtriple=x86_64-w64-mingw32 -betterC test.d

import core.stdc.stdio;
extern(C) int main(){
	return 0;
}


To fix this in druntime, we need a new version like: CRuntime_Mingw ?

or should reuse CRuntime_Glibc ?

On Monday, 6 July 2020 at 13:49:31 UTC, Innot Sagg wrote:
> try build mingw from linux, get this error:
>
> ldc2 -mtriple=x86_64-w64-mingw32 -betterC test.d
>
> import core.stdc.stdio;
> extern(C) int main(){
> 	return 0;
> }
>
>
> To fix this in druntime, we need a new version like: CRuntime_Mingw ?
>
> or should reuse CRuntime_Glibc ?

I apply this https://github.com/ldc-developers/druntime/pull/106 fix the issue.


when I try build the betterC app, I get a lot undefined symbol(same code work well on linux and osx):


.__postblit()
.__fieldPostblit()
.__ctor()

On Monday, 6 July 2020 at 20:55:29 UTC, Innot Sagg wrote:
> I apply this https://github.com/ldc-developers/druntime/pull/106 fix the issue.
>
>
> when I try build the betterC app, I get a lot undefined symbol(same code work well on linux and osx):
>
>
> .__postblit()
> .__fieldPostblit()
> .__ctor()


this is the after ddemangle message. the original symbol is like:

Test__postblitMFZv
Test__fieldPostblitMFNaNbNiNfZv

On Monday, 6 July 2020 at 20:57:31 UTC, Innot Sagg wrote:
> On Monday, 6 July 2020 at 20:55:29 UTC, Innot Sagg wrote:
>> I apply this https://github.com/ldc-developers/druntime/pull/106 fix the issue.
>>
>>
>> when I try build the betterC app, I get a lot undefined symbol(same code work well on linux and osx):
>>
>>
>> .__postblit()
>> .__fieldPostblit()
>> .__ctor()
>
>
> this is the after ddemangle message. the original symbol is like:
>
> Test__postblitMFZv
> Test__fieldPostblitMFNaNbNiNfZv


This error is throw when build with lto,  remove lto fix it.

On Monday, 6 July 2020 at 13:49:31 UTC, Innot Sagg wrote:
> To fix this in druntime, we need a new version like: CRuntime_Mingw ?
>
> or should reuse CRuntime_Glibc ?

Yeah, MinGW is a mess - it's actually based on the MS runtime, but overrides some MS symbols (e.g., all `long double` math functions, because they use 80-bit, not 64-bit as MSVC, and so also the scanf/printf function families) and adds some new functions for C99/Posix/GNU compatibility. [Most of these are obsolete by now since the MS runtime provides almost full C99 compatibility since their 2015 runtime.]

So in some cases, it would be CRuntime_Microsoft, in others CRuntime_Glibc, and in some others probably resorting to already existing version `MinGW` to differentiate.

On Monday, 6 July 2020 at 21:23:50 UTC, kinke wrote:
> On Monday, 6 July 2020 at 13:49:31 UTC, Innot Sagg wrote:
>> To fix this in druntime, we need a new version like: CRuntime_Mingw ?
>>
>> or should reuse CRuntime_Glibc ?
>
> Yeah, MinGW is a mess - it's actually based on the MS runtime, but overrides some MS symbols (e.g., all `long double` math functions, because they use 80-bit, not 64-bit as MSVC, and so also the scanf/printf function families) and adds some new functions for C99/Posix/GNU compatibility. [Most of these are obsolete by now since the MS runtime provides almost full C99 compatibility since their 2015 runtime.]
>
> So in some cases, it would be CRuntime_Microsoft, in others CRuntime_Glibc, and in some others probably resorting to already existing version `MinGW` to differentiate.

Thanks for the explain.

I think there is a bug:

==============================================
@nogc nothrow:
struct A {
	@disable this(this);
}
extern(C) int main(){

        return 0;
}
==============================================

ldc2 -betterC test.d -flto=full -mtriple=i686-w64-mingw32

lld-link: error: undefined symbol: __D4test1A10__postblitMFZv
>>> referenced by test.d
>>>               test.o

lld-link: error: undefined symbol: __D4test1A15__fieldPostblitMFNaNbNiNfZv
>>> referenced by test.d
>>>               test.o
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)

On Tuesday, 7 July 2020 at 06:44:45 UTC, Innot Sagg wrote:
> Thanks for the explain.
>
> I think there is a bug:
>
> ==============================================
> @nogc nothrow:
> struct A {
> 	@disable this(this);
> }
> extern(C) int main(){
>
>         return 0;
> }
> ==============================================
>
> ldc2 -betterC test.d -flto=full -mtriple=i686-w64-mingw32
>
> lld-link: error: undefined symbol: __D4test1A10__postblitMFZv
>>>> referenced by test.d
>>>>               test.o
>
> lld-link: error: undefined symbol: __D4test1A15__fieldPostblitMFNaNbNiNfZv
>>>> referenced by test.d
>>>>               test.o
> clang-10: error: linker command failed with exit code 1 (use -v to see invocation)



And one more problem only for mingw triple.  I redefine printf inside my module, and only import core.stdc.stdio : FILE, BUFSIZ, EOF, FOPEN_MAX, FILENAME_MAX, TMP_MAX;

linux & osx work well, on mingw:

Error: function my.stdio.printf at /d/src/my/stdio.d(206) conflicts with function core.stdc.stdio.printf at /usr/local/bin/../import/core/stdc/stdio.d(1309)

On Monday, 6 July 2020 at 21:23:50 UTC, kinke wrote:
>
> So in some cases, it would be CRuntime_Microsoft, in others CRuntime_Glibc, and in some others probably resorting to already existing version `MinGW` to differentiate.

Hi @kinke

I report this bugs at github: https://github.com/ldc-developers/ldc/issues/3500

can you confirm this issue ?

I test on windows with msvc native build, has the same problem.