Bug#599206: dpkg-cross should leave files in converted package
On Tue, Oct 05, 2010, Neil Williams wrote:
> This script is a "build-tool", it is not a "cross-build-dependency" in
> that it is not a header file, it is not a pkg-config file and it is not
> used when linking the cross built application. The file is therefore
> not architecture-dependent and cannot be handled by dpkg-cross.
It is a build tool, but it's specific to the target architecture
The fact that it's not a header, not a pkg-config file, and not used
when linking cross built applications doesn't imply that it is
architecture independent.
I diffed tclConfig.sh on armel and amd64:
@@ -18,10 +18,10 @@ TCL_MINOR_VERSION='5'
TCL_PATCH_LEVEL='.8'
# C compiler to use for compilation.
- TCL_CC='x86_64-linux-gnu-gcc'
+ TCL_CC='arm-linux-gnueabi-gcc'
# -D flags for use with the C compiler.
- TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\" -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1 -DTCL_THREADS=1 -DTCL_CFGVAL_ENCODING=\"iso8859-1\" -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1 -DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1 -DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_UNLOAD_DLLS=1 '
+ TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\" -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GETATTR_NP=1 -DGETATTRNP_NOT_DECLARED=1 -DTCL_THREADS=1 -DTCL_CFGVAL_ENCODING=\"iso8859-1\" -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1 -DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1 -DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_UNLOAD_DLLS=1 '
# TCL_DBGX used to be used to distinguish debug vs. non-debug builds.
# This was a righteous pain so the core doesn't do that any more.
BTW in /usr/lib is actually a good indication that it might be
arch-specific IMHO (by opposition to /usr/share where it must be
arch-independent).
Being in a subdir of usr/lib (usr/lib/tcl8.5) makes it less obvious
that it's relevant for the crossed package since it might look like a
plugin directory.
> If having the amd64 package around causes trouble, discuss with the tcl
> maintainers whether the script can be put into a -dev-common package
> or whether some more standard tool like pkg-config can be used instead.
Not an option here since the script does differ across architectures.
> This is a recurring problem in cross-building. dpkg-cross cannot leave
> these files in place or the -cross package won't install. In an ideal
> world, it would be nice if cross builds had a completely clean build
> environment without native build-deps but that is not reality. Many
> packages have architecture-independent support scripts which behave no
> differently whether the build is native or cross. There is nothing
> dpkg-cross can do about this except explain it in the manpage.
Not an architecture-independent support script here.
Being a shell script also doesn't make it a native script; it can be
used for both cross and native builds.
> If the script doesn't generate the correct config when cross-building,
> file a bug with Tcl to get the script to accept a parameter which can
> be handled in the cross build. Simply moving the script to somewhere
> under /usr/lib/arm-linux-gnueabi/ is not going to help you.
The data will be different depending on the output of tcl's
configuration script, so it would be a maintenance nightmare to try to
maintain the output of the configuration script in a single tool
supporting all possible arches.
The two ways I see this getting fixed:
a) (preferred) get dpkg-cross to output a
/usr/share/arm-linux-gnueabi/tcl8.5/tclConfig.sh and change tcl-based
builds to look for that one when cross-building
b) change tcl to output a tcl-cross-config-armel or similar package
containing just the above (very ugly IMHO); this would essentially be
like providing a cross-compiler except it's a cross-tcl-configuration
tool; it's very intrusive for the tcl packaging though
Now I bet Neil would be unhappy to have some specific tcl bits
hardcoded in dpkg-cross, which would be fair enough.
@Neil: what would you think of providing some kind of extension
mechanism for these files in packages? e.g. dpkg-cross would run
/etc/dpkg-cross/hooks.d/*.pl and tcl8.5-dev would provide one, or
something similar?
Cheers
--
Loïc Minier
Reply to: