[Gdal-dev] status of ldshared build? (or,
other options for OSX framework build)
Chris.Barker at noaa.gov
Fri Nov 2 01:11:02 EDT 2007
Thanks for all this OS-X work William!
> it looks like libtool is simply getting
> in the way - it can't make a library file with a 'lib' prefix and
> '.dylib' extension.
It sounds likethe OS-X port of libtool is broken and/or incomplete --
are the libtool developers open to fixing this kind of stuff?
I don't have my OS-X box in front of me, but is the lib* convention not
usually used with *.dylib? (ie,. it's either the old *nix lib*.so or
Anyway, I'm pretty sure I've seen python extensions built against
*.dylibs before -- why do we need the lib*.dylib convention?
> And without knowing the exact path to the built
> python or installed python gdal libs (they're controlled by
> distutils/setuptools), there is no way to to postprocess them into
> framework binaries.
Now I'm confused -- isn't the goal here to build a GDAL Framework that
the python extensions can use? In which case it seems you'd need to hack
the GDAL framework, not the python install.
Anyway, if you sue the python that you're running setup.py with, you
should be able to use it to figure out the path to the python
installation (or could you hack it before installing, in which case,
it's in the build dir that distutils creates)
I wonder if some of the complication is coming from the order that we're
using to do things -- if we did:
install GDAL lib (framework on OS-X)
build python extensions (using installed GDAL)
install python extensions
would that work better? I guess I've see this kind of thing done two ways:
Either the lib is there just to support the python extensions (like
PIL), in which case it is built, then the extensions built, then the
whole shebang installed in site-packages
Or the lib exists outside of python, and you want to use in in
non-python tools (that would be GDAL) -- in that case, it's usually
built and installed separately.
Then there's a third case -- like wxPython -- wx is used by other,
non-python apps, but wxPython needs a specific build, so it's usually
built and installed alongside the extension, not in a central location.
However, the lib is still built and installed before building the python
> One possibility is for configure to somehow get from python the exact
> install path and store it in gdalmake.opt.
I'd think there'd be some way to query distutils for this. This looks
> My other thought is to use the ldshared build, where we have complete
> control over the compile and link commands configurations and build the
> binary correct from the start. then the python libs link correctly and
> no post-processing is needed. Currently, it looks like the ldshared
> build is taylored to linux only. I recall hearing some time ago that it
> wasn't really being maintained?
I presume that libtool has been adopted for a good reason, but I'll let
someone who knows comment on that. It does seem like a bad ides to try
to maintain multiple systems.
Howard Butler wrote:
> People seem to prefer the 'make install' approach of manually copying
> things as we did in the past,
What's the difference? the scripts are useless without the python
bindings, so It makes more sense to me to have distutils install them
(or is it hard to get them in the right place that way?)
Given what's going on with the issues on OS-X, I'm feeling more and more
like I'd rather the python extensions, and accompanying scripts, were
separately built and installed with distutils/setuptools, and stop
trying to integrate it into one make && make install step.
Is this to save a couple lines of typing?
In any case it would be nice to have the option of building separately?
I haven't tried it, but is it as easy as just using without-python in
.configure, then running setup.py after building and installing GDAL?
Christopher Barker, Ph.D.
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 at noaa.gov
More information about the gdal-dev