*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
That OS X coot stand-alone thing that I wrapped up is a first attempt at such a thing. Here is what I did to make it: 1. Built coot in /usr/local/xtal/coot. 2. Used otool -L to see what dylibs that the binary had linked from coot-real(ldd works on linux). 3. Copied each of those files to /usr/local/xtal/coot/lib 4. In the wrapper shell script, have $DYLID_LIBRARY_PATH point to the above 5. Moved /sw and anything else that wasn't system-dependent out of the way. 6. Tested it, and kept copying in libraries until it worked. 7. Put all the extra platform-independent stuff (like scm files) into coot/share. 8. Tested it on an "uncontaminated" computer to make sure nothing was missing. My task was made somewhat easier in that I used static clipper libraries to link to. Heh. Bill Phil Evans wrote: > *** For details on how to be removed from this list visit the *** > *** CCP4 home page http://www.ccp4.ac.uk *** > > > > I suppose I'm asking a silly question, "Why is it so difficult to > make a binary which will work anywhere?" (or at least on allegedly > similar systems) > > How do commercial software houses manage? Do they package all the > dependencies with their applications (perhaps this is why Adobe CS2 > is >5GB)? > > The amount of work involved is one reason why CCP4 resisted for many > years the demand for distributing executables, and I do know that > Paul & Kevin have spent (wasted?) a lot of time on this. > > Phil > > > On 16 Jan 2007, at 11:12, Kevin Cowtan wrote: > >> *** For details on how to be removed from this list visit the *** >> *** CCP4 home page http://www.ccp4.ac.uk *** >> >> >> You're new here aren't you. :) >> >> To recap, you can't use static lib because coot links into major >> system >> dependent components, like X and openGL. If it were possible to build >> coot statically (which it isn't because the libraries it links to >> cannot >> themselves be built statically for this very reason), then it would >> work >> on one hardware configuration only. >> >> It is potentially possible to make more of the dependencies static >> than are currently static. But this requires building all of the >> dependencies, some of which will require major changes to the build >> system to make it happen. >> >> What you are asking for is probably more like years than months of >> work, and would take some serious software engineering expertise. >> >> Phil Evans wrote: >>> On a different topics, is there really a reason for not using >>> static libraries? Dynamic libraries are a constant pain, both to >>> users and maintainers, because there are always different >>> versions on different machines (and of course we don't have all >>> our machines on the same OS version, like I imagine most people). >>> Also the obscure error messages "can't find right version of >>> libthingy-99.9.dylib" or whatever is deeply confusing to nearly >>> all of us. >>> I love stand-alone binaries with no external dependencies >>> Phil >>>> On 11 Jan 2007, at 00:39, Donnie Berkholz wrote: >>>> >>>>> William Scott wrote: >>>>> >>>>>> Or you could just build ccp4-onlylibs-dev, use the include/ >>>>>> ccp4.setup-x >>>>>> file in THAT, and source it before building coot. If you build >>>>>> ccp4-onlylibs-dev with only static libs, then you can even get >>>>>> rid of the >>>>>> ccp4-onlylibs-dev installation afterwards. >>>>>> >>>>>> That is the way I have been doing it. >>>>> >>>>> >>>>> Thanks for the suggestion -- it does provide an escape route. Being >>>>> forced to use static libraries is really a hack, though. It also >>>>> violates our packaging policy because it makes security updates >>>>> very >>>>> difficult. People are still finding static and bundled copies of >>>>> vulnerable zlib from a year ago and more. It also means >>>>> everyone's going >>>>> to be building essentially the same libraries twice for no good >>>>> reason. >> >> >
