Subject: Re: [Boost-build] An option to prepend paths to %PATH% before executing a test built with a toolset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-10-20 12:39:44
On 10/20/2015 3:03 AM, Ion Gaztañaga wrote:
> On 20/10/2015 3:36, Edward Diener wrote:
>> My experience with mingw(-64) is that you will not be able to
>> compile/link without the 'bin' directory of the mingw(-64) installation
>> being in your PATH. Since different mingw(-64) releases have different
>> paths it appears impossible to me that you can run more than one
>> mingw(-64) regression test at a time.
>
> With mingw-64 I have no problems when compiling-linking because I've put
> a .bat file that updates PATH and passes arguments to g++:
>
> using gcc : 4.7c++03 : c:/.../_mingw-scripts/gcc-4.7.bat :
> <cxxflags>-std=c++03 ;
>
> where gcc-4.7.bat is:
>
> @echo off
> set PATH=C:\Program Files
> (x86)\mingw-builds\x32-4.7.3-posix-dwarf-rev1\mingw32\bin;%PATH%
> g++ %*
>
> This works with older mingw-builds and newer mingw-w64 builds, at least
> in several compilers (I have gcc-4.6,4.7,4.8,4.9, and 5.1). I use
> link=static to run tests, I don't know if this helps a bit.
I tried what you are doing above ( with batch files ) previously but ran
into problems which I could never figure out regarding missing DLLs. If
'link-static' overrides whatever linking is normally done for a
library's tests and also guarantees that all DLLs including the
run-time-library are statically linked then your final executable, being
standalone, should work without any of mingw(-64)/gcc's DLLs.
>
> I have no execution errors, even if PATH is not updated when executing
> (maybe those different runtimes in each compiler are compatible or they
> just embed some DLL lookup path in the binary, I don't know).
If your 'link-static' means that there are no DLLs of any kind then you
don't need the PATH set in any way at run-time, since you have a
standalone executable. But I don't know if 'link-static' actually works
this way given the different needs of all Boost libraries and the
vagaries of different mingw(-64)/gcc implementations.
>
> The main problem is with the old mingw (I'm trying to test gcc-3.4 and
> gcc-4.2) which complains about mingwm10.dll.
I think you are trying to hard to regression test versions of compilers
which nobody seriously uses anymore. OTOH if you are only testing your
own libraries with these ancient compilers it is understandable if you
are still willing to support those compilers.
As a solution to your problem try putting ( or making a symbolic link )
of each of your batch files in the appropriate 'bin' directory of the
mingw(-64)/gcc implementation. So your path to the batch file is the
same as the path to the g++ executable. I believe that for gcc Boost
Build automatically adds that directory to the front of the PATH when
running tests.
> I could just try to put a
> copy of this DLL in %WINDOWS% directory, but if that DLL has no ABI
> compatibility, then each compiler will need a different path. Even with
> ABI compatibility, I would need to guess which is the most recent
> version and deal with additional dependencies.
>
> I don't know much about how Build works, but I see several properties
> are passed to the "run-path-setup", I just don't know if those could
> come from user-config.jam.