Home » Community » U++ community news and announcements » U++/Win32 is now using CLANG toolchain
| U++/Win32 is now using CLANG toolchain [message #53107] |
Mon, 02 March 2020 00:38  |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
I have found this wonderful little project:
https://github.com/mstorsjo/llvm-mingw
which provides CLANG toolchain in windows. This is great match for several reasons:
- it is multichain, single compiler for both 32 and 64 bits, which results in nice small footprint - in fact, I have dropped "without toolchain" windows version, it is now single 140MB .7z file...
- it has good optimal TLS support, unlike gcc in win32
- it is actually able to produce .pdb compatible debug info. That means we can use the same (superior) debugger as for Microsoft C++, including "smart" parts that now display U++ types (!) There are some issues that I plan to gradually fix with workarounds, but overal this seems to work prette well.
Currently it has some downsides too, namely
- targets Windows universal CRT (instead of MSVCRT.dll), which means that for previous versions you need to ship some .dlls with your application. This might or might not be fixed in future...
- being there, it was not possible to have single static linked OpenSSL library for both clang and msvc, so I have gave up and OpenSSL is once again linked dynamically (just as SDL2, MYSQL, PGSQL are)
- there are some issues with weak references, which affected global new/delete overloading )https://github.com/mstorsjo/llvm-mingw/issues/91), but we have workaround for now
- there is also some issue with std::chrono timers, not able to reproduce, but I needed to revert 'msecs' function to older code to fix some weird issues in theide.
Overal, this is a great step forward, next release will be great!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53243 is a reply to message #53127] |
Tue, 24 March 2020 20:05  |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
Is it possible to take a look at the bazaar/Protect with CLANG? I already noticed that removing file xed/VERSION fixes the compilation issue of Xed package that Protect uses.
However, something goes wrong when running ProtectEncrypt for an exe file created with CLANG.
-
Also, I use some external static libraries and they in turn have some Windows library dependencies that are not being satisfied:
Linking...
lld-link: error: could not open 'libLIBCMT.a': No such file or directory
lld-link: error: could not open 'libOLDNAMES.a': No such file or directory
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
There were errors. (0:00.50)
In reality these libraries are called 'libcmt.lib' and 'oldnames.lib' and are included with e.g. MSBT. Any suggestions how to proceed here?
Best regards,
Tom
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53245 is a reply to message #53244] |
Wed, 25 March 2020 08:57 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Mirek,
Adding the libs manually
when: WIN32
Libraries: ../lib/libcmt.lib ../lib/liboldnames.lib
introduces a different issue:
Linking...
lld-link: error: duplicate symbol: atexit
>>> defined at ../crt\crtexe.c:438
>>> C:\upp-svn\bin\clang\x86_64-w64-mingw32\lib\crt2.o
>>> defined at libcmt.lib(utility.obj)
lld-link: error: duplicate symbol: __dyn_tls_init
>>> defined at d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\tls\tlsdyn.cpp:87
>>> libcmt.lib(tlsdyn.obj)
>>> defined at ../crt\tlssup.c:77
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
lld-link: error: duplicate symbol: __dyn_tls_init_callback
>>> defined at libcmt.lib(tlsdyn.obj)
>>> defined at ../crt\tlssup.c:103
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
lld-link: error: duplicate symbol: _onexit
>>> defined at d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\utility\utility.cpp:256
>>> libcmt.lib(utility.obj)
>>> defined at ../crt\ucrtbase_compat.c:86
>>> libmsvcrt.a(lib64_libucrt_extra_a-ucrtbase_compat.o)
lld-link: error: duplicate symbol: _tls_index
>>> defined at ../crt\tlssup.c:35
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
>>> defined at libcmt.lib(tlssup.obj)
lld-link: error: duplicate symbol: _tls_start
>>> defined at ../crt\tlssup.c:41
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
>>> defined at libcmt.lib(tlssup.obj)
lld-link: error: duplicate symbol: _tls_end
>>> defined at ../crt\tlssup.c:42
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
>>> defined at libcmt.lib(tlssup.obj)
lld-link: error: duplicate symbol: __xl_a
>>> defined at ../crt\tlssup.c:44
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
>>> defined at libcmt.lib(tlssup.obj)
lld-link: error: duplicate symbol: __xl_z
>>> defined at ../crt\tlssup.c:45
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
>>> defined at libcmt.lib(tlssup.obj)
lld-link: error: duplicate symbol: _tls_used
>>> defined at ../crt\tlssup.c:47
>>> libmingw32.a(lib64_libmingw32_a-tlssup.o)
>>> defined at libcmt.lib(tlssup.obj)
lld-link: error: could not open 'liblibvcruntime.a': No such file or directory
lld-link: error: could not open 'liblibucrt.a': No such file or directory
lld-link: error: could not open 'libLIBCMT.a': No such file or directory
lld-link: error: could not open 'libOLDNAMES.a': No such file or directory
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
There were errors. (0:00.50)
So adding the libraries yields duplicate symbols while adding yet more unsatisfied dependencies. Unfortunately, they still do not satisfy the requirement for the strange 'libLIBCMT.a' and 'libOLDNAMES.a'. (I also tried to copy the original files to these names, but that did not work either.)
I wonder if I should create a couple of dummy libraries with no public symbols and give them names 'libLIBCMT.a' and 'libOLDNAMES.a'...
Any suggestions to try?
Best regards,
Tom
[EDIT] Well, those dummy empty libraries with names 'libLIBCMT.a' and 'libOLDNAMES.a' did not help either.
[Updated on: Wed, 25 March 2020 09:27] Report message to a moderator |
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53253 is a reply to message #53250] |
Wed, 25 March 2020 12:52 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
I use some special devices that are accompanied by static libraries to be used to access those devices. When I add those specific libraries (lib files) into the project, the requirement for these two (old) Windows libraries appear.
Best regards,
Tom
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53257 is a reply to message #53255] |
Wed, 25 March 2020 13:24 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
OK, I need to check that separately.
As a matter of fact I never really used MINGW version as ... well I cannot remember exactly, but it did not work for me.
Can you point out where to download the last MINGW version?
Best regards,
Tom
[EDIT] Nevermind... I found the 2019.2 MINGW on sourceforge.net...
[Updated on: Wed, 25 March 2020 13:57] Report message to a moderator |
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53268 is a reply to message #53263] |
Wed, 25 March 2020 15:37 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
OK, upp-mingw-13664 tested. The same result as with CLANG:
Linking...
lld-link: error: could not open libLIBCMT.a: no such file or directory
lld-link: error: could not open libOLDNAMES.a: no such file or directory
collect2.exe: error: ld returned 1 exit status
Also, if I explicitly give the libraries, the behavior follows that of CLANG.
--
BTW: It seems that MINGW is not able to deal with GDAL/OGR source properly... and some other packages too. I guess this was one of my reasons to drop it.
Best regards,
Tom
|
|
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53285 is a reply to message #53284] |
Thu, 26 March 2020 12:00 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Mirek,
Actually, I think it is not about missing symbols at all...
I opened the binary .lib file and noticed that it contains the following text string:
/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES"
IMO, these are the problem. I just can't figure out how to remove these dependencies cleanly. All my attempts with binary editing resulted in invalid library file.
Is there some LIB or AR command that could be used to remove these? Then I could see missing symbols and try to fix them.
Best regards,
Tom
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53291 is a reply to message #53285] |
Thu, 26 March 2020 16:55 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
One step forward...
when: WIN32 CLANG
Link options: -Xlinker /NODEFAULTLIB:OLDNAMES -Xlinker /NODEFAULTLIB:LIBCMT
This prevents those default libs to be linked.
However, this comes with a price tag:
Linking...
lld-link: error: undefined symbol: __GSHandlerCheck
lld-link: error: undefined symbol: __security_check_cookie
lld-link: error: undefined symbol: __report_rangecheckfailure
lld-link: error: undefined symbol: __chkstk
lld-link: error: undefined symbol: _fltused
lld-link: error: undefined symbol: EnumPrintersA
lld-link: error: undefined symbol: OpenPrinterA
lld-link: error: undefined symbol: SetPrinterA
lld-link: error: undefined symbol: ClosePrinter
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
There were errors. (0:00.61)
Best regards,
Tom
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53293 is a reply to message #53291] |
Thu, 26 March 2020 17:26 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
And here's finally the solution to this game. Had to add fake functions to satisfy the dependencies. I know these functions do not do anything, but I decided not to really need those anyway...
#ifdef __MINGW32__
extern "C"{
void __cdecl __GSHandlerCheck() { }
void __cdecl __security_check_cookie(uintptr_t i) { }
void __cdecl __chkstk() { }
void __cdecl __report_rangecheckfailure() { }
void __cdecl _fltused() { }
WINBOOL WINAPI EnumPrintersA(DWORD Flags,LPSTR Name,DWORD Level,LPBYTE pPrinterEnum,DWORD cbBuf,LPDWORD pcbNeeded,LPDWORD pcReturned) { return false; }
WINBOOL WINAPI OpenPrinterA(LPSTR pPrinterName,LPHANDLE phPrinter,LPPRINTER_DEFAULTSA pDefault) { return false; }
WINBOOL WINAPI SetPrinterA(HANDLE hPrinter,DWORD Level,LPBYTE pPrinter,DWORD Command) { return false; }
WINBOOL WINAPI ClosePrinter(HANDLE hPrinter) { return false; }
}
#endif //__MINGW32__
One more library to go... with a different challenge.
Best regards,
Tom
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #53296 is a reply to message #53295] |
Thu, 26 March 2020 18:57 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
The above solution is actually easier for me as I do not need to maintain separate dummy empty libs. The lines of code required can be included in the module using the library so it is quite straight forward in this special case.
Thanks and best regards,
Tom
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #54549 is a reply to message #53299] |
Thu, 13 August 2020 12:13 |
Oblivion
Messages: 1264
Registered: August 2007
|
Senior Contributor |
|
|
Hello Mirek,
One problem I've noticed about CLANG on windows: Windows 10 api doesn't seem to be supported by Upp. They cant't be compiled because some of them are conditionally included (ver >= 0x0A00, ver >= 0x0700, etc.)
(I've noticed this while implementing the windows 10 pseudoconsole API support for terminal ctrl.)
The headers, and prototypes are already included in CLANG bundle but It requires manual intervention in Core/config.h to change _WIN32_WINNT from 0x0501 to 0x0A00. (redefining it elsewhere doesn't seem to work either; or at least I couldn't find a simple way)
If I set the version number to 0x0A00 everthing compiles fine on CLANG.
(Also, there is no such problem with MSVC 19. It does not require any intervention.)
Is there a workaround for this problem? (may be a flag in TheIDE's main configuration, etc. ?)
Best regards,
Oblivion
Github page: https://github.com/ismail-yilmaz
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Thu, 13 August 2020 12:26] Report message to a moderator |
|
|
|
|
|
|
|
| Re: U++/Win32 is now using CLANG toolchain [message #54592 is a reply to message #54550] |
Tue, 18 August 2020 20:31 |
Oblivion
Messages: 1264
Registered: August 2007
|
Senior Contributor |
|
|
Hello Mirek,
Can we set the definitions in config.h to:
#ifdef flagWIN10
#define _WIN32_WINNT _WIN32_WINNT_WIN10
#undef NTDDI_VERSION
#define NTDDI_VERSION NTDDI_WIN10_19H1
#else
#define _WIN32_WINNT _WIN32_WINNT_WINXP
#endif
Apparently CLANG Windows 10 api requires setting both the _WIN32_WINNT amd NTDDI_VERSION, to properly -fully- work.
It seems that both versioning constants have to match, and the default NTDDI is set to WINXP.
The WIN10_19H1 is the latest windows 10 upgrade that our CLANG bundle supports. (Gives better Win10 api access to driver kits, which pseudoconsole requires. It doesn't seem to break anything anyway.).
Best regards,
Oblivion
Github page: https://github.com/ismail-yilmaz
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Tue, 18 August 2020 20:37] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Sun Apr 26 05:56:04 GMT+2 2026
Total time taken to generate the page: 0.01036 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
