Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Building from source on Debian

  • Swaine Chen
    Swaine Chen

    Somewhat related to this thread:
    but details for building on Debian Sarge.

    I finally managed to get everything to build ok except for the documentation, but wasn't very concerned with that.

    Short story:
    System: Debian Sarge
    Kernel: 2.6.8 Custom
    Package: staden-src-1-5-3.tar.gz
    Idea: Debian packages exist for most of the build requirements.  I wasn't interested in recompiling and reinstalling third-party libraries to get this to build.  What follows is how to get the package to build using only apt-get-able libraries which can be found on the main Debian mirrors.
    Relevant package list:
    ii  itcl3          3.2.1-3      
    ii  itcl3-dev      3.2.1-3      
    ii  itcl3.1        3.1.0-7      
    ii  tcl8.3         8.3.5-4      
    ii  tcl8.3-dev     8.3.5-4      
    ii  tcl8.4         8.4.9-1      
    ii  tcl8.4-dev     8.4.9-1
    ii  itk3           3.2.1-3      
    ii  itk3-dev       3.2.1-3      
    ii  itk3.1         3.1.0-7
    ii  tk8.3          8.3.5-4      
    ii  tk8.4          8.4.9-1      
    ii  tk8.4-dev      8.4.9-1
    ii  iwidgets4      4.0.1-3
    ii  zlib1g         1.2.2-3      
    ii  zlib1g-dev     1.2.2-3
    ii  libpng10-0     1.0.18-1     
    ii  libpng12-0     1.2.8rel-1   
    ii  libpng12-dev   1.2.8rel-1
    There are three main things (in addition to everything mentioned in README.build) that needed to be changed to get this to build properly.
    (1) change include variables in src/mk/globals.mk to point to location of Debian header files
    (2) for all 'dependencies' files, change $(SRCROOT)/[tk|tcl]8.4.6/generic to Debian location: /usr/include/tcl8.4/[tk|tcl]-private/generic
    (3) change 'ln -s' to 'ln -sf' in all Makefiles where they appear
    Slightly more details:
    (1) here's the diff:
    diff -r orig/src/mk/global.mk staden-src-1-5-3/src/mk/global.mk
    < TCLSRC                = $(SRCROOT)/tcl8.4.6/generic
    < TKSRC         = $(SRCROOT)/tk8.4.6/generic
    < ITCLSRC               = $(SRCROOT)/incrTcl-3.3cvs/itcl/generic
    < ITKSRC                = $(SRCROOT)/incrTcl-3.3cvs/itk/generic
    > #TCLSRC               = $(SRCROOT)/tcl8.4.6/generic
    > TCLSRC                = /usr/include/tcl8.4/tcl-private/generic
    > #TKSRC                = $(SRCROOT)/tk8.4.6/generic
    > TKSRC         = /usr/include/tcl8.4/tk-private/generic
    > #ITCLSRC              = $(SRCROOT)/incrTcl-3.3cvs/itcl/generic
    > ITCLSRC               = /usr/include/tcl8.4/itcl-private/generic
    > #ITKSRC               = $(SRCROOT)/incrTcl-3.3cvs/itk/generic
    > ITKSRC                = /usr/include/tcl8.4/itk-private/generic

    (2) There are 2 files that need to be changed:

    (3) There are 2 Makefiles that need to be changed:

    I can provide a diff file if need be, but a little afraid it won't come out formatted right in this message.

    Hope this helps others.

    Swaine Chen
    slchen (at) users (dot) sourceforge (dot) net

    • James Bonfield
      James Bonfield

      There are a few tweaks to tcl/tk that I added for the purposes of speeding things up, most notably with the file browser (which in the default incarnation is abysmally slow with lots of exp and ztr files in a directory).

      These changes have, where possible, been submitted back to the appropriate developers. I should review the situation again to see how many of these changes made their way in to the tk core.

      That said, the Staden Package does not *require* modified versions of tk so it'll still work fine with the standard ones.

      It may be valid to just generate the dependency files using "make depend". I'm not 100% sure that code will work correctly on all systems though. The plan was that the dependency files are just for local dependencies and so system files (/usr/include/fu/bar, etc) get grepped out.
      Without doing this make depend on an Alpha would mean a build on linux would fail unless another make depend was run.

      I guess that a better solution here is to have the dependency output generated on the fly and stored in the machine-specific output directories.

      I'm not even sure it really matters to most people. The key reason for various platform-specific subdirectories is that it makes my development so much easier as I do not need multiple source trees. (VPATH is probably a better bet now that I can always rely on using gnu make.)

      The documentation really ought to work now as that's had quite a few tweaks to make it more linux-friendly and using standard versions of tools. (Originally we had a hacked makeinfo version.)

      Finally, the Makefile system will never be as easy (for users) to setup as just ./configure; make. The reason is that the same source tree has to work on windows too (and not by using cygwin libraries). It may now be possible to use configure on all the platforms, but frankly libtool is the spawn of the devil and I hate it to pieces!

      Perhaps a debian.mk Makefile stub to change various global.mk components to be in a more debian-specific location is the best way to go. I'll happily add this into the source tree if you wish.


    • Swaine Chen
      Swaine Chen

      Sorry, in testing some of your suggestions I realized I'd left out two other things I had done, which to continue the list from the first post, should be items 4 and 5.

      (4) Add the following lines to the beginning of staden-src-1-5-3/src/tk_utils/tkCanvGraph.c:

      #define HAVE_LIMITS_H
      #define HAVE_UNISTD_H

      These two lines get rid of error messages about not having limits.h and unistd.h in /usr/include (which is where they are)

      (5) the file staden-src-1-5-3/src/tk_utils/tclAppInit.c is a broken symbolic link (I assume if you compile the third party libraries yourself it is no longer broken) so should be fixed to point to /usr/lib/tcl8.4/tclAppInit.c

      Sorry for the omissions.

      That said, I tried making only the changes in items 1,3,4,5 and did a "make depend" followed by "make" and that seemed to compile fine.  So at least some of the hand editing in (2) from the first message (editing the dependencies files) becomes unnecessary.

      Thanks for all your work on this package.  I'm probably not a good one to ask whether or how these changes should be made, but at least hopefully this will help others on Linux who are interested in compiling the package using binary packages for library dependencies.  You guys have obviously worked a lot on this and thus I was pretty sure the compilation problems I was getting at first were relatively minor.

      Thanks again.