static linking in distutils/setuptools?
Is there any way to specify static linking to particular libraries when building installers with distutils or setuptools? I want to be able to include the shared libraries that I am linking to in my builds. I did not see any info on this in the docs. Thanks, C. -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us
With the OSX eggs I link and include static libraries for libpng and freetype. You can just put them in a directory and when building mpl use something like, "LDFLAGS=/tmp/static-libs python setup.py build". This will make setuptools look in the directory you specify first. On 1/23/06, Christopher Fonnesbeck <chris@trichech.us> wrote:
Is there any way to specify static linking to particular libraries when building installers with distutils or setuptools? I want to be able to include the shared libraries that I am linking to in my builds. I did not see any info on this in the docs.
Thanks, C.
-- Christopher J. Fonnesbeck
Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL
Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA
T: 727.235.5570 E: chris at trichech.us
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
At 01:48 PM 1/23/2006 -0500, Christopher Fonnesbeck wrote:
Is there any way to specify static linking to particular libraries when building installers with distutils or setuptools? I want to be able to include the shared libraries that I am linking to in my builds. I did not see any info on this in the docs.
I don't believe there's a way to force linking to occur statically. The distutils does have a 'build_clib' command that can be used to *build* static libraries, which then can be linked with your other code, and the current in-development version of setuptools has limited support for building shared libraries that get included with your package. In both cases, however, the tools are for building the libraries, not including system libraries in your distribution.
Christopher Fonnesbeck wrote:
Is there any way to specify static linking to particular libraries when building installers with distutils or setuptools? I want to be able to include the shared libraries that I am linking to in my builds. I did not see any info on this in the docs.
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first. -- Robert Kern robert.kern@gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Hi, Robert Kern:
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first.
Note: Linking static code (gcc without -fpic => foo.o => libfoo.a) into a shared library (lib*.so) is a bad idea. On i386, the required relocation means that the static library's text is not shared between concurrent invocations, and loading the library is more expensive too. On some other architectures, either linking the library, or loading it, will simply fail. You need to build an archive of shared objects (same as above, but use -fpic or equivalent). These are usually named lib*_pic.a IIRC. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - It is surely a great calamity for a human being to have no obsessions. -- Robert Bly
Matthias Urlichs wrote:
Hi,
Robert Kern:
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first.
Note: Linking static code (gcc without -fpic => foo.o => libfoo.a) into a shared library (lib*.so) is a bad idea. On i386, the required relocation means that the static library's text is not shared between concurrent invocations, and loading the library is more expensive too. On some other architectures, either linking the library, or loading it, will simply fail.
You need to build an archive of shared objects (same as above, but use -fpic or equivalent). These are usually named lib*_pic.a IIRC.
On OS X (the platform Chris is building for), -fPIC is the default for everything, so the operation is fairly safe, if not optimal. -- Robert Kern robert.kern@gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Robert Kern wrote:
Christopher Fonnesbeck wrote:
Is there any way to specify static linking to particular libraries when building installers with distutils or setuptools? I want to be able to include the shared libraries that I am linking to in my builds. I did not see any info on this in the docs.
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first.
I believe this is wrong. The (GNU ld) man pages mention '-Bdynamic' and '-Bstatic' as a means to instruct the linker to link to a particular library dynamically or statically. (To only link statically to libbar.a you could write e.g. ... -lfoo -Bstatic -lbar -Bdynamic -lbaz etc.) However, the way distutils is written makes it practically impossible to control such behavior without completely rewriting the whole 'build_ext' command. Hopefully setuptools can manage this better. Regards, Stefan
At 05:05 PM 1/26/2006 -0500, Stefan Seefeld wrote:
I believe this is wrong. The (GNU ld) man pages mention '-Bdynamic' and '-Bstatic' as a means to instruct the linker to link to a particular library dynamically or statically. (To only link statically to libbar.a you could write e.g.
... -lfoo -Bstatic -lbar -Bdynamic -lbaz
etc.)
However, the way distutils is written makes it practically impossible to control such behavior without completely rewriting the whole 'build_ext' command. Hopefully setuptools can manage this better.
Probably not, as I'm not rewriting build_ext, just wrapping it. You might try kludging your library names to be 'foo -Bstatic', 'bar -Bdynamic', etc., if you're on the right platform/compiler.
Phillip J. Eby wrote:
Hopefully setuptools can manage this better.
Probably not, as I'm not rewriting build_ext, just wrapping it.
Is this wrapping transparent ? Or do you present your own command interfaces, for which the current implementation is simply distutils' commands ? One of the weak aspects of distutils (IMO) is its lack of extensibility. There is just no way to plug my own 'Extension' in (with all its build infrastructure), for example. This is definitely a lesson to be learned. FWIW, Stefan
On Jan 26, 2006, at 7:29 PM, Stefan Seefeld wrote:
Phillip J. Eby wrote:
Hopefully setuptools can manage this better.
Probably not, as I'm not rewriting build_ext, just wrapping it.
Is this wrapping transparent ? Or do you present your own command interfaces, for which the current implementation is simply distutils' commands ? One of the weak aspects of distutils (IMO) is its lack of extensibility. There is just no way to plug my own 'Extension' in (with all its build infrastructure), for example. This is definitely a lesson to be learned.
While I don't agree with a lot of the design decisions in distutils, it's plenty extensible. You can plug your own Extension in, just subclass it. -bob
Bob Ippolito wrote:
While I don't agree with a lot of the design decisions in distutils, it's plenty extensible. You can plug your own Extension in, just subclass it.
I disagree. An 'Extension' is "Just a collection of attributes that describes an extension module and everything needed to build it..." (to cite the Extension's own doc string). There is no encapsulation of behavior (i.e. how to build it), as that is handled in separate command classes. And this is why I provided my own build_ext class, which, however, didn't use anything from the 'Extension' type, since that isn't adequate for my needs. Regards, Stefan
Stefan Seefeld wrote:
Robert Kern wrote:
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first.
I believe this is wrong. The (GNU ld) man pages mention '-Bdynamic' and '-Bstatic' as a means to instruct the linker to link to a particular library dynamically or statically. (To only link statically to libbar.a you could write e.g.
... -lfoo -Bstatic -lbar -Bdynamic -lbaz
etc.)
Ah, yes, you are correct. Unfortunately, OS X's ld does not have these options (and is not GNU; I am an idiot). -- Robert Kern robert.kern@gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
On Jan 26, 2006, at 3:29 PM, Robert Kern wrote:
Stefan Seefeld wrote:
Robert Kern wrote:
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first.
I believe this is wrong. The (GNU ld) man pages mention '- Bdynamic' and '-Bstatic' as a means to instruct the linker to link to a particular library dynamically or statically. (To only link statically to libbar.a you could write e.g.
... -lfoo -Bstatic -lbar -Bdynamic -lbaz
etc.)
Ah, yes, you are correct. Unfortunately, OS X's ld does not have these options (and is not GNU; I am an idiot).
What I normally do is specify the full path to the library in extra_link_args, and remove it from the libraries list. -bob
[Bob Ippolito wrote]
On Jan 26, 2006, at 3:29 PM, Robert Kern wrote:
Stefan Seefeld wrote:
Robert Kern wrote:
Not really, no. In many cases (e.g., GNU ld), there's simply no way to tell the linker that you prefer static libraries to shared libraries when you are building a shared library like a Python extension. You simply have to make sure that the static libraries are found first.
I believe this is wrong. The (GNU ld) man pages mention '- Bdynamic' and '-Bstatic' as a means to instruct the linker to link to a particular library dynamically or statically. (To only link statically to libbar.a you could write e.g.
... -lfoo -Bstatic -lbar -Bdynamic -lbaz
etc.)
Ah, yes, you are correct. Unfortunately, OS X's ld does not have these options (and is not GNU; I am an idiot).
What I normally do is specify the full path to the library in extra_link_args, and remove it from the libraries list.
Ditto. Trent -- Trent Mick TrentM@ActiveState.com
-->"Robert" == Robert Kern <robert.kern@gmail.com> writes: Robert> Not really, no. In many cases (e.g., GNU ld), there's simply Robert> no way to tell the linker that you prefer static libraries to Robert> shared libraries when you are building a shared library like a Robert> Python extension. You simply have to make sure that the static Robert> libraries are found first. you can pass the linker a direct path to the archive, rather than using -L/-l. this will ensure static linkage. (not sure if that's helpful in this context though) d
participants (9)
-
Bob Ippolito
-
Charlie Moad
-
Christopher Fonnesbeck
-
David Arnold
-
Matthias Urlichs
-
Phillip J. Eby
-
Robert Kern
-
Stefan Seefeld
-
Trent Mick