breaking change with rsp file when migrating from boost 1.78 to boost 1.83 under windows/mingw64

[rlepere]

Hello,

I am migrating my application from boost-1.78 (b2 4.7-git) to boost-1.83 (b2 4.10-git). I am using boost build and bjam as a build tool for my application.

I am using g++ compiler (11.3) under windows environment, everything was working correctly under the old version of boost-build but I am having a problem with the new one.

It is related to the linker pass where a response file .rsp file is used because the line can be very long.

In previous version, the linker line generated was something like :
g++ -L"c:\external\boost_1_78_0" @toto.rsp

now the line is
g++ @toto.rsp

and the first line of the response file is -L"c:\external\boost_1_78_0"
This leads to problems because g++ does not find libs correctly. The first line of the response file should be either
-L"c:\external\boost_1_78_0"
or
-L"c:/external/boost_1_78_0"
so that g++ can find correctly the libs.

What could I do to fix the problem ? Is this a bug ?

Best regards,

Renaud Lepère

[grafikrobot]

Can you give me more details on the environment? How are you building? I.e. is it mingw64, cygwin, WSL, something else? Do you have a small repro project and command you invoke?

Also.. for this:

and the first line of the response file is -L"c:\external\boost_1_78_0"

That, looks the same as..

This leads to problems because g++ does not find libs correctly. The first line of the response file should be either
-L"c:\external\boost_1_78_0"

..this to me.

or
-L"c:/external/boost_1_78_0"
so that g++ can find correctly the libs.

[rlepere]

Can you give me more details on the environment? How are you building? I.e. is it mingw64, cygwin, WSL, something else? Do you have a small repro project and command you invoke?
My g++ is mingw64

c:\Compilers\mingw64-113\bin>g++ --version
g++ (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 11.3.0

I will try to make a small project to show you the problem tomorrow.

Also.. for this:

and the first line of the response file is -L"c:\external\boost_1_78_0"

That, looks the same as..

Oups I made a mistake the first line of the response file should be:
-L"c:\external\boost_1_78_0"
or
-L"c:/external/boost_1_78_0"

But if it is:
-L"c:\external\boost_1_78_0"

then g++ does not find the libs.

[rlepere]

There is a problem with the "\\" due to escaping the first line should contain "\\" instead of single "\"

[rlepere]

I have done a small test case:
jamroot file contents

lib mylib
:
: mylib
;

exe a : a.cpp .//mylib
: lib/lib
file
;

bjam.bat file contents

@SETLOCAL
@set MINGW64=c:\compilers\mingw64-113\bin
@set BOOST_LOCATION=%USERPROFILE%\nest\external\boost_1_83_0
@set PATH=%MINGW64%;%BOOST_LOCATION%;%PATH%
@set BOOST_BUILD_PATH=%BOOST_LOCATION%
b2.exe --toolset=gcc address-model=64 %*
@endlocal

output of bjam.bat -d2
c:\Users\renaud\nest\default\bug_b2>b2.exe --toolset=gcc address-model=64 -d+2

file bin/gcc-11/debug/address-model-64/threadapi-win32/a.exe.rsp
-L"lib\lib" -o "bin\gcc-11\debug\address-model-64\threadapi-win32\a.exe" -Wl,--start-group "bin/gcc-11/debug/address-model-64/threadapi-win32/a.o" -Wl,-Bstatic -Wl,-Bdynamic -lmylib -Wl,--end-group -g
gcc.link bin\gcc-11\debug\address-model-64\threadapi-win32\a.exe

"g++" @"bin/gcc-11/debug/address-model-64/threadapi-win32/a.exe.rsp"

c:/compilers/mingw64-113/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmylib: No such file or directory
collect2.exe: error: ld returned 1 exit status

It works if I use bbv2 included in boost_1_78_0. I hope it will help to solve the issue.

[rlepere]

sorry again jamroot file contents is

`lib mylib
:
: mylib
;

exe a : a.cpp .//mylib
: lib/lib
file
; `

[rlepere]

bug_b2.zip

A simple test case with all the files.

[rlepere]

The regression is between boost 1.83 and boost 1.82.

With boost 1.82, the linker line is the following one (the -L flag is not in the response .rsp file)
"g++" -L"lib\lib" -o "bin\gcc-11\debug\address-model-64\a.exe" @"bin/gcc-11/debug/address-model-64/a.exe.rsp" -g

[grafikrobot]

Fixed with 2474be5