force static linking
Hello, I am attempting to build statically linked distributions. I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern. Is there any way to force static linking so that wheels can be installed into a virtual env without requiring specific packages on the host? Thanks, Gordon
On Thu, Sep 11, 2014 at 5:28 AM, gordon <wgordonw1@gmail.com> wrote:
Hello,
I am attempting to build statically linked distributions.
I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern.
Is there any way to force static linking so that wheels can be installed into a virtual env without requiring specific packages on the host?
Maybe pass -static in $LDFLAGS? Just a wild guess really.
Gordon, If you are sure that your dev and production environments match, then you should have same shared libraries on both, and no need for static linkage? -Bill On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg <drsalists@gmail.com> wrote:
On Thu, Sep 11, 2014 at 5:28 AM, gordon <wgordonw1@gmail.com> wrote:
Hello,
I am attempting to build statically linked distributions.
I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern.
Is there any way to force static linking so that wheels can be installed into a virtual env without requiring specific packages on the host?
Maybe pass -static in $LDFLAGS? Just a wild guess really. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Is this the general perspective on static linking of python module dependencies? That if your systems are the same, you don't need to? I want static linking too, but if it's swimming upstream in a fast river, I may reconsider. Thanks. On Mon, Mar 23, 2015 at 11:41 AM, Bill Deegan <bill@baddogconsulting.com> wrote:
Gordon,
If you are sure that your dev and production environments match, then you should have same shared libraries on both, and no need for static linkage?
-Bill
On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg <drsalists@gmail.com> wrote:
On Thu, Sep 11, 2014 at 5:28 AM, gordon <wgordonw1@gmail.com> wrote:
Hello,
I am attempting to build statically linked distributions.
I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern.
Is there any way to force static linking so that wheels can be installed into a virtual env without requiring specific packages on the host?
Maybe pass -static in $LDFLAGS? Just a wild guess really. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 23 March 2015 at 18:45, Dan Stromberg <drsalists@gmail.com> wrote:
Is this the general perspective on static linking of python module dependencies? That if your systems are the same, you don't need to?
I want static linking too, but if it's swimming upstream in a fast river, I may reconsider.
On Windows, it's not uncommon to statically link dependencies into a wheel. Obviously that's a very different environment, and the situation isn't the same, but it's certainly something that *can* be done. I don't know how easy it is to do it on Linux, though (on Windows, it's mostly a case of building static libs for your dependencies and linking to those rather than to DLLs, AIUI). Paul.
On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg <drsalists@gmail.com> wrote:
Is this the general perspective on static linking of python module dependencies? That if your systems are the same, you don't need to?
That's general -- nothing specific to python here. There _may_ be a difference in that you might be more likely to want to distribute a binary python module, and no be sure of the level of compatibility of the host sytem -- particularly if you use a non-standard or not-comon lib, or one you want built a particular way -- like ATLAS, BLAS, etc... I want static linking too, but if it's swimming upstream in a fast
river, I may reconsider.
well it's a slow river... The easiest way is to make sure that you only have the static version of the libs on the system you build on. You may be able to do that by passing something like --disable-shared to configure, or you can just kludge it and delete the shared libs after you build and install. -Chris
Thanks.
Gordon,
If you are sure that your dev and production environments match, then you should have same shared libraries on both, and no need for static
On Mon, Mar 23, 2015 at 11:41 AM, Bill Deegan <bill@baddogconsulting.com> wrote: linkage?
-Bill
On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg <drsalists@gmail.com>
wrote:
On Thu, Sep 11, 2014 at 5:28 AM, gordon <wgordonw1@gmail.com> wrote:
Hello,
I am attempting to build statically linked distributions.
I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern.
Is there any way to force static linking so that wheels can be
installed
into a virtual env without requiring specific packages on the host?
Maybe pass -static in $LDFLAGS? Just a wild guess really. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 24 Mar 2015 05:16, "Chris Barker" <chris.barker@noaa.gov> wrote:
On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg <drsalists@gmail.com>
Is this the general perspective on static linking of python module dependencies? That if your systems are the same, you don't need to?
That's general -- nothing specific to python here.
There _may_ be a difference in that you might be more likely to want to distribute a binary python module, and no be sure of the level of compatibility of the host sytem -- particularly if you use a non-standard or not-comon lib, or one you want built a particular way -- like ATLAS, BLAS, etc...
I want static linking too, but if it's swimming upstream in a fast river, I may reconsider.
well it's a slow river...
The easiest way is to make sure that you only have the static version of
wrote: the libs on the system you build on. You may be able to do that by passing something like --disable-shared to configure, or you can just kludge it and delete the shared libs after you build and install. The "not swimming upriver" approach is to look at conda for language independent cross-platform user level package management :) It's purpose built to handle the complexities of the scientific Python stack, while the default Python specific toolchain is more aimed at cases where you can relatively easily rely on Linux system libraries. Cheers, Nick.
-Chris
Thanks.
On Mon, Mar 23, 2015 at 11:41 AM, Bill Deegan <bill@baddogconsulting.com>
Gordon,
If you are sure that your dev and production environments match, then you should have same shared libraries on both, and no need for static
wrote: linkage?
-Bill
On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg <drsalists@gmail.com>
wrote:
On Thu, Sep 11, 2014 at 5:28 AM, gordon <wgordonw1@gmail.com> wrote:
Hello,
I am attempting to build statically linked distributions.
I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern.
Is there any way to force static linking so that wheels can be
installed
into a virtual env without requiring specific packages on the host?
Maybe pass -static in $LDFLAGS? Just a wild guess really. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
For outsourcing upstream packaging of (cross-platform) dependencies, I'll second +1 conda. Pants Build bundles everything into a static executable (PEX); and works with pip requirements.txt files. On Mar 23, 2015 5:30 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 24 Mar 2015 05:16, "Chris Barker" <chris.barker@noaa.gov> wrote:
On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg <drsalists@gmail.com>
Is this the general perspective on static linking of python module dependencies? That if your systems are the same, you don't need to?
That's general -- nothing specific to python here.
There _may_ be a difference in that you might be more likely to want to distribute a binary python module, and no be sure of the level of compatibility of the host sytem -- particularly if you use a non-standard or not-comon lib, or one you want built a particular way -- like ATLAS, BLAS, etc...
I want static linking too, but if it's swimming upstream in a fast river, I may reconsider.
well it's a slow river...
The easiest way is to make sure that you only have the static version of
wrote: the libs on the system you build on. You may be able to do that by passing something like --disable-shared to configure, or you can just kludge it and delete the shared libs after you build and install.
The "not swimming upriver" approach is to look at conda for language independent cross-platform user level package management :)
It's purpose built to handle the complexities of the scientific Python stack, while the default Python specific toolchain is more aimed at cases where you can relatively easily rely on Linux system libraries.
Cheers, Nick.
-Chris
Thanks.
On Mon, Mar 23, 2015 at 11:41 AM, Bill Deegan <
Gordon,
If you are sure that your dev and production environments match, then you should have same shared libraries on both, and no need for static
bill@baddogconsulting.com> wrote: linkage?
-Bill
On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg <drsalists@gmail.com>
wrote:
On Thu, Sep 11, 2014 at 5:28 AM, gordon <wgordonw1@gmail.com> wrote:
Hello,
I am attempting to build statically linked distributions.
I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern.
Is there any way to force static linking so that wheels can be
installed
into a virtual env without requiring specific packages on the host?
Maybe pass -static in $LDFLAGS? Just a wild guess really. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
participants (7)
-
Bill Deegan -
Chris Barker -
Dan Stromberg -
gordon -
Nick Coghlan -
Paul Moore -
Wes Turner