Environment variables

Anonymous
2004-04-10
2004-04-13
  • Anonymous - 2004-04-10

    Hello James and others.  First, thanks for helping to get the Staden package on to Sourceforge and making it available for everyone.  It's going to be excellent.

    I've run into a problem with the Mac OS X build (1.4.1) - and this is probably a problem with previous versions too - but I've just noticed: Anyway, by setting the DYLD_LIBRARY_PATH environment variable to DYLD_LIBRARY_PATH=/usr/local/staden-macosx-1-4-1/lib/macosx-binaries in the ~/.bash_profile login script produces a big problem with other apps that want to use those libraries.

    I've just got a program compiled (an HTML editor called Bluefish) that uses libpng but it breaks if I have set DYLD_LIBRARY_PATH in my login script because there is a version incompatibility.

    The solution is to unset the environment variable unless I am using Staden - but this is a problem (or more of a nusience really) if I want to use them both together (or any other program that uses the libraries that Staden uses.

    I posted a message to the fink mailing list (the fink package manager is what I use to install a lot of other apps) and one of the developers there replied with the following suggestion:

    <start of fink dev post>
    The problem you are having is a classical example for why it is generally considered harmful to set this environment variable. It should only be used in exceptional cases, for testing new versions of libraries etc. Setting it in a login file is really bad style and a sign of lazy programmers.

    They could and should have defined install_name for their libraries, and the executables would then find the libraries automatically. You might want to go to the staden site and hit them over the head with some Darwin programmer's manual. I mean, producing something like what I see here is really disgusting:

    % otool -L staden-macosx-1-4-1/macosx-bin/stash
    staden-macosx-1-4-1/macosx-bin/stash:
            ../lib/macosx-binaries/libtk_utils.dylib (compatibility version 0.0.0, current version 0.0.0)
            libpng12.0.1.2.5.dylib (compatibility version 0.0.0, current version 0.0.0)
            /usr/local/lib/libtk8.4.dylib (compatibility version 8.4.0, current version 8.4.0)
            /usr/local/lib/libtcl8.4.dylib (compatibility version 8.4.0, current version 8.4.0)
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0)
            /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, current version 6.2.0)

    <end of fink dev post>

    So, I'm not a programmer and can't really help with more suggestions here, but I wonder if something could be done about this in the long run.  Another thing that would be good is that the build process could ported to the fink system - this would greatly increase the user base and help to guarantee long-term survival. I'd offer to help with this but I'll be learning as I go as I'm a bit of an amateur.

    Any comments?  Cheers, David.

     
    • James Bonfield

      James Bonfield - 2004-04-13

      I couldn't agree more with the fink people really. The Staden Package distribution IS a tangled mess. However I simply do not have time to learn the "fink way" to do it properly, or indeed to read the "darwin manual" even if beaten over the head with it! Volunteers are, of course, welcome :-)

      Also, -install_name seems completely pointless to me. Sure it'll work if everyone installs the package binaries in the same place, but who am I to force people to use the same pathnames are me for the package installation root? Possibly if install_name handles relative paths it could work, but I haven't checked this.

      The only downside to splitting the package up into the various fink depedencies (tcl, tk, png, zlib, etc) is that novice users would find installing the package substantially harder if it means also installing 4 or 5 other fink packages first.

      My advice though would be to ignore the staden.profile / staden.login scripts and just set up PATH manually. This means htat you may not be able to find libraries for command line tools like extract_seq and the link, but the main tools (trev, pregap4, gap4, spin) will all still work.

      The reason is that these programs are infact shell scripts that set the environment variables themselves and so ou do not need to setup the environment before hand (causing potential clashes).

      Finally let me reiterate the comment earlier. The hard work (writing the staden package) has already been done. Wrapping it up into an easy to use distribution is the easy bit, so people with appropriate expertise please please feel free to do it for me. I'm unlikely to do this myself as neither myself or employer currently use macosx for this purpose and I do not have my own Mac.

      James

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks