www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - undefined identifier FILE for mingw

reply Innot Sagg <donovinsbbkgbi gmail.com> writes:
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 ?
Jul 06 2020
next sibling parent reply Innot Sagg <donovinsbbkgbi gmail.com> writes:
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()
Jul 06 2020
parent reply Innot Sagg <donovinsbbkgbi gmail.com> writes:
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
Jul 06 2020
parent Innot Sagg <donovinsbbkgbi gmail.com> writes:
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.
Jul 06 2020
prev sibling parent reply kinke <noone nowhere.com> writes:
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.
Jul 06 2020
next sibling parent reply Innot Sagg <donovinsbbkgbi gmail.com> writes:
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)
Jul 06 2020
parent Innot Sagg <donovinsbbkgbi gmail.com> writes:
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)
Jul 06 2020
prev sibling parent Calvin P <changlon gmail.com> writes:
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.
Jul 09 2020