AWS_CRT_BUILD_FORCE_STATIC_LIBS #596
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
DmitriyMusatkin
approved these changes
Sep 12, 2024
graebm
commented
Sep 12, 2024
| extra_link_args += ['-Wl,--no-execute-only'] | ||
|
|
||
| # FreeBSD doesn't have execinfo as a part of libc like other Unix variant. | ||
| # Passing linker flag to link execinfo properly | ||
| if sys.platform.startswith('freebsd'): | ||
| extra_link_args += ['-lexecinfo'] | ||
| libraries += ['execinfo'] |
There was a problem hiding this comment.
this wasn't broken, it was just weird we were adding this library via extra_link_args instead of via libraries
| # hide the symbols from libcrypto.a | ||
| # this prevents weird crashes if an application also ends up using | ||
| # libcrypto.so from the system's OpenSSL installation. | ||
| # Do this even if using system libcrypto, since it could still be a static lib. |
There was a problem hiding this comment.
I moved this out of the if-statement because:
Do this even if using system libcrypto, since it could still be a static lib.
| # aws-lc produces libcrypto.a | ||
| AWS_LIBS.append(AwsLib('aws-lc', libname='crypto')) | ||
| # aws-lc produces libcrypto.a | ||
| AWS_LIBS.append(AwsLib('aws-lc', libname='crypto')) |
There was a problem hiding this comment.
I did this so that aws-lc is in AWS_LIBS even if we're not building it, in the same way that all the other non-OS libs are in AWS_LIBS even if we're not building them. This removes some weirdness later where we had to add crypto back into the list of libraries we need to link against
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue:
#593 introduced env-var,
AWS_CRT_BUILD_USE_SYSTEM_LIBS=1, but it didn't work unless those system libs were built statically.Diagnosis:
The reason it didn't work is: there's a hack in setup.py that forces dependencies to be linked statically on Unix variants (excluding macOS). It worked when I tested on macOS because the hack isn't applied there.
The reason for the hack is: in Brazil (internal AWS build system), dependencies are available as both static and dynamic libs. But we prefer to link the static ones so that, if a python application is packaged for AWS lambda, the developer has fewer files they need to chase down and copy into their .zip package.
Description of changes:
Don't force static libs to be used unless
AWS_CRT_BUILD_FORCE_STATIC_LIBS=1(new env-var). Otherwise (by default), the linker will use whatever version of the lib is available (if both are available, linkers generally prefer dynamic). This only applies to non-OS dependencies, we won't force libc to be linked statically.It's unlikely this env-var will be used anywhere except Brazil.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.