Hello. I'm maintaining debian cross-compiler package building paches.
Since recently, debian gcc-3.4 source package started to build libunwind during build process for ia64 architecture. To do so, package has a copy of libunwind-0.98.3 sources. Later library (libunwind.so.7) is placed into libgcc1 binary package. While building cross-compiler packages (in this case, for ia64 target), I try to create exactly same binaries (in this case, libunwind.so.7) in appropriate cross-library package (libgcc1-ia64-cross). Do do so, I have to cross-compile libunwind-0.98.3. What I want to get is exactly same .so library as is created in native ia64 build. Unfortunately, I'm having technical problems here. First, libunwind build procedure first creates two tools, mk_Gcursor_i and mk_Lcursor_i, that are executed to produce two headers that are used later in the build process. This can't work when cross-compiling (unless special care is taken to build the tools with native compiler, not cross compiler - but this is not done in current libunwind build system) Second, looks that when cross-compiling (--host=ia64-linux --build=x86-linux), REMOTE_ONLY automake conditional is set to true, which causes different things to be built other than when native-compiling. To make libunwind cross-compile properly, some hacks may be used (e.g. providing pre-generated headers and manual overriding of REMOTE_ONLY) setting part of configure before running it. But isn't it better to add proper cross-compilation support to libunwind distribution? Looks like generated headers may be easily eliminated because the generated headers just define several constants to numeric values of offsetof's, while those offsetoff's may be used directly in 'static' (non-generated) headers. As for second issue, maybe an additional command-line switch mat be added to configure that will separate 'buildarch!=targetarch' condition and REMOTE_ONLY setting. Looking forward for replies, Nikita Youshchenko. P.S. Please CC replies to [EMAIL PROTECTED]
