You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering why the static library libpythonXX.a (example in the alpine: /usr/local/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.a) was kept in the docker image for all the image variance, while the --enable-shared flag is active for the compilation process. That file is around 50% of the image size on the alpine.
I am assuming this is intended for the usage of some use case where you might need to link some code directly to it, but the documentation of the image only make reference to using the image as base, including our own script and just run it with python (which seems to be dynamically linked to the .so files).
I am mostly curious to know if this is intended or if this is an oversight from a few year ago when the --enable-shared flag was added.
The text was updated successfully, but these errors were encountered:
Hello,
I was wondering why the static library libpythonXX.a (example in the alpine: /usr/local/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.a) was kept in the docker image for all the image variance, while the --enable-shared flag is active for the compilation process. That file is around 50% of the image size on the alpine.
I am assuming this is intended for the usage of some use case where you might need to link some code directly to it, but the documentation of the image only make reference to using the image as base, including our own script and just run it with python (which seems to be dynamically linked to the .so files).
I am mostly curious to know if this is intended or if this is an oversight from a few year ago when the --enable-shared flag was added.
The text was updated successfully, but these errors were encountered: