|
|
|
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: 14257
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: 1303
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: 1303
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: 1303
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: 1303
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: 1303
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: 1303
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
|
|
|
|
Goto Forum:
Current Time: Fri May 09 21:58:55 CEST 2025
Total time taken to generate the page: 0.01094 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
