libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libunwind] Trouble cross-compiling libunwind


From: Nikita V. Youshchenko
Subject: [libunwind] Trouble cross-compiling libunwind
Date: Thu, 30 Dec 2004 00:06:24 +0300
User-agent: KMail/1.7.1

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 address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]