tcl8.5-dev contains /usr/lib/tcl8.5/tclConfig.sh which is a symlink pointing to /usr/share/tcltk/tcl8.5/tclConfig.sh
Currently dpkg-cross only copies symlinks across when crossing a package if the symlink points to somewhere within /lib. symlinks outside /lib are ignored because they are not arch-dependent so shouldn't need to be crossed.
The file /usr/lib/tcl8.5/tclConfig.sh is used by packages which build extensions to tcl (such as sqlite), so that files does need to be present.
The file is essentially a cache of the config options TCL was built with so that extensions can make sure they match up. However it is not arch-independent. e.g. Line 22 of that file is TCL_CC='x86_64-linux-gnu-gcc' on the x86_64 version and TCL_CC='arm-linux-gnueabi-gcc' on the armel version. Other options also differ between 32-bit and 64-bit arches for example.
So this file is arch-dependent in that it's different for each arch it is built-on but arch-independent in that it's just a shell file.
Debian policy (8.2) says: --------------- It is recommended that supporting files and run-time support programs that do not need to be invoked manually by users, but are nevertheless required for the package to function, be placed (if they are binary) in a subdirectory of /usr/lib, preferably under /usr/lib/package-name. If the program or file is architecture independent, the recommendation is for it to be placed in a subdirectory of /usr/share instead, preferably under /usr/share/package-name. Following the package-name naming convention ensures that the file names change when the shared object version changes.
Files and support programs only useful when compiling software against the library should be included in the development package for the library --------------- A maintainer reading the above could reasonably decide that /usr/share was the right place for this file, because the file itself (being just shell) is arch-independent. The problem is that the contents are arch-dependent. Policy is not at all clear on this distinction (It's been making my head hurt all day). For multiarch, or existing dpkg-cross cross-compiling, to work, arch-dependent needs to mean either form _or_ content (see below for elaboration).
The original tcl build puts both tclConfig.sh and tcl.m4 in /usr/lib but the debian packaging moves them to /usr/share/tcltk/tcl8.5 and /usr/share/aclocal/ respectively
Currently the sqlite build fails because it looks for tclConfig.sh in /usr/<triplet>/lib/tcl8.5/ and doesn't find it there, because dpkg-cross didn't copy the symlink (or original) there.
So, the questions is - which of these is the correct fix: 1) make dpkg-cross copy over symlinks even when they point into /usr/share 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of /usr/share/tcltk/tcl8.5 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5 instead of /usr/lib/tcl8.5 when building
I note that the supplied tcl8.5.m4 file actually lists a whole pile of possible locations for the file: for i in `ls -d ${libdir} 2>/dev/null` \ `ls -d ${exec_prefix}/lib 2>/dev/null` \ `ls -d ${prefix}/lib 2>/dev/null` \ `ls -d /usr/local/lib 2>/dev/null` \ `ls -d /usr/contrib/lib 2>/dev/null` \ `ls -d /usr/share/tcltk/tk8.5 2>/dev/null` \ `ls -d /usr/lib 2>/dev/null` \ `ls -d /usr/lib64 2>/dev/null` \
However that list doesn't include anything ending in tcl8.5 (i.e /usr/<triplet>/lib/tcl8.5 or /usr/share/tcltk/tcl8.5) and perhaps should by way of 'back-up plan', although I haven't actually looked into the detals of how that is used.
Consideration when deciding how to fix this include: Squeeze will be released in a few days with this broken so we will be stuck with the /usr/share/ file location for some time there. Any fix going into Ubuntu should make Natty easily enough.
For Multiarch tcl-dev will be a Multiarch:same package (i.e a 'library' package) (despite the name, it contains nothing but headers, libraries and the above config.sh and m4 files), so the two different tclConfig.sh files supplied by the DEB_BUILD_ARCH and DEB_HOST_ARCH packages (when cross-building) will clash and the 2nd package will not be installable. This, it seems to me, is the clinching argument that the correct fix is to change the tcl build to put these files in /usr/lib.
This also implies that policy 8.2 needs to be clarified to explain what 'arch-independent' means.
Are there other situations which expect to find the tclConfig.sh file in /usr/share? Is so those need considering.
Does anyone disgree with the above conclusions? And do people agree that policy 8.2 could be clearer on this point?
I've filed a bug containing some of the above discussion and a patch for tcl8.5. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611650
Wookey