Clang on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Clang on Windows

Boost - Dev mailing list
Hi,

Based on recent news:
Clang 6.0.0 is out with very decent support of the latest MSVC STL (15.6).
Chrome is built with clang on Windows.

So, maybe it is good time to include clang+windows into list of
supported configs, setup a CI worker with clang (clang-cl) on Windows?
Currently many boost libs already work fine, but some of them require
small tweaks like explicit BOOST_USE_WINDOWS_H etc.

--
Egor Pugin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list


On 09/03/2018 16:16, Egor Pugin via Boost wrote:

> Hi,
>
> Based on recent news:
> Clang 6.0.0 is out with very decent support of the latest MSVC STL (15.6).
> Chrome is built with clang on Windows.
>
> So, maybe it is good time to include clang+windows into list of
> supported configs, setup a CI worker with clang (clang-cl) on Windows?
> Currently many boost libs already work fine, but some of them require
> small tweaks like explicit BOOST_USE_WINDOWS_H etc.

A cursory check suggests the compiler is working OK and builds
Boost.Config's tests, but I'm unable to get it working at all with
Boost.Build, I'm trying:

using clang-win : : "C:/Program Files/LLVM/bin/clang-cl.exe" :
<compatibility>vc14.1 ;

In my user-config.jam - note that the <compatibility> option appears to
be required, and there is not default, likewise the semi-documented
option <compatibility>native gets rejected as invalid.

In any case this leads to:

  $ ../../../b2 config_info clang-win
C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in
argument <cxxflags>-std:c++latest
..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in
argument <define>$(flag)=1
M:/data/boost/boost/tools/build/src/tools\msvc.jam:900: in set-setup-command
*** argument error
* rule virtual-target.from-file ( file : file-loc : project )
* called with: (  : /M:/data/boost/boost/libs/config/test :
object(project-target)@129 )
* missing argument file
M:/data/boost/boost/tools/build/src/build\virtual-target.jam:970:see
definition of rule 'virtual-target.from-file' being called
M:/data/boost/boost/tools/build/src/tools\msvc.jam:465: in
clang-win.compile.c++
M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in
modules.call-in
M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in indirect.call
M:/data/boost/boost/tools/build/src/build\virtual-target.jam:902: in execute
M:/data/boost/boost/tools/build/src/build\virtual-target.jam:821: in
[hidden email]
M:/data/boost/boost/tools/build/src/build\virtual-target.jam:332: in
actualize-action
M:/data/boost/boost/tools/build/src/build\virtual-target.jam:518: in
actualize-no-scanner
M:/data/boost/boost/tools/build/src/build\virtual-target.jam:142: in
[hidden email]
M:/data/boost/boost/tools/build/src/build\configure.jam:258: in
try-find-build
M:/data/boost/boost/tools/build/src/build\configure.jam:391: in
find-builds-raw
M:/data/boost/boost/tools/build/src/build\configure.jam:450: in
configure.find-builds
M:/data/boost/boost\boostcpp.jam:734: in boostcpp.deduce-address-model
M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in
modules.call-in
M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in indirect.call
M:/data/boost/boost/tools/build/src/build\property.jam:144: in
property.evaluate-conditionals-in-context
M:/data/boost/boost/tools/build/src/build\targets.jam:1087: in
evaluate-requirements
M:/data/boost/boost/tools/build/src/build\targets.jam:1121: in
common-properties2
M:/data/boost/boost/tools/build/src/build\targets.jam:1017: in
targets.common-properties
M:/data/boost/boost/tools/build/src/build\targets.jam:1313: in
[hidden email]
M:/data/boost/boost/tools/build/src/build\targets.jam:812: in
generate-really
M:/data/boost/boost/tools/build/src/build\targets.jam:784: in
[hidden email]
M:/data/boost/boost/tools/build/src\build-system.jam:797: in load
M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import
M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build
M:\data\boost\boost\boost-build.jam:17: in module scope

The unescaped character warnings are new to current develop Boost.Build,
and the rest is inscrutable to me, any ideas anyone?

Thanks, John.

PS, appveyor's CI is still on clang-5 currently.

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
AMDG

On 03/09/2018 11:42 AM, John Maddock via Boost wrote:

>
>
> On 09/03/2018 16:16, Egor Pugin via Boost wrote:
>> Hi,
>>
>> Based on recent news:
>> Clang 6.0.0 is out with very decent support of the latest MSVC STL
>> (15.6).
>> Chrome is built with clang on Windows.
>>
>> So, maybe it is good time to include clang+windows into list of
>> supported configs, setup a CI worker with clang (clang-cl) on Windows?
>> Currently many boost libs already work fine, but some of them require
>> small tweaks like explicit BOOST_USE_WINDOWS_H etc.
>
> A cursory check suggests the compiler is working OK and builds
> Boost.Config's tests, but I'm unable to get it working at all with
> Boost.Build, I'm trying:
>
> using clang-win : : "C:/Program Files/LLVM/bin/clang-cl.exe" :
> <compatibility>vc14.1 ;
>

  The clang-win toolset is known to be broken.  I don't
know if it ever worked.  I believe that clang-linux
(using regular clang, not clang-cl) works for most
platforms other than OSX.  (Yes, I know, cleaning up
this mess is on my todo list.)

> In my user-config.jam - note that the <compatibility> option appears to
> be required, and there is not default, likewise the semi-documented
> option <compatibility>native gets rejected as invalid.
>
> In any case this leads to:
>
>  $ ../../../b2 config_info clang-win
> C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in
> argument <cxxflags>-std:c++latest
> ..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in
> argument <define>$(flag)=1
> M:/data/boost/boost/tools/build/src/tools\msvc.jam:900: in
> set-setup-command
> *** argument error
> * rule virtual-target.from-file ( file : file-loc : project )
> * called with: (  : /M:/data/boost/boost/libs/config/test :
> object(project-target)@129 )
> * missing argument file
> <snip>
>
> The unescaped character warnings are new to current develop Boost.Build,

  They're harmless for now, but will break
at some unspecified time in the future, when
I switch to the new lexer.

> and the rest is inscrutable to me, any ideas anyone?
>

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list

>    The clang-win toolset is known to be broken.  I don't
> know if it ever worked.  I believe that clang-linux
> (using regular clang, not clang-cl) works for most
> platforms other than OSX.  (Yes, I know, cleaning up
> this mess is on my todo list.)

Using:

using clang : : "C:/Program Files/LLVM/bin/clang-cl.exe" :
<compatibility>vc14.1 ;

Results in:

$ ../../../b2 config_info clang
C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in
argument <cxxflags>-std:c++latest
..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in
argument <define>$(flag)=1
M:/data/boost/boost/tools/build/src/build\configure.jam:288: in
try-find-build
*** argument error
* rule log-check-result ( result )
* called with: (  )
* missing argument result
M:/data/boost/boost/tools/build/src/build\configure.jam:86:see
definition of rule 'log-check-result' being called
M:/data/boost/boost/tools/build/src/build\configure.jam:391: in
find-builds-raw
M:/data/boost/boost/tools/build/src/build\configure.jam:450: in
configure.find-builds
M:/data/boost/boost\boostcpp.jam:734: in boostcpp.deduce-address-model
M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in
modules.call-in
M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in indirect.call
M:/data/boost/boost/tools/build/src/build\property.jam:144: in
property.evaluate-conditionals-in-context
M:/data/boost/boost/tools/build/src/build\targets.jam:1087: in
evaluate-requirements
M:/data/boost/boost/tools/build/src/build\targets.jam:1121: in
common-properties2
M:/data/boost/boost/tools/build/src/build\targets.jam:1017: in
targets.common-properties
M:/data/boost/boost/tools/build/src/build\targets.jam:1313: in
[hidden email]
M:/data/boost/boost/tools/build/src/build\targets.jam:812: in
generate-really
M:/data/boost/boost/tools/build/src/build\targets.jam:784: in
[hidden email]
M:/data/boost/boost/tools/build/src\build-system.jam:797: in load
M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import
M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build
M:\data\boost\boost\boost-build.jam:17: in module scope

Using:

using clang : : "C:/Program Files/LLVM/bin/clang.exe" ;

Does indeed seem to work OK, and as far as I can tell it's clang on top
of msvc-14.1.

>    They're harmless for now, but will break
> at some unspecified time in the future, when
> I switch to the new lexer.

It would help a lot if the message said which characters were special
and need escaping.

Thanks, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
AMDG

On 03/09/2018 01:02 PM, John Maddock via Boost wrote:

>
>>    The clang-win toolset is known to be broken.  I don't
>> know if it ever worked.  I believe that clang-linux
>> (using regular clang, not clang-cl) works for most
>> platforms other than OSX.  (Yes, I know, cleaning up
>> this mess is on my todo list.)
>
> Using:
>
> using clang : : "C:/Program Files/LLVM/bin/clang-cl.exe" :
> <compatibility>vc14.1 ;
>
> Results in:
>
> $ ../../../b2 config_info clang
> C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in
> argument <cxxflags>-std:c++latest
> ..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in
> argument <define>$(flag)=1
> M:/data/boost/boost/tools/build/src/build\configure.jam:288: in
> try-find-build
> *** argument error
> * rule log-check-result ( result )
> * called with: (  )
> * missing argument result
> M:/data/boost/boost/tools/build/src/build\configure.jam:86:see
> definition of rule 'log-check-result' being called
> M:/data/boost/boost/tools/build/src/build\configure.jam:391: in
> find-builds-raw

  This is a bug in configure.jam.  I think I know
what's going on.  (It still won't work after I fix
this particular problem, but at least the error
won't be quite as inscrutable.)

> <snip>
>
> Using:
>
> using clang : : "C:/Program Files/LLVM/bin/clang.exe" ;
>
> Does indeed seem to work OK, and as far as I can tell it's clang on top
> of msvc-14.1.
>
>>    They're harmless for now, but will break
>> at some unspecified time in the future, when
>> I switch to the new lexer.
>
> It would help a lot if the message said which characters were special
> and need escaping.
>

  The full list is ":;{}=+?*()<>" (some of which
are context sensitive)  In general, the easiest
fix is to quote the whole token.  I'll see about
adjusting the message.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/9/2018 3:02 PM, John Maddock via Boost wrote:

>
>>    The clang-win toolset is known to be broken.  I don't
>> know if it ever worked.  I believe that clang-linux
>> (using regular clang, not clang-cl) works for most
>> platforms other than OSX.  (Yes, I know, cleaning up
>> this mess is on my todo list.)
>
> Using:
>
> using clang : : "C:/Program Files/LLVM/bin/clang-cl.exe" :
> <compatibility>vc14.1 ;

My use of clang-cl with clang-5.0 for x32 compilation looks like:

using clang : 5.0cl : C:/Utilities/LLVM/500/x32/bin/clang++
  :
  <cxxflags>-fmacro-backtrace-limit=0
  <cxxflags>-Wno-invalid-token-paste
  <compileflags>-fmsc-version=1900
  <compileflags>--target=i686-pc-windows-msvc
  <linkflags>--target=i686-pc-windows-msvc
  <linkflags>-fuse-ld=lld
  ;

It works for me pretty well when invoked as toolset=clang-5.0cl on the
b2 command line. Before invoking b2 I am also doing:

call "C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\vcvarsall.bat" x86

in order to setup vc++.

For x64 compilation it looks like:

using clang : 5.0x64cl : C:/Utilities/LLVM/500/x64/bin/clang++
  :
  <cxxflags>-fmacro-backtrace-limit=0
  <cxxflags>-Wno-invalid-token-paste
  <compileflags>-fmsc-version=1900
  <compileflags>--target=x86_64-pc-windows-msvc
  <linkflags>--target=x86_64-pc-windows-msvc
  <linkflags>-fuse-ld=lld
  ;

invoked on the b2 command line as toolset=clang-5.0x64cl. Before
invoking b2 I am also doing:

call "C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\vcvarsall.bat" amd64

in order to setup vc++.

Needless to say I have other using statements for clang with gcc for
various C++ standard levels in the same user-config.jam.

I am pretty sure to use the same type of setup with the recently
released 6.0 on Windows.

Maybe these will help you.

>
> Results in:
>
> $ ../../../b2 config_info clang
> C:\cygwin64\home\John\user-config.jam:47: Unescaped special character in
> argument <cxxflags>-std:c++latest
> ..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in
> argument <define>$(flag)=1
> M:/data/boost/boost/tools/build/src/build\configure.jam:288: in
> try-find-build
> *** argument error
> * rule log-check-result ( result )
> * called with: (  )
> * missing argument result
> M:/data/boost/boost/tools/build/src/build\configure.jam:86:see
> definition of rule 'log-check-result' being called
> M:/data/boost/boost/tools/build/src/build\configure.jam:391: in
> find-builds-raw
> M:/data/boost/boost/tools/build/src/build\configure.jam:450: in
> configure.find-builds
> M:/data/boost/boost\boostcpp.jam:734: in boostcpp.deduce-address-model
> M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in
> modules.call-in
> M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in indirect.call
> M:/data/boost/boost/tools/build/src/build\property.jam:144: in
> property.evaluate-conditionals-in-context
> M:/data/boost/boost/tools/build/src/build\targets.jam:1087: in
> evaluate-requirements
> M:/data/boost/boost/tools/build/src/build\targets.jam:1121: in
> common-properties2
> M:/data/boost/boost/tools/build/src/build\targets.jam:1017: in
> targets.common-properties
> M:/data/boost/boost/tools/build/src/build\targets.jam:1313: in
> [hidden email]
> M:/data/boost/boost/tools/build/src/build\targets.jam:812: in
> generate-really
> M:/data/boost/boost/tools/build/src/build\targets.jam:784: in
> [hidden email]
> M:/data/boost/boost/tools/build/src\build-system.jam:797: in load
> M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import
> M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in
> boost-build
> M:\data\boost\boost\boost-build.jam:17: in module scope
>
> Using:
>
> using clang : : "C:/Program Files/LLVM/bin/clang.exe" ;
>
> Does indeed seem to work OK, and as far as I can tell it's clang on top
> of msvc-14.1.
>
>>    They're harmless for now, but will break
>> at some unspecified time in the future, when
>> I switch to the new lexer.
>
> It would help a lot if the message said which characters were special
> and need escaping.
>
> Thanks, John.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list

> My use of clang-cl with clang-5.0 for x32 compilation looks like:
>
> using clang : 5.0cl : C:/Utilities/LLVM/500/x32/bin/clang++
>  :
>  <cxxflags>-fmacro-backtrace-limit=0
>  <cxxflags>-Wno-invalid-token-paste
>  <compileflags>-fmsc-version=1900
>  <compileflags>--target=i686-pc-windows-msvc
>  <linkflags>--target=i686-pc-windows-msvc
>  <linkflags>-fuse-ld=lld
>  ;
>
> It works for me pretty well when invoked as toolset=clang-5.0cl on the
> b2 command line. Before invoking b2 I am also doing:
>
> call "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\vcvarsall.bat" x86
>
> in order to setup vc++.
>
> For x64 compilation it looks like:
>
> using clang : 5.0x64cl : C:/Utilities/LLVM/500/x64/bin/clang++
>  :
>  <cxxflags>-fmacro-backtrace-limit=0
>  <cxxflags>-Wno-invalid-token-paste
>  <compileflags>-fmsc-version=1900
>  <compileflags>--target=x86_64-pc-windows-msvc
>  <linkflags>--target=x86_64-pc-windows-msvc
>  <linkflags>-fuse-ld=lld
>  ;
>

Thanks for that, I have things semi-working with:

using clang : 6.0 : "C:/Program Files/LLVM/bin/clang.exe" :
  <cxxflags>-fmacro-backtrace-limit=0
  <cxxstd>17
  <cxxflags>-Wno-invalid-token-paste
  <compileflags>-fmsc-version=1900
  <compileflags>--target=x86_64-pc-windows-msvc
  <linkflags>--target=x86_64-pc-windows-msvc
  <linkflags>-lmsvcrt
  <linkflags>-lkernel32
  <linkflags>-luser32
    ;

But:

* I can't build dll's, so I need link=static on the command line.
* The cxxstd invocation in user-config.jam doesn't work - and clang.jam
appends -std=c++11 to the clang command line which breaks several MS
headers.  Adding cxxstd=17 to the b2 command line fixes that, but it's a
pain.
* I'm still getting linker errors I haven't been able to resolve for
system calls even with the references to Kernal32 and User32 as above.

I really think we should be using clang-cl, as I suspect it would solve
most of this stuff...

Best, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Plus I still see:


In file included from C:\Program
Files\LLVM\lib\clang\6.0.0\include\vadefs.h:32:
M:\Compilers\VC2017\VC\Tools\MSVC\14.13.26128\include\vadefs.h:112:10:
error: expected unqualified-id
     void __cdecl __va_start(va_list* , ...);

vadefs.h gets pulled in by limits.h BTW so this is hardly obscure stuff....


John.


On 09/03/2018 21:13, Edward Diener via Boost wrote:

> On 3/9/2018 3:02 PM, John Maddock via Boost wrote:
>>
>>>    The clang-win toolset is known to be broken.  I don't
>>> know if it ever worked.  I believe that clang-linux
>>> (using regular clang, not clang-cl) works for most
>>> platforms other than OSX.  (Yes, I know, cleaning up
>>> this mess is on my todo list.)
>>
>> Using:
>>
>> using clang : : "C:/Program Files/LLVM/bin/clang-cl.exe" :
>> <compatibility>vc14.1 ;
>
> My use of clang-cl with clang-5.0 for x32 compilation looks like:
>
> using clang : 5.0cl : C:/Utilities/LLVM/500/x32/bin/clang++
>  :
>  <cxxflags>-fmacro-backtrace-limit=0
>  <cxxflags>-Wno-invalid-token-paste
>  <compileflags>-fmsc-version=1900
>  <compileflags>--target=i686-pc-windows-msvc
>  <linkflags>--target=i686-pc-windows-msvc
>  <linkflags>-fuse-ld=lld
>  ;
>
> It works for me pretty well when invoked as toolset=clang-5.0cl on the
> b2 command line. Before invoking b2 I am also doing:
>
> call "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\vcvarsall.bat" x86
>
> in order to setup vc++.
>
> For x64 compilation it looks like:
>
> using clang : 5.0x64cl : C:/Utilities/LLVM/500/x64/bin/clang++
>  :
>  <cxxflags>-fmacro-backtrace-limit=0
>  <cxxflags>-Wno-invalid-token-paste
>  <compileflags>-fmsc-version=1900
>  <compileflags>--target=x86_64-pc-windows-msvc
>  <linkflags>--target=x86_64-pc-windows-msvc
>  <linkflags>-fuse-ld=lld
>  ;
>
> invoked on the b2 command line as toolset=clang-5.0x64cl. Before
> invoking b2 I am also doing:
>
> call "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\vcvarsall.bat" amd64
>
> in order to setup vc++.
>
> Needless to say I have other using statements for clang with gcc for
> various C++ standard levels in the same user-config.jam.
>
> I am pretty sure to use the same type of setup with the recently
> released 6.0 on Windows.
>
> Maybe these will help you.
>
>>
>> Results in:
>>
>> $ ../../../b2 config_info clang
>> C:\cygwin64\home\John\user-config.jam:47: Unescaped special character
>> in argument <cxxflags>-std:c++latest
>> ..\..\..\libs\log\build\Jamfile.v2:45: Unescaped special character in
>> argument <define>$(flag)=1
>> M:/data/boost/boost/tools/build/src/build\configure.jam:288: in
>> try-find-build
>> *** argument error
>> * rule log-check-result ( result )
>> * called with: (  )
>> * missing argument result
>> M:/data/boost/boost/tools/build/src/build\configure.jam:86:see
>> definition of rule 'log-check-result' being called
>> M:/data/boost/boost/tools/build/src/build\configure.jam:391: in
>> find-builds-raw
>> M:/data/boost/boost/tools/build/src/build\configure.jam:450: in
>> configure.find-builds
>> M:/data/boost/boost\boostcpp.jam:734: in boostcpp.deduce-address-model
>> M:/data/boost/boost/tools/build/src/kernel\modules.jam:107: in
>> modules.call-in
>> M:/data/boost/boost/tools/build/src/util\indirect.jam:105: in
>> indirect.call
>> M:/data/boost/boost/tools/build/src/build\property.jam:144: in
>> property.evaluate-conditionals-in-context
>> M:/data/boost/boost/tools/build/src/build\targets.jam:1087: in
>> evaluate-requirements
>> M:/data/boost/boost/tools/build/src/build\targets.jam:1121: in
>> common-properties2
>> M:/data/boost/boost/tools/build/src/build\targets.jam:1017: in
>> targets.common-properties
>> M:/data/boost/boost/tools/build/src/build\targets.jam:1313: in
>> [hidden email]
>> M:/data/boost/boost/tools/build/src/build\targets.jam:812: in
>> generate-really
>> M:/data/boost/boost/tools/build/src/build\targets.jam:784: in
>> [hidden email]
>> M:/data/boost/boost/tools/build/src\build-system.jam:797: in load
>> M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import
>> M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in
>> boost-build
>> M:\data\boost\boost\boost-build.jam:17: in module scope
>>
>> Using:
>>
>> using clang : : "C:/Program Files/LLVM/bin/clang.exe" ;
>>
>> Does indeed seem to work OK, and as far as I can tell it's clang on
>> top of msvc-14.1.
>>
>>>    They're harmless for now, but will break
>>> at some unspecified time in the future, when
>>> I switch to the new lexer.
>>
>> It would help a lot if the message said which characters were special
>> and need escaping.
>>
>> Thanks, John.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list


On 10/03/2018 08:40, John Maddock wrote:

> Plus I still see:
>
>
> In file included from C:\Program
> Files\LLVM\lib\clang\6.0.0\include\vadefs.h:32:
> M:\Compilers\VC2017\VC\Tools\MSVC\14.13.26128\include\vadefs.h:112:10:
> error: expected unqualified-id
>     void __cdecl __va_start(va_list* , ...);
>
> vadefs.h gets pulled in by limits.h BTW so this is hardly obscure
> stuff....

All this seems to be fixed by using clang-cl rather than clang....

John.



---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
Some time ago, got things working quite well with the following project
file:


import option ;

using clang : 6.0 :
  "C:/Program Files/LLVM/bin/clang++.exe" :
  <compileflags>-fmsc-version=1911

  <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe"
  <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe"
  <rc>"C:/Program Files (x86)/Windows Kits/10/bin/10.0.16299.0/x64/rc.exe"

  <linkflags>-fuse-ld=lld
  <linkflags>-flto=thin

  <cxxflags>-Wno-gnu-string-literal-operator-template
  <cxxflags>-Xclang <cxxflags>-flto-visibility-public-std

  <cxxflags>-fno-ms-compatibility
  <cxxflags>-fno-delayed-template-parsing
  <cxxflags>-Wno-dynamic-exception-spec # TODO: file bug to MS
  <cxxflags>-Wno-c++11-narrowing # TODO: wut
  <cxxflags>-D_WINSOCK_DEPRECATED_NO_WARNINGS # TODO: wut

  <cxxflags>-std=c++17
  <cxxflags>-Wunused-command-line-argument

  <cxxflags>-DBOOST_USE_WINDOWS_H
  <cxxflags>-DBOOST_NO_ANSI_APIS

  <cxxflags>-DBOOST_USE_WINAPI_VERSION=0x1000
  <cxxflags>-DBOOST_USE_WINDOWS_H=1
  <cxxflags>-D_WIN32_WINNT=0x1000

  <cxxflags>-D_MT
  <cxxflags>-D_WIN32
  <cxxflags>-D_WIN64
  <cxxflags>-DNOMINMAX
  <cxxflags>-DWIN32_LEAN_AND_MEAN
  <cxxflags>-D_HAS_AUTO_PTR_ETC=1
  <cxxflags>-D_ITERATOR_DEBUG_LEVEL=0
  <cxxflags>-D_CRT_DECLARE_NONSTDC_NAMES=1 # clang defines __STDC__, cl
does not (see definition of _CRT_INTERNAL_NONSTDC_NAMES)

  #
<cxxflags>-IC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/include
  #
<linkflags>-LC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/lib/x64
  ;

option.set keep-going : false ;

degski

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/10/2018 3:38 AM, John Maddock via Boost wrote:

>
>> My use of clang-cl with clang-5.0 for x32 compilation looks like:
>>
>> using clang : 5.0cl : C:/Utilities/LLVM/500/x32/bin/clang++
>>  :
>>  <cxxflags>-fmacro-backtrace-limit=0
>>  <cxxflags>-Wno-invalid-token-paste
>>  <compileflags>-fmsc-version=1900
>>  <compileflags>--target=i686-pc-windows-msvc
>>  <linkflags>--target=i686-pc-windows-msvc
>>  <linkflags>-fuse-ld=lld
>>  ;
>>
>> It works for me pretty well when invoked as toolset=clang-5.0cl on the
>> b2 command line. Before invoking b2 I am also doing:
>>
>> call "C:\Program Files (x86)\Microsoft Visual Studio
>> 14.0\VC\vcvarsall.bat" x86
>>
>> in order to setup vc++.
>>
>> For x64 compilation it looks like:
>>
>> using clang : 5.0x64cl : C:/Utilities/LLVM/500/x64/bin/clang++
>>  :
>>  <cxxflags>-fmacro-backtrace-limit=0
>>  <cxxflags>-Wno-invalid-token-paste
>>  <compileflags>-fmsc-version=1900
>>  <compileflags>--target=x86_64-pc-windows-msvc
>>  <linkflags>--target=x86_64-pc-windows-msvc
>>  <linkflags>-fuse-ld=lld
>>  ;
>>
>
> Thanks for that, I have things semi-working with:
>
> using clang : 6.0 : "C:/Program Files/LLVM/bin/clang.exe" :
>   <cxxflags>-fmacro-backtrace-limit=0
>   <cxxstd>17
>   <cxxflags>-Wno-invalid-token-paste
>   <compileflags>-fmsc-version=1900
>   <compileflags>--target=x86_64-pc-windows-msvc
>   <linkflags>--target=x86_64-pc-windows-msvc
>   <linkflags>-lmsvcrt
>   <linkflags>-lkernel32
>   <linkflags>-luser32
>     ;
>
> But:
>
> * I can't build dll's, so I need link=static on the command line.
> * The cxxstd invocation in user-config.jam doesn't work - and clang.jam
> appends -std=c++11 to the clang command line which breaks several MS
> headers.  Adding cxxstd=17 to the b2 command line fixes that, but it's a
> pain.
> * I'm still getting linker errors I haven't been able to resolve for
> system calls even with the references to Kernal32 and User32 as above.
>
> I really think we should be using clang-cl, as I suspect it would solve
> most of this stuff...

clang targeting msvc is the same thing as clang-cl AFAIK. I have never
used 'cxxstd' with clang, although when targeting gcc using, for
example, '<cxxflags>-std=c++11', works fine for me. For what libraries
are you failing to build DLLs ? For what libraries are tou getting
linker errors involving kernel32 and user32 ?

>
> Best, John.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/10/2018 3:38 AM, John Maddock via Boost wrote:

>
>> My use of clang-cl with clang-5.0 for x32 compilation looks like:
>>
>> using clang : 5.0cl : C:/Utilities/LLVM/500/x32/bin/clang++
>>  :
>>  <cxxflags>-fmacro-backtrace-limit=0
>>  <cxxflags>-Wno-invalid-token-paste
>>  <compileflags>-fmsc-version=1900
>>  <compileflags>--target=i686-pc-windows-msvc
>>  <linkflags>--target=i686-pc-windows-msvc
>>  <linkflags>-fuse-ld=lld
>>  ;
>>
>> It works for me pretty well when invoked as toolset=clang-5.0cl on the
>> b2 command line. Before invoking b2 I am also doing:
>>
>> call "C:\Program Files (x86)\Microsoft Visual Studio
>> 14.0\VC\vcvarsall.bat" x86
>>
>> in order to setup vc++.
>>
>> For x64 compilation it looks like:
>>
>> using clang : 5.0x64cl : C:/Utilities/LLVM/500/x64/bin/clang++
>>  :
>>  <cxxflags>-fmacro-backtrace-limit=0
>>  <cxxflags>-Wno-invalid-token-paste
>>  <compileflags>-fmsc-version=1900
>>  <compileflags>--target=x86_64-pc-windows-msvc
>>  <linkflags>--target=x86_64-pc-windows-msvc
>>  <linkflags>-fuse-ld=lld
>>  ;
>>
>
> Thanks for that, I have things semi-working with:
>
> using clang : 6.0 : "C:/Program Files/LLVM/bin/clang.exe" :
>   <cxxflags>-fmacro-backtrace-limit=0
>   <cxxstd>17
>   <cxxflags>-Wno-invalid-token-paste
>   <compileflags>-fmsc-version=1900
>   <compileflags>--target=x86_64-pc-windows-msvc
>   <linkflags>--target=x86_64-pc-windows-msvc
>   <linkflags>-lmsvcrt
>   <linkflags>-lkernel32
>   <linkflags>-luser32
>     ;
>
> But:
>
> * I can't build dll's, so I need link=static on the command line.
> * The cxxstd invocation in user-config.jam doesn't work - and clang.jam
> appends -std=c++11 to the clang command line which breaks several MS
> headers.  Adding cxxstd=17 to the b2 command line fixes that, but it's a
> pain.
> * I'm still getting linker errors I haven't been able to resolve for
> system calls even with the references to Kernal32 and User32 as above.
>
> I really think we should be using clang-cl, as I suspect it would solve
> most of this stuff...

I agree with you. My clang setup targeting msvc can not build dlls either.

>
> Best, John.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/10/2018 6:06 AM, degski via Boost wrote:

> Some time ago, got things working quite well with the following project
> file:
>
>
> import option ;
>
> using clang : 6.0 :
>    "C:/Program Files/LLVM/bin/clang++.exe" :
>    <compileflags>-fmsc-version=1911
>
>    <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe"
>    <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe"
>    <rc>"C:/Program Files (x86)/Windows Kits/10/bin/10.0.16299.0/x64/rc.exe"
>
>    <linkflags>-fuse-ld=lld
>    <linkflags>-flto=thin
>
>    <cxxflags>-Wno-gnu-string-literal-operator-template
>    <cxxflags>-Xclang <cxxflags>-flto-visibility-public-std
>
>    <cxxflags>-fno-ms-compatibility
>    <cxxflags>-fno-delayed-template-parsing
>    <cxxflags>-Wno-dynamic-exception-spec # TODO: file bug to MS
>    <cxxflags>-Wno-c++11-narrowing # TODO: wut
>    <cxxflags>-D_WINSOCK_DEPRECATED_NO_WARNINGS # TODO: wut
>
>    <cxxflags>-std=c++17
>    <cxxflags>-Wunused-command-line-argument
>
>    <cxxflags>-DBOOST_USE_WINDOWS_H
>    <cxxflags>-DBOOST_NO_ANSI_APIS
>
>    <cxxflags>-DBOOST_USE_WINAPI_VERSION=0x1000
>    <cxxflags>-DBOOST_USE_WINDOWS_H=1
>    <cxxflags>-D_WIN32_WINNT=0x1000
>
>    <cxxflags>-D_MT
>    <cxxflags>-D_WIN32
>    <cxxflags>-D_WIN64
>    <cxxflags>-DNOMINMAX
>    <cxxflags>-DWIN32_LEAN_AND_MEAN
>    <cxxflags>-D_HAS_AUTO_PTR_ETC=1
>    <cxxflags>-D_ITERATOR_DEBUG_LEVEL=0
>    <cxxflags>-D_CRT_DECLARE_NONSTDC_NAMES=1 # clang defines __STDC__, cl
> does not (see definition of _CRT_INTERNAL_NONSTDC_NAMES)
>
>    #
> <cxxflags>-IC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/include
>    #
> <linkflags>-LC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/lib/x64
>    ;
>
> option.set keep-going : false ;
>

With all of the configuration items, does Clang successfully build C++
MFC Windows Forms and/or DLL projects?

--Robert

> degski
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Edward Diener via Boost
> Sent: 10 March 2018 13:39
> To: [hidden email]
> Cc: Edward Diener
> Subject: Re: [boost] Clang on Windows
>
> On 3/10/2018 3:38 AM, John Maddock via Boost wrote:
> >
> >> My use of clang-cl with clang-5.0 for x32 compilation looks like:
> >>
> >> using clang : 5.0cl : C:/Utilities/LLVM/500/x32/bin/clang++
> >>  :
> >>  <cxxflags>-fmacro-backtrace-limit=0
> >>  <cxxflags>-Wno-invalid-token-paste
> >>  <compileflags>-fmsc-version=1900
> >>  <compileflags>--target=i686-pc-windows-msvc
> >>  <linkflags>--target=i686-pc-windows-msvc
> >>  <linkflags>-fuse-ld=lld
> >>  ;
> >>
> >> It works for me pretty well when invoked as toolset=clang-5.0cl on the
> >> b2 command line. Before invoking b2 I am also doing:
> >>
> >> call "C:\Program Files (x86)\Microsoft Visual Studio
> >> 14.0\VC\vcvarsall.bat" x86
> >>
> >> in order to setup vc++.
> >>
> >> For x64 compilation it looks like:
> >>
> >> using clang : 5.0x64cl : C:/Utilities/LLVM/500/x64/bin/clang++
> >>  :
> >>  <cxxflags>-fmacro-backtrace-limit=0
> >>  <cxxflags>-Wno-invalid-token-paste
> >>  <compileflags>-fmsc-version=1900
> >>  <compileflags>--target=x86_64-pc-windows-msvc
> >>  <linkflags>--target=x86_64-pc-windows-msvc
> >>  <linkflags>-fuse-ld=lld
> >>  ;
> >>
> >
> > Thanks for that, I have things semi-working with:
> >
> > using clang : 6.0 : "C:/Program Files/LLVM/bin/clang.exe" :
> >   <cxxflags>-fmacro-backtrace-limit=0
> >   <cxxstd>17
> >   <cxxflags>-Wno-invalid-token-paste
> >   <compileflags>-fmsc-version=1900
> >   <compileflags>--target=x86_64-pc-windows-msvc
> >   <linkflags>--target=x86_64-pc-windows-msvc
> >   <linkflags>-lmsvcrt
> >   <linkflags>-lkernel32
> >   <linkflags>-luser32
> >     ;
> >
> > But:
> >
> > * I can't build dll's, so I need link=static on the command line.
> > * The cxxstd invocation in user-config.jam doesn't work - and clang.jam
> > appends -std=c++11 to the clang command line which breaks several MS
> > headers.  Adding cxxstd=17 to the b2 command line fixes that, but it's a
> > pain.
> > * I'm still getting linker errors I haven't been able to resolve for
> > system calls even with the references to Kernal32 and User32 as above.
> >
> > I really think we should be using clang-cl, as I suspect it would solve
> > most of this stuff...
I have also been investigating (fumbling with) this can of worms.  (Lots of details attached)

I have got some things to work, but linking libraries produces an inexplicable (to me) link failure when trying to use Boost.Test and Clang.

I have tried this on Codeblocks when I can link to Chrono library OK, but when I try to use Boost.Test using the same test.cpp that passes using GCC7.1.0, I get a final failure

LINK : fatal error LNK1561: entry point must be defined

There is not a int main() but Boost.Test's own entry function

int unit_test_main( init_unit_test_func init_func, int argc, char* argv[] );

that I presume should be fed in place of int main()

Is this a Boost.Test config problem that makes Clang and GCC different , or am I doing something silly.

Suggestions welcome.

Paul









msvcrt.lib








_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

clang problems.txt (100K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Paul A. Bristow
> via Boost
> Sent: Donnerstag, 15. März 2018 19:05
> To: [hidden email]
> Cc: Paul A. Bristow <[hidden email]>
> Subject: Re: [boost] Clang on Windows
>
> I have got some things to work, but linking libraries produces an inexplicable
> (to me) link failure when trying to use Boost.Test and Clang.
>
> I have tried this on Codeblocks when I can link to Chrono library OK, but
> when I try to use Boost.Test using the same test.cpp that passes using
> GCC7.1.0, I get a final failure
>
> LINK : fatal error LNK1561: entry point must be defined
>
> There is not a int main() but Boost.Test's own entry function
>
> int unit_test_main( init_unit_test_func init_func, int argc, char* argv[] );
>
> that I presume should be fed in place of int main()
>
> Is this a Boost.Test config problem that makes Clang and GCC different , or
> am I doing something silly.

I've seen this error when /SUBSYSTEM:CONSOLE wasn't passed to the MSVC linker.

Marcel


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
On 15 March 2018 at 13:30, Marcel Raad via Boost <[hidden email]>
wrote:

> > -----Original Message-----
> > From: Boost <[hidden email]> On Behalf Of Paul A. Bristow
> > via Boost
> > Sent: Donnerstag, 15. März 2018 19:05
> > To: [hidden email]
> > Cc: Paul A. Bristow <[hidden email]>
> > Subject: Re: [boost] Clang on Windows
> >
> > I have got some things to work, but linking libraries produces an
> inexplicable
> > (to me) link failure when trying to use Boost.Test and Clang.
> >
> > I have tried this on Codeblocks when I can link to Chrono library OK, but
> > when I try to use Boost.Test using the same test.cpp that passes using
> > GCC7.1.0, I get a final failure
> >
> > LINK : fatal error LNK1561: entry point must be defined
> >
> > There is not a int main() but Boost.Test's own entry function
> >
> > int unit_test_main( init_unit_test_func init_func, int argc, char*
> argv[] );
> >
> > that I presume should be fed in place of int main()
> >
> > Is this a Boost.Test config problem that makes Clang and GCC different ,
> or
> > am I doing something silly.
>
> I've seen this error when /SUBSYSTEM:CONSOLE wasn't passed to the MSVC
> linker.
>

If you'd do that, you'll have an issue, but... I've just tested building an
app not passing /SUBSYSTEM:CONSOLE. It builds and runs, but of course
there's no console window (something flashes up, no error or problem).

I think the -flto=thin flag is possibly not properly passed around, or the
vc linker (link.exe) is invoked instead of lld.exe. As OP's libs are lto
instrumented, they can only be linked with lld and the flag -flto=thin.

degski

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of degski via Boost
> Sent: Freitag, 16. März 2018 12:20
> To: boost <[hidden email]>
> Cc: degski <[hidden email]>
> Subject: Re: [boost] Clang on Windows
>
> On 15 March 2018 at 13:30, Marcel Raad via Boost <[hidden email]>
> wrote:
>
> > I've seen this error when /SUBSYSTEM:CONSOLE wasn't passed to the
> > MSVC linker.
>
> If you'd do that, you'll have an issue, but... I've just tested building an
> app not passing /SUBSYSTEM:CONSOLE. It builds and runs, but of course
> there's no console window (something flashes up, no error or problem).

Ah, I don't know what happens if invoked directly. What I meant is, if you
create a new empty project from within Visual Studio and include unit_test.hpp,
you get that error unless you set Linker->System->SubSystem to
"Console (/SUBSYSTEM:CONSOLE)" in the project options.

> I think the -flto=thin flag is possibly not properly passed around, or the
> vc linker (link.exe) is invoked instead of lld.exe. As OP's libs are lto
> instrumented, they can only be linked with lld and the flag -flto=thin.

Yes, the error message is from the MSVC linker.

Marcel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Clang on Windows

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of degski via Boost
> Sent: 16 March 2018 11:20
> To: boost
> Cc: degski
> Subject: Re: [boost] Clang on Windows
>
> On 15 March 2018 at 13:30, Marcel Raad via Boost <[hidden email]>
> wrote:
>
> > > -----Original Message-----
> > > From: Boost <[hidden email]> On Behalf Of Paul A. Bristow
> > > via Boost
> > > Sent: Donnerstag, 15. März 2018 19:05
> > > To: [hidden email]
> > > Cc: Paul A. Bristow <[hidden email]>
> > > Subject: Re: [boost] Clang on Windows
> > >
> > > I have got some things to work, but linking libraries produces an
> > inexplicable
> > > (to me) link failure when trying to use Boost.Test and Clang.
> > >
> > > I have tried this on Codeblocks when I can link to Chrono library OK, but
> > > when I try to use Boost.Test using the same test.cpp that passes using
> > > GCC7.1.0, I get a final failure
> > >
> > > LINK : fatal error LNK1561: entry point must be defined
> > >
> > > There is not a int main() but Boost.Test's own entry function
> > >
> > > int unit_test_main( init_unit_test_func init_func, int argc, char*
> > argv[] );
> > >
> > > that I presume should be fed in place of int main()
> > >
> > > Is this a Boost.Test config problem that makes Clang and GCC different ,
> > or
> > > am I doing something silly.
> >
> > I've seen this error when /SUBSYSTEM:CONSOLE wasn't passed to the MSVC
> > linker.
> >
>
> If you'd do that, you'll have an issue, but... I've just tested building an
> app not passing /SUBSYSTEM:CONSOLE. It builds and runs, but of course
> there's no console window (something flashes up, no error or problem).

I see this error on Codeblocks IDE which runs the .exe via a console,
but also when built using bjam/b2.  So I'm not sure if this is relevant?
 
> I think the -flto=thin flag is possibly not properly passed around, or the
> vc linker (link.exe) is invoked instead of lld.exe.

I'll look into this. I note that John Maddock has   <linkflags>-lmsvcrt

Should I have x86_64-pc-windows-mgwin rather than x86_64-pc-windows-msvc?

> As OP's libs are lto instrumented, they can only be linked with lld and the flag -flto=thin.

This is a useful info.  I was unclear if/which linker should be used.
(I hoped that either were useable - always the optimist!)

Thanks

Paul
 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost