On Sun, 5 Aug 2018 13:06:09 +0200 Helmut Grohne <[email protected]> wrote: > Source: tclcl > User: [email protected] > Usertags: rebootstrap > Control: affects -1 + src:nam > > nam fails to cross build from source, because it fails running tcl2c++ > with an "Exec format error". Usually, this indicates that tclcl should > be marked Multi-Arch: foreign. Being a package whose main interface is > two programs, that actually makes sense. Still the question of whether > such a marking is correct is nontrivial to answer. >
tcl2c++ is a tool to convert tcl scripts to C++ program. I am not sure about whether it is can be marked as Multi-Arch: foreign. As to be Multi-Arch: foreign, it need to produce the same C++ source code for different architectures. I guess we need to read the code of tcl2c++ carefully. > To answer it, one needs both a good understanding of multiarch and > package specific knowledge. Most developers lack either. I for one have > little clue about tclcl. In my experience, this issue can be solved by > having some multiarch person (e.g. me) discuss the matter with a package > maintainer. I thus ask you to help me understand the correctness of the > marking. > > When considering the marking, one has to think about the interface that > tclcl provides to other packages. What can others expect by depending on > tclcl? For instance, Debian policy 12.3 requires that the functionality > of packages does not depend on /usr/share/doc being present. Thus > anything in that subtree does not contribute to the interface (or it > violates the Debian policy). In this case, the interface likely consists > of the prorgams tcl2c++ and otcldoc. The question to ask is whether > their behaviour depends on the architecture they are being run on. For > packages that transform files, this includes the file formats being > consumed or produced. For instance, running gcc on armhf produces > different object code than running it on amd64. Thus gcc cannot be > marked Multi-Arch: foreign. Often we can quickly say that the formats > produced or consumed are text formats and thus architecture independent. > Still they can contain multiarch paths (e.g. /usr/lib/<triplet>) or the > tool can look up files on architecture-dependent paths. For instance, > GNU make looks up dependencies of a target in the form "-lfoo" in the > library search path. For this reason, make is not Multi-Arch: foreign. > > Can you help me understand whether the interface of tclcl is > architecture-dependent? > > Thanks for your help > > Helmut > >
