Subject: Dumb Question on Cross-Development

From: "Kevin D. Kissell" <[email-masked]>
Date: Mon, 2 Apr 2001 14:24:00 +0200

I've historically done all of my MIPS/Linux development
native, on Indies, P-5064's, Atlas, and Malta.  But now
that we seem to be in a situation where the latest, 
greatest, and most correct compilers are x86 cross-dev
only, I've cut over to building kernels on my Athlon box.
I'd like to start building apps and benchmarks (not 
necessarily from srpm's).  Plainly, I need a set of
libraries (naive attempts at cross-compilation of
user code with the egcs 1.1.2 compiler results in
complaints about the missing crt1.o), and possibly
some variant include files.  Are these packaged
somewhere, and is there an FAQ/HowTo on how
to set them up?  This may have been handled in 
Ralf's HowTo, but that seems to have disappeared
from the web.

            Regards,

            Kevin K.

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 2 Apr 2001 15:14:25 +0200

On Mon, Apr 02, 2001 at 02:24:00PM +0200, Kevin D. Kissell wrote:

> only.

There is nothing that keeps you from building those compiler as native
compilers also.  Usually I only crosscompile kernels and do all other
work native.

> I've cut over to building kernels on my Athlon box.
> some variant include files.

Which looks like you don't have a glibc package installed.

> Are these packaged somewhere, and is there an FAQ/HowTo on how
> to set them up?

Guess I should occasionally roll an uptodate crosscompiler package ...

> This may have been handled in Ralf's HowTo, but that seems to have
> disappeared from the web.

http://oss.sgi.com/mips/mips-howto.html.  Where are you looking?  It's still
on the web and is also being distributed as part of the LDP project.  Heck,
the HOWTO even seems to ship with a number of Intel distributions, at least
Conectiva 6.0 and Redhat 6.2 seem to include it, even though fairly old
versions.

  Ralf

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Mon, 2 Apr 2001 21:20:44 +0200

> compilers also.  Usually I only crosscompile kernels and do all other

"Let them eat cake".  My Athlon is an order of magnitude
faster than my 4Kc, and several times faster than my
Algor/R5260.  It also has much more memory and a
CD-RW unit for backup, unlike my MIPS boxes.  As
MIPS/Linux becomes more an embedded platform
and less an SGI/DEC legacy platform, people are in
general not going to put up with being forced to buy
old Indy's to do their target application work!

> Which looks like you don't have a glibc package installed.

That's correct.  Because I have the strong suspicion that
RH 7.0 PC rpm is too stupid to put it somewhere useful, and
is far more likely to clobber my native i686 libc unless I give
it the correct incantations.   Hence my question.  And
of course, if it ends up somewhere other than /usr/lib,
presumably I need to tweak mips-linux-gcc to know
where it is.  I'm sure that's documented somewhere,
too, but it would save me several hours if someone had
a description of how to install the full cross environment
on a Linux PC.

> Guess I should occasionally roll an uptodate crosscompiler package ...

If not you, someone certainly needs to.

> http://oss.sgi.com/mips/mips-howto.html.  Where are you looking?

There is no visible link to it on the oss.sgi.com/mips page - then again
there's no visible link to oss.sgi.com/mips from the oss.sgi.com page,
so at least things are consistent.  ;-)  It used to be accessible from the
FAQ that used to be at oss.sgi.com/mips/faq.html, but that document
has be deleted, leaving no forwarding address.  The pointers on Brad
LaRonde's site is even older (remember linux.sgi.com?).

> It's still

That's great.  Now, why can't there be a pointer to it on one of the
pages accessible to someone dropping into oss.sgi.com/mips?

            Regards,

            Kevin K.

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 2 Apr 2001 23:48:50 +0200

> old Indy's to do their target application work!

In not so far future their will be an complete distribution for both
endianesses available (and even kept up to date) containing everything
you need. Debian even now has cross-binutils available for mipsel and
just a couple of mails would be required to come with cross-binutils for
mips too. Compiling a cross-compiler from the debian gcc source package
is described somewhere (Just a matter of a single line imho)

Cross-compilation is IMHO so broken when it comes to userspace
than noone really thinking of having something reusable would
consider this. It all ends beeing a really ugly hack.

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: Thiemo Seufer <[email-masked]>
Date: Mon, 2 Apr 2001 23:56:19 +0200

Kevin D. Kissell wrote:
[snip]
>a description of how to install the full cross environment

There's even a script by Keith Weselowski to do that, see e.g.
ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/ 

[snip]
>LaRonde's site is even older (remember linux.sgi.com?).

http://www.linux-mips.org/ has a good link page (if it isn't down).

Thiemo

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Tue, 3 Apr 2001 00:22:48 +0200

> > As MIPS/Linux becomes more an embedded platform
> > old Indys to do their target application work!
> 

I'm not sure exactly what you mean here.  That no one would
consider using your Debian cross environment?  That no one
would consider doing cross-development?   What part of it 
seems to you to be a show-stopper?

            Kevin K.

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 3 Apr 2001 00:30:59 +0200

> consider using your Debian cross environment?  That no one

I am not building cross, i am not building the debian cross
toolchain. Just for completeness.

> seems to you to be a show-stopper?

A major problem get the thing in which the configure try to 
begin to build executables and guess on the behaviour of the
OS to run on. This ends to be a hack and reminds me on
"pre gnu configure" times where one had to deal
with hundrets of "config.h" or "os.h" files. 

If you are going to use anything like a package format
might it be "rpm" or "deb" the dependencies tend to be
utterly broken as the dependcies are guessed by stuff like
"ldd" output and friends.

If you have a 90Meg source tarball and build a 4Meg Ramdisk
for a Nino out of it. Fine. 

Flo

---

From: "Steven J. Hill" <[email-masked]>
Date: Mon, 02 Apr 2001 18:41:10 -0500

Greetings.

I would like to officially announce patches to binutils and
friends that fix the mismatch of symbols in kernel modules
compiled for MIPS architectures that produced messages like
these below:

dummy.o: local symbol gcc2_compiled. with index 10 exceeds local_symtab_size 10
dummy.o: local symbol __gnu_compiled_c with index 11 exceeds local_symtab_size
10
dummy.o: local symbol __module_kernel_version with index 12 exceeds
local_symtab_size 10

They are available at (ftp://ftp.cotw.com/pub/linux/nino/toolchain/)
and are made against the official binutils/gcc/glibc straight out
of CVS snapshots made on 03292001. The most important patch is of
course the one made to binutils. The patch to GCC fixes the error
that some people are seeing with a missing 'atexit' symbol when
cross compiling glibc. You must update to GCC out of CVS in order
to fix this issue AFAIK. The GCC patch was done by HJ Lu and not
myself. This patch has been tested for a 32-bit toolchain configured
for little-endian. It currently does not compile for big endian and
64-bit architectures. The reason for this is what I would like to
discuss with everyone.

Without the binutils patch, all binaries compiled for MIPS/Linux
will be IRIX flavored which was the whole problem. I would now
like to make 'elf[32|64]_trad[little|big]mips' be the official
targets instead of 'elf[32|64]_[little|big]mips' which is what
things currently are. This means changing of linker scripts in
GLIBC as well as the Linux kernel (as far as I can tell). I would
like to propose the any 'mips*-*-linux-gnu' and 'mips*el-*linux-gnu'
targets be pure traditional targets WITHOUT any emulated IRIX targets
which are the current 'elf[32|64]_[little|big]mips' targets. Please
provide feedback, comments, etc. with justification. Thanks.

-Steve

  I shall now put on asbestos armor and grab a LART.

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 3 Apr 2001 04:17:40 +0200

Steven J. Hill wrote:
[snip]
>will be IRIX flavored which was the whole problem.

Please may You elaborate about this? AFAICS, the IRIX flavour
can't be a problem by itself.

>I would now

Changing the MIPS/Linux ABI to circumvent a toolchain bug seems
to be a bit extremistic. Am I missing some important details?

Thiemo

---

From: Joe deBlaquiere <[email-masked]>
Date: Mon, 02 Apr 2001 21:57:15 -0500

> with hundrets of "config.h" or "os.h" files. 

Perfect it is not, but it's not nearly _that_ bad either. I would say 40% of the RPMs I've tried will configure out of the box for a cross build. Another 40% or so require a few "export ac_cv_sizeof_long=4" kind of settings to configure for a cross build. The remaining 20% are painful.

Most of the package maintainers have been very receptive to configuration help for cross build environments. Of course some seem to have died or gone to work for Microsoft (is there a measurable difference?). 

> "ldd" output and friends.

You can of course specify the target to rpm when unpacking the source... 

> for a Nino out of it. Fine. 

Of course you could compile the packages natively on the Nino on a NFS mount over serial-ppp... ;)

-- 
Joe

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 3 Apr 2001 08:11:19 +0200 (MET DST)

> "ldd" output and friends.

So if you would have a `cross ldd', things would be better?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Apr 2001 11:50:48 +0200 (MET DST)

> with hundrets of "config.h" or "os.h" files. 

 But autoconf supports it properly.  It doesn't try to make and run an
executable in the case of cross-compiling and also prints a unambiguous
warning in the case no cross-compilation default (usually the worst case
assumption) was provided.

> "ldd" output and friends.

 Well, my rpm binaries find dependencies correctly (go, figure! -- all
binary packages I make available have correct dependencies).  Using ldd
for this purpose is broken, indeed.  What I do is using readelf, if
available, and falling back to objdump, if not (as in the case of old
binutils).  Readelf is better as it's host-independent.  Objdump might not
work if a host is of different "bitness" than a target.  It might even not
work at all if a host is non-ELF.  Ldd is used as well, I admit, but only
for a.out binaries -- I don't know of any other way for finding a.out
shared library dependencies.  It doesn't really matter here, though. 

 Check my rpm packages for a patch -- I haven't submitted it yet, because
rpm 3.0 was already obsolete when I created it.  I'll check if it applies
to 4.0 cleanly.  If so, I'll submit it ASAP, otherwise don't hold your
breath. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Apr 2001 11:26:11 +0200 (MET DST)

> consider this. It all ends beeing a really ugly hack.

 I disagree.  It's not that userland cross-compilation is broken.  It's
just the matter of certain programmers who do not care to write
scripts/Makefiles to support cross-development portably.  They might even
not realize there exists such a feature as cross-compilation.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Apr 2001 11:52:18 +0200 (MET DST)

> So if you would have a `cross ldd', things would be better?

 Everything is already in place -- readelf might be used, for example. 
See my other letter.

---

From: "Steven J. Hill" <[email-masked]>
Date: Tue, 03 Apr 2001 10:46:49 -0500

> can't be a problem by itself.
Yes, it is. Take a look at the IRIX_COMPAT macro in 'bfd/elf32-mips.c'
which checks to see what type (flavor) of binary you are using. Before
the patch all elf32-mips targets used the IRIX way of determining a if
a symbol was global or not (see function that determines this at around
line 2301 in 'bfd/elf32-mips.c'). By using IRIX flavored symbols, LOCAL
and GLOBAL symbols are not sorted correctly and we get the problems with
symbols being out of order in Linux kernel modules. With the patch and
using 'elfXX-tradXXmips' as the new output targets, we sort local and
global symbols correctly.

> to be a bit extremistic. Am I missing some important details?
Yes, you are missing a few things, but I attribute that to my poor
communications in my first email. My point is that the IRIX_COMPAT
and SGI_COMPAT macros are used to check what type of target we are
using in order to sort local and global symbols properly and many
other places in the BFD library to creat binaries for Linux or for
IRIX. The way (that I think) this should be done is to use the
target 'elfXX-tradXXmips' and make that the default target utilized
for MIPS-Linux targets. This is the decision that I wanted everyone's
input on. I hope I explained this better. If not, ask more questions
and I will try again. Cheers.

-Steve

---

From: Jun Sun <[email-masked]>
Date: Tue, 03 Apr 2001 10:34:55 -0700

> with hundrets of "config.h" or "os.h" files.

While it is a pain for some packages, it is actually not too bad for most of
them.  I think we (mvista) are rolling out cross-compiled 250+ packages for 5
major CPU architectures and 21 sub-architectures - where most of them are
based on debian sources. :-)

> "ldd" output and friends.

There are some tools which make it work right.  mvista has one.  I think
Merceij has one too.
 
Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Apr 2001 18:59:41 +0200 (MET DST)

> provide feedback, comments, etc. with justification. Thanks.

 I've reviewed the patch briefly and it appears fine in principle.  I'm
unsure about the target naming.  Since the MIPS ABI (which Linux tries to
conform to) is defined by SVR4 and IRIX defines incompatible changes, I
believe the the target SVR4 and Linux uses should be named
'elf[32|64]_bigmips' (and 'elf[32|64]_littlemips' for consistency, even
though SVR4 doesn't really define it) and the IRIX target should be named
something like 'elf[32|64]_irixbigmips'.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Apr 2001 10:26:09 +0200

> to be a bit extremistic. Am I missing some important details?

IRIX ELF orders the symbol table of object files in a way that violates
the ABI.  Worse, these IRIX specialities are not documented anywhere.

Changing to ABI ELF only makes them look as they're supposed to ...

  Ralf

---

From: "Steven J. Hill" <[email-masked]>
Date: Tue, 03 Apr 2001 11:56:05 -0500

> something like 'elf[32|64]_irixbigmips'.
Well, the traditional MIPS targets are BEING used for SVR4....observe:

ld/configure.tgt:286:    mips*-*-sysv4*) targ_emul=elf32btsmip ;;
 gas/conlfigure:2499:    mips-*-sysv4*MP*) fmt=elf em=tmips ;;
   bfd/config.bd:646:    mips*-*-sysv4*) targ_defvec=bfd_elf32_tradbigmips_vec

I think that using 'elf[32|64]_[big|little]mips' for Linux and SVR4 would
be a bad idea and would confuse things. Note that in 'bfd/elf32-mips.c' the
IRIX_COMPAT macro is hinged around checking for a traditional MIPS target
and will proceed to build IRIX flavored binaries if we are not using a
traditional target. The names for IRIX targets ARE currently
'elf[32|64]_[big|little]mips'. Changing binutils so that these targets will
now be for Linux/SVR4 and create ANOTHER target 'elf[32|64]_irixbigmips'
will add more bloat to binutils and be confusing to people. SVR4 already
uses traditional MIPS targets and Linux should as well. My vote is still
to make Linux use the traditional MIPS targets. It will be difficult to
convince me otherwise right now :).

-Steve

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Apr 2001 17:10:05 +0200

> not realize there exists such a feature as cross-compilation. 

Brokeness starts with autoconf's AC_CHECK_SIZEOF macro implementation
which is used frequently throughout a whole distribution and there are
so many test that require actually execution of code on the target that
fix a whole distribution for crosscompilation and keeping it uptodate
is seriously double-plus un-fun.

  Ralf

---

From: "Steven J. Hill" <[email-masked]>
Date: Tue, 03 Apr 2001 12:27:18 -0500

> Changing to ABI ELF only makes them look as they're supposed to ...
Thanks for backing me up. Also, after discussion with Ralf on IRC,
the decision has been made to except the patch as the fix. There will
not be an additional target 'irix[little|big]mips' added. Linux and
SVR4 will utilize 'trad[little|big]mips' and IRIX and other targets
will use '[little|big]mips'. Also, when building for Linux targets,
the 'elf[32|64]_[little|big]mips' targets (IRIX) will not be built as
emulation targets.

-Steve

---

From: Andreas Jaeger <[email-masked]>
Date: 04 Apr 2001 07:57:22 +0200

> the 'elf[32|64]_[little|big]mips' targets (IRIX) will not be built as

Please send the patch to [email-masked] and get it
integrated into the official sources!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs [email-masked]
   private [email-masked]
    http://www.suse.de/~aj

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 4 Apr 2001 12:02:11 +0200

On Tue, Apr 03, 2001 at 10:34:55AM -0700, Jun Sun wrote:
> While it is a pain for some packages, it is actually not too bad for
> most of them.  I think we (mvista) are rolling out cross-compiled 250+
> packages for 5 major CPU architectures and 21 sub-architectures - where
> most of them are based on debian sources. :-)

We already had the discussion on parts of that implementation. Honestly - 
I dont like the stuff - Rolling out mips packages as "noarch" is
simply broken - And the argument that one would want to install
it on a i386 nfs root is simply an excuse for a broken rpm or missing
installer.

Flo

---

From: Geert Uytterhoeven <[email-masked]>
Date: Wed, 4 Apr 2001 12:15:59 +0200 (MET DST)

> it on a i386 nfs root is simply an excuse for a broken rpm or missing

What about modifying dpkg so it can install the lib and include parts of
non-native packages for arch $ARCH in /usr/$ARCH-linux/? Thay way you can
easily install *-dev packages for cross-development.

Gr{oetje,eeting}s,

						Geert

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 4 Apr 2001 13:02:26 +0200

> easily install *-dev packages for cross-development.

Even with rpm or dpkg different arch packages can be extracted and installed.
On rpm you could do it with "rpm2cpio" or with dpkg you could do it
with "ar x <*.deb>" and then extract the data.tar.gz

Flo

---

From: Alan Cox <[email-masked]>
Date: Wed, 4 Apr 2001 12:22:16 +0100 (BST)

> it on a i386 nfs root is simply an excuse for a broken rpm or missing

Or a flawed packaging tool. RPM allows you to force noarch and you can use it
to get around this precise problem. Its also useful when you want to force
an x86 package onto an Alpha with em86.

I find it hard to believe dpkg lacks such a feature.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 4 Apr 2001 13:35:10 +0200 (MET DST)

>    bfd/config.bd:646:    mips*-*-sysv4*) targ_defvec=bfd_elf32_tradbigmips_vec

 Yep, I know.

> convince me otherwise right now :).

 Note that 'elf32_tradbigmips' is quite a recent invention.  I was
thinking of making SVR4 use 'elf32_bigmips', as well, as this is *THE*
MIPS ELF target and others are variations.  Getting it otherwise seems
backwards.  It's a minor purity issue anyway, so even though I like my
idea better I don't absolutely insist on it. 

 Thanks for getting the work off from me, BTW.  I was going to make the
fix for quite some time now, but given my recent time constraints I
couldn't assure any reasonable deadline for it. :-(

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 4 Apr 2001 14:06:22 +0200 (MET DST)

> is seriously double-plus un-fun.

 Well, I can't see any other way to check sizeof of a type.  OTOH, I
haven't seen many programs that call AC_CHECK_SIZEOF on unions or structs
-- that's where the real problem might be as predicting member alignment
is not always easy (especially for "evil" objects -- but if such ones
exist the actual problem is a badly written program begging for a
rewrite).  There is no need to check sizeof for simple types -- ISO C
<stdint.h> types might be used if a desired number of bits in a type is
needed with a fallback to AC_CHECK_SIZEOF for legacy hosts only (which we
don't care that much of).  In short, the macro shouldn't really be used in
most cases. 

 I sustain the problem does not lie in the tool but in its usage.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 4 Apr 2001 14:15:41 +0200 (MET DST)

> easily install *-dev packages for cross-development.

 I'm not sure if that actually solves the problem.  I think
cross-compilation libraries need to be built specifically for this purpose
as bits might be different, such as in the case of
/usr/mipsel-linux/lib/libc.so, which has to be different from the
mipsel-linux native /usr/lib/libc.so.  Cross-compilation libraries might
be built as noarch packages as they are actually independent from the
build system they are installed on.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 4 Apr 2001 14:29:50 +0200

On Wed, Apr 04, 2001 at 02:06:22PM +0200, Maciej W. Rozycki wrote:
> Date: Wed, 4 Apr 2001 14:06:22 +0200 (MET DST)
> From: "Maciej W. Rozycki" <[email-masked]>
> To: Ralf Baechle <[email-masked]>
> cc: Florian Lohoff <[email-masked]>, "Kevin D. Kissell" <[email-masked]>,
>         "MIPS/Linux List (SGI)" <[email-masked]>
> Subject: Re: Dumb Question on Cross-Development
> 

stdint.h isn't available everywhere.  Aside of that I won't object ...

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 4 Apr 2001 15:39:42 +0200 (MET DST)

> stdint.h isn't available everywhere.  Aside of that I won't object ...

 That's why I wrote of legacy hosts.  The AC_CHECK_HEADERS and
AC_CHECK_TYPE macros are cross-compilation-safe and they are all that
modern hosts need.  For other hosts AC_CHECK_SIZEOF might be used to find
generic types suitable for ISO C definitions, which might be problematic
for cross-compilation, though.  Still this applies to non-gcc
cross-compilers only, which are not that common, AFAIK.

---

From: Carsten Langgaard <[email-masked]>
Date: Wed, 04 Apr 2001 16:23:26 +0200

I would like to join the fun of cross-compiling RPMs.
What I have done so far with userland is simply to collect precompiled
binaries, and only compiled less than a handful of RPMs natively.
So where do I start ?
I have started out getting the tarball
(ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/cross-all-20010303.tar)
and compiled everything on a linux hosted PC, it worked fine, though I had
to upgrade from redhat6.1 to redhat7.0. Nice work whoever put this together.

Now I would like to start cross compile SRPMs (let say redhat7.0).
What do I need to do to make the SRPMS cross compile ?
Could someone please get me booted or is there an howto somewhere ?
I realize it probably gonna be hard work, but I like to join the fun, at
least so I have an idea what exactly the problems are, and hopefully with
time I can contribute in the bug fixing.

/Carsten

--
_    _ ____  ___   Carsten Langgaard   Mailto:[email-masked]
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

---

From: "Jay Carlson" <[email-masked]>
Date: Wed, 4 Apr 2001 11:17:39 -0400

> Perfect it is not, but it's not nearly _that_ bad either. I would
> say 40% of the RPMs I've tried will configure out of the box for
> a cross build. Another 40% or so require a few "export
> ac_cv_sizeof_long=4" kind of settings to configure for a cross
> build. The remaining 20% are painful.

Yeah, and it's not so bad once you start building up a config.site file you
can reuse across builds.  I got this idea from the debian dpkg-cross
package.  For people who aren't debian-y, the idea is that you set
CONFIG_SITE to point at a file like
http://www.csee.umbc.edu/~acedil1/agenda/files/agenda-config.site and run
configure as normal.  (I don't think I like that particular file but it
should give you ideas.)

BTW dpkg-cross comes with a tool that does ldd via grepping through objdump
output.

Jay

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 4 Apr 2001 17:37:15 +0200 (MET DST)

> What do I need to do to make the SRPMS cross compile ?

 Spec files need to be written appropriately for cross-compilation to be
supported as you need to override the compiler used (and possibly other
tools) and configure scripts need to be passed a host system name.  Also
depending on the cluefulness of a given maintainer/team, packages might be
easy or difficult to cross-compile -- heavy patching is required in some
cases. 

 For the way I am using RPM to cross-compile you might visit my FTP site
at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/' (mirrored at
'ftp://ftp.rfc822.org/pub/mirror/ftp.ds2.pg.gda.pl/pub/macro' -- thanks,
Flo).  There are source and binary packages as well as configuration files
I use.  Read the READMEs and look at a few spec files and everything
should be clear.  Many of the *.mipsel.rpm packages available there were
cross-built -- you may verify it with `rpm -qip': "macro" is my i386-linux
system, while "3maxp" is my mipsel-linux one (still no i386-linux
cross-compiler on my mipsel-linux system, sigh... :-( ). 

 You need to build cross-binutils, cross-gcc and cross-glibc to start. 
I've already written and sent a detailed description on cross-gcc
bootstrapping here.  I'm not sure if the list is archived, or not.  If
not, I may dig through my mail archives and send it again. 

 If you have any specific questions, don't hesitate to ask me.

  Maciej

---

From: Thiemo Seufer <[email-masked]>
Date: Wed, 4 Apr 2001 18:12:42 +0200

>the ABI.  Worse, these IRIX specialities are not documented anywhere.

That would be ok, but, according to the source, there are also
different maximum offsets for ELF_MIPS_GP_OFFSET, which is hardcoded
to IRIX standard in gas, and different section namings like
.MIPS.options vs. .options. 

>Changing to ABI ELF only makes them look as they're supposed to ...

At least the section naming is specified different.

Thiemo

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 4 Apr 2001 18:05:38 +0200

> I find it hard to believe dpkg lacks such a feature.

Just had a look - One can install them 

dpkg --force-architecture -i --root=/nfsexport

But i was arguing against compiling the packages as "noarch" not installing
them with noarch.

Flo

---

From: Jun Sun <[email-masked]>
Date: Wed, 04 Apr 2001 11:06:28 -0700

Florian Lohoff wrote:
> simply broken - 

That part is fixed in the coming BIG release.  

Honestly, I am not an expert on packeging.  It is basically somebody else's
job here at mvista.  Nevertheless, the point is we cross-compiled it. :-)

Like I said, there are times I do wish and often have to compile natively (the
one that comes to mind is mp3 player).  Due to the embedded constraints, we
pretty much *have* to do cross-compiling for at least some customers on some
systems.  So the argument is that since we are already doing it any way, we
might as well do it all the way.

BTW, we actually do have native compiling as well - probably for something
like mp3 player.  

(Flo, you really cannot beat the argument of having both. :-0)

Jun

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 4 Apr 2001 20:45:50 +0200

> (Flo, you really cannot beat the argument of having both. :-0)

I dont want to argue very much - I think both ways do have advantages.
I am coming the distribution way and i am used to something
like rpm --rebuild although i am going the debian way.

There is stuff like autobuilder, autoconf, dependencies etc which
give a major headache on cross-compiling. For all the embedded archs
i do think there is a way of having a "workstation" like machine
available for compiling native and having a distribution.

Flo

---

From: Carsten Langgaard <[email-masked]>
Date: Thu, 05 Apr 2001 12:54:44 +0200

Thanks a lot.
I have question about installation of the SRPMs, though.
How can I relocate the packages, so they don't need to reside under
/usr/src/redhat/ ?

/Carsten

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 5 Apr 2001 14:05:23 +0200 (MET DST)

> How can I relocate the packages, so they don't need to reside under

 RPM uses the value of the _topdir macro as the root for source handling. 
You may override the default from /usr/lib/rpm/macros in several places --
see the macrofiles tag in /usr/lib/rpm/rpmrc.  I have it overriden to
/home/macro/src/redhat in the configuration files I made available at my
FTP site.

---

From: Carsten Langgaard <[email-masked]>
Date: Thu, 05 Apr 2001 16:35:53 +0200

I tried the following:
rpm -ba --rcfile .rpmrc-mipsel SPECS/mipsel-linux-binutils-2.10.91-2.spec

but it fails with
Architecture is excluded: mipsel

/Carsten

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 5 Apr 2001 18:50:27 +0200 (MET DST)

> Architecture is excluded: mipsel

 All packages which names start with <cpu>-<os> are cross-development
packages.  Mipsel-linux-binutils is a package providing binutils targeted
to mipsel.  You cannot build the package for the mipsel-linux host (which
the .rpmrc-mipsel configuration file sets up) as this wouldn't be a
cross-development package.  For this package to build just run: 

$ rpm -ba SPECS/mipsel-linux-binutils-2.10.91-2.spec

 You can only change the host system with .rpmrc-* files.  The target
system is hardcoded in cross-development packages and the build system is
implied.

 I hope this helps.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 5 Apr 2001 14:32:39 +0200

> How can I relocate the packages, so they don't need to reside under

That patch is compiled into rpm and a number of the config files of rpm
in /usr/lib/rpm which are generated are rpm build time.  So changing
isn't that easy, you'll have to rebuild rpm configured with a different
pathname, I think.

  Ralf

---

From: Wichert Akkerman <[email-masked]>
Date: Fri, 6 Apr 2001 11:37:49 +0200

> "ldd" output and friends.

I have code for dpkg that makes it only use objdump which
should work fine.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| [email-masked]                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 6 Apr 2001 17:30:40 +0200 (MET DST)

> isn't that easy, you'll have to rebuild rpm configured with a different

 The RPM config files are processed first, but later definitions override
earlier ones.  The order is: /usr/lib/rpm/rpmrc, /etc/rpmrc, ~/.rpmrc. 
The path for macro files is set in /usr/lib/rpm/rpmrc -- if the default
one does not suit you, you may override it in any of the above rc files.

---

From: Joe deBlaquiere <[email-masked]>
Date: Sat, 07 Apr 2001 10:29:01 -0500

> cross-compilers only, which are not that common, AFAIK.

You might call it a hack, but it makes life easy if you do something like:

export ac_cv_sizeof_short=2
export ac_cv_sizeof_int=4
export ac_cv_sizeof_long=4

sh ./configure --target=$CONFIG_TARGET --host=$CONFIG_HOST 
--prefix=$CONFIG_PREFIX --exec-prefix=$CONFIG_EXECPR

This will short circuit a "broken" configure trying to execute programs 
for this kind of thing. If configure doesn't care about sizeof_int, then 
this definition is silently ignored...

-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 9 Apr 2001 14:16:53 +0200 (MET DST)

> this definition is silently ignored...

 If you look at my RPM packages, you'll see I'm already doing this.  I've
already thought of making global cross-compilation configuration files for
each host containing appropriate definitions.  I'm not sure how to
integrate it with RPM, yet (the macro definition file is a good
candidate).  I didn't make any progress due to a low priority of this
task.