[CXX-286] Support additional custom compiler and linker options when invoking scons (e.g. rpath) Created: 21/Jul/14  Updated: 27/May/22  Resolved: 23/Jan/15

Status: Closed
Project: C++ Driver
Component/s: Build
Affects Version/s: legacy-0.0-26compat-2.6.3
Fix Version/s: legacy-1.0.0-rc4

Type: Improvement Priority: Minor - P4
Reporter: Kevin Locke Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 0
Labels: legacy-cxx
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-16663 options requested in top-level SConst... Closed
Duplicate
is duplicated by CXX-104 Option to add flags to client build Closed
Server Compat: 3.0

 Description   

I have been unable to find a way to build the C++ driver with additional custom linker options. I am currently attempting to build libmongoclient with Wl,-z,origin,-rpath=\$ORIGIN,-rpath-link=$(pwd) for a non-system-wide installation. I can almost accomplish this with the option -ld="clang++ -Wl,-z,origin,-rpath=\$\$ORIGIN,-rpath-link=$(pwd), but the string is evaluated for variables multiple times at different depths resulting in error messages such as the following:

scons: *** [build/linux2/c++11/cc_clang/cxx_clang++/ld_clang++ -Wl_-z_origin_-rpath=$ORIGIN_-rpath-link=_tmp_dependencies_lib/use-system-boost/libmongoclient.so] Implicit dependency `build/linux2/c+11/cc_clang/cxx_clang/ld_clang+ -Wl_-z_origin_-rpath=-rpath-link=_tmp_dependencies_lib/use-system-boost/third_party/libshim_boost.a' not found, needed by target `build/linux2/c+11/cc_clang/cxx_clang/ld_clang+ -Wl-z_origin_-rpath=$ORIGIN_-rpath-link=_tmp_dependencies_lib/use-system-boost/libmongoclient.so'.

Note the mismatch where sometimes $ORIGIN follows -rpath and other times it doesn't. Although this may be a bug, passing linker options as part of the linker command seems like a hack that may not be worth supporting.

Although my current use-case could be addressed by adding some rpath options to SConstruct, I suspect the issue may be better addressed with an approach that would allow any custom linker options rather than rewriting every linker option users may need as a scons option.

As a better solution, would it be possible to support $LDFLAGS from the environment (as autotools- and cmake-based build systems do) for passing custom linker options? Possibly protected by an option similar to -cc-use-shell-environment such as -ldflags-use-shell-environment?

I think this may be useful for $CFLAGS and $CXXFLAGS as well, but I can file that as another issue if it is worth considering separately.

Thanks for considering,
Kevin



 Comments   
Comment by Kevin Locke [ 21/Jul/14 ]

Hi Andrew,

Thanks for responding so quickly and thoroughly. That makes a lot of sense and I agree on all points. Feel free to merge this ticket with CXX-104, they do appear to be duplicates (sorry about that).

As for how to delimit the strings, it seems like there is not much consistency in this area between build systems. In building the other libraries for my current project, I have escaped $ORIGIN many different ways in LDFLAGS for the different projects and it is never documented and usually a matter of trial-and-error between escaping for Makefile macros (with $$) and shell escapes (either quotes or backslashes). My recommendation would be to handle word-splitting like the shell (if that's easily possible inside scons) so directories with spaces would need to be quoted or the space escaped, and avoid variable expansion in the passed string, but if that is difficult I wouldn't spend much engineering effort reimplementing shell parsing since anyone going down this road will be used to dealing with trial-and-error escaping. But that's just my 2c at the moment and not a well-researched opinion.

Thanks,
Kevin

Comment by Andrew Morrow (Inactive) [ 21/Jul/14 ]

Hi Kevin -

There is actually a (not very detailed) ticket requesting this feature (see CXX-104). I think it is a reasonable request, and I had been hoping to do it for the upcoming 1.0.0-rc1 release of the legacy driver. I think we would want, at minimum, a way to specify early flags (e.g. ones that are applied at Environment construction time) in case they are necessary to make things like the compiler validity checks pass, and late flags (so that you can override flags that we put on the build line ourself).

We should probably offer this for:

  • CFLAGS
  • CCFLAGS
  • CXXFLAGS
  • LINKFLAGS
  • SHLINKFLAGS

We would need to decide whether to use the SCons Variables feature for this, or make these options (--cflags and --extra-cflags, etc.?). An additional question, as you point out, is quoting. If using the Variables feature, how should this work if you want to pass several flags? Should they be comma delimited? A quoted space delimited string seems easiest, but then there are problems with things like spaces in paths. Similar subtleties exist with making them --options. And there are probably still some issues to be considered re escaping things like $ORIGIN as you mention.

Finally, please note that this work would be done on the legacy branch, but it is unlikely that it would be backported to the 26compat branch, since that is now a maintenance release series.

Generated at Wed Feb 07 21:58:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.