[SERVER-23208] Results of TryLinks with cached scons configs can be erroneous if command line options change the order of config tests Created: 17/Mar/16 Updated: 21/Aug/20 Resolved: 05/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Eric Milkie | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
|||||||
| Backwards Compatibility: | Fully Compatible | |||||||
| Operating System: | ALL | |||||||
| Steps To Reproduce: | In a directory set up with the Enterprise module, type:
Eventually you get:
Then type:
You get, eventually:
Looking in config.log, this is apparently because the linker cannot find the "main" method in the conftest file that is linked. To fix the problem, you can do this:
|
|||||||
| Sprint: | Dev Platform 2020-01-27, Dev Platform 2020-02-10 | |||||||
| Participants: |
| Description |
|
If I mistakenly run "scons" to build with the Enterprise module and forget --ssl, I end up breaking my cached config such that I need to use "--config=force". I'm not sure if there is a bug in scons TryLink, or in the way we're melding things from the Enterprise module into the configuration stage. |
| Comments |
| Comment by Githook User [ 21/Aug/20 ] | |||||||||||||||||||||||||||||
|
Author: {'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'}Message: https://github.com/SCons/scons/commit/7c32091fccad5e70755dc46174fe516fff4549c3 | |||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 05/Feb/20 ] | |||||||||||||||||||||||||||||
|
Let the celebrations (and backports requests) begin! | |||||||||||||||||||||||||||||
| Comment by Githook User [ 05/Feb/20 ] | |||||||||||||||||||||||||||||
|
Author: {'name': 'Andrew Morrow', 'username': 'acmorrow', 'email': 'acm@mongodb.com'}Message: https://github.com/SCons/scons/commit/7c32091fccad5e70755dc46174fe516fff4549c3 | |||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 05/Feb/20 ] | |||||||||||||||||||||||||||||
|
This has been merged upstream in https://github.com/SCons/scons/commit/7c32091fccad5e70755dc46174fe516fff4549c3 I will work to get it cherry-picked into our vendored SCons ASAP. | |||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 16/Jan/20 ] | |||||||||||||||||||||||||||||
|
bdbaddog - OK, I've attached three config.log files here. The first one, config.log.1 matches up to the first --ssl=on build, and then config.log.2 matches up to the --ssl=off build, and then the last one, config.log.3, is from the failing third run where we switched back to --ssl=on again. Note that I added VERBOSE=1 to all of the command lines to generate these, as they are more complete when verbose mode is on. | |||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 15/Jan/20 ] | |||||||||||||||||||||||||||||
|
The above repro was on community 4119889d9cf5d3e1b9e23ecd112c7d4bf9773390 and enterprise 914271f2efcc444af84d737a1120ecac74b00dfb. | |||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 15/Jan/20 ] | |||||||||||||||||||||||||||||
|
bdbaddog - Here are updated reproduction instructions on master.
Looking at the build/scons/config.log we see this:
This suggests that the numbering has gotten confused and we have tried to link an object file that didn't define main as the last step of this TryLink. | |||||||||||||||||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 30/Aug/19 ] | |||||||||||||||||||||||||||||
|
I ran into this today with our buildscript/scons.py on the 4.0 branch (logs attached). The --config=force workaround continues to fix the issue. | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 04/Apr/16 ] | |||||||||||||||||||||||||||||
|
Also I think the problem is restricted to configure checks that have multiple output items (that can be cached). TryLink outputs both an object file and an executable, so scons can get confused if the object file is already seemingly up-to-date but the executable binary is not. | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 17/Mar/16 ] | |||||||||||||||||||||||||||||
|
Ah, I think I see the problem. scons assumes that the conftests are always in the same order, no matter what command line flags are used to affect scons' behavior. When I run scons without "--ssl", my 40th configure test is a cpp file, which explains why the linker gets confused when it tries to link it as a C program later on. | |||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 17/Mar/16 ] | |||||||||||||||||||||||||||||
|
Here's the config.log output:
Curiously, if I just run the link line by itself, I get the same error. However, if I run the compilation line (verbatim), and then run the link line, the link is successful. I think that means that there is a leftover conftest_40.o from the previous invocation of scons? I'm surprised that scons's configure up-to-date detection mechanism would be fooled by this. |