Dumb Question on Cross-Development

Dumb Question on Cross-Development

[Kevin D. Kissell]

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.

Dumb Question on Cross-Development

[Kevin D. Kissell]

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.

Re: Dumb Question on Cross-Development

[Ralf Baechle]

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

> 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.

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.
> 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.

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

Re: Dumb Question on Cross-Development

[Ralf Baechle]

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

> 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.

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.
> 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.

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

Re: Dumb Question on Cross-Development

[Kevin D. Kissell]

> > 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.
>
> 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.

"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!

> > 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.
>
> 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.

> > 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 ...

If not you, someone certainly needs to.

> > 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?

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
> 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.

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.

Re: Dumb Question on Cross-Development

[Kevin D. Kissell]

> > 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.
>
> 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.

"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!

> > 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.
>
> 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.

> > 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 ...

If not you, someone certainly needs to.

> > 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?

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
> 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.

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.

Re: Dumb Question on Cross-Development

[Florian Lohoff]

On Mon, Apr 02, 2001 at 09:20:44PM +0200, Kevin D. Kissell wrote:

> "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!

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                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Dumb Question on Cross-Development

[Kevin D. Kissell]

> > 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 Indys 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.

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.

Re: Dumb Question on Cross-Development

[Kevin D. Kissell]

> > 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 Indys 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.

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.

Re: Dumb Question on Cross-Development

[Florian Lohoff]

On Tue, Apr 03, 2001 at 12:22:48AM +0200, Kevin D. Kissell wrote:
> 
> I'm not sure exactly what you mean here.  That no one would
> 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.

> would consider doing cross-development?   What part of it 
> 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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Dumb Question on Cross-Development

[Joe deBlaquiere]

Florian Lohoff wrote:

> On Tue, Apr 03, 2001 at 12:22:48AM +0200, Kevin D. Kissell wrote:
> 
>> I'm not sure exactly what you mean here.  That no one would
>> 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.
> 
> 
>> would consider doing cross-development?   What part of it 
>> 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. 
> 

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?). 

> 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.
> 

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

> If you have a 90Meg source tarball and build a 4Meg Ramdisk
> 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

RE: Dumb Question on Cross-Development

[Jay Carlson]

> 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

RE: Dumb Question on Cross-Development

[Jay Carlson]

> 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

Re: Dumb Question on Cross-Development

[Geert Uytterhoeven]

On Tue, 3 Apr 2001, Florian Lohoff wrote:
> On Tue, Apr 03, 2001 at 12:22:48AM +0200, Kevin D. Kissell wrote:
> > would consider doing cross-development?   What part of it 
> > 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.

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)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Tue, 3 Apr 2001, Geert Uytterhoeven wrote:

> 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Tue, 3 Apr 2001, Florian Lohoff wrote:

> 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. 

 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.

> 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.

 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Jun Sun]

Florian Lohoff wrote:
> 
> On Tue, Apr 03, 2001 at 12:22:48AM +0200, Kevin D. Kissell wrote:
> >
> > I'm not sure exactly what you mean here.  That no one would
> > 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.
> 
> > would consider doing cross-development?   What part of it
> > 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.
> 

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. :-)

> 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.
>

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

Re: Dumb Question on Cross-Development

[Florian Lohoff]

On Tue, Apr 03, 2001 at 10:34:55AM -0700, Jun Sun wrote:
> > 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.
> 
> 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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Dumb Question on Cross-Development

[Geert Uytterhoeven]

On Wed, 4 Apr 2001, Florian Lohoff wrote:
> On Tue, Apr 03, 2001 at 10:34:55AM -0700, Jun Sun wrote:
> > > 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.
> > 
> > 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.

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

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: Dumb Question on Cross-Development

[Florian Lohoff]

On Wed, Apr 04, 2001 at 12:15:59PM +0200, Geert Uytterhoeven wrote:
> > 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.
> 
> 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.

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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Wed, 4 Apr 2001, Geert Uytterhoeven wrote:

> 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.

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Alan Cox]

> 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.

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.

Re: Dumb Question on Cross-Development

[Alan Cox]

> 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.

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.

Re: Dumb Question on Cross-Development

[Florian Lohoff]

On Wed, Apr 04, 2001 at 12:22:16PM +0100, Alan Cox wrote:
> 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.
> 

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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Dumb Question on Cross-Development

[Jun Sun]

Florian Lohoff wrote:
> 
> On Tue, Apr 03, 2001 at 10:34:55AM -0700, Jun Sun wrote:
> > > 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.
> >
> > 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 - 

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

Re: Dumb Question on Cross-Development

[Florian Lohoff]

On Wed, Apr 04, 2001 at 11:06:28AM -0700, Jun Sun wrote:
> 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)

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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Dumb Question on Cross-Development

[Wichert Akkerman]

Previously Florian Lohoff wrote:
> 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.

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     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Mon, 2 Apr 2001, Florian Lohoff wrote:

> 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.

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Ralf Baechle]

On Tue, Apr 03, 2001 at 11:26:11AM +0200, Maciej W. Rozycki wrote:

> > 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.
> 
>  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. 

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

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Tue, 3 Apr 2001, Ralf Baechle wrote:

> 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.

 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Ralf Baechle]

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" <macro@ds2.pg.gda.pl>
> To: Ralf Baechle <ralf@oss.sgi.com>
> cc: Florian Lohoff <flo@rfc822.org>, "Kevin D. Kissell" <kevink@mips.com>,
>         "MIPS/Linux List (SGI)" <linux-mips@oss.sgi.com>
> Subject: Re: Dumb Question on Cross-Development
> 
> On Tue, 3 Apr 2001, Ralf Baechle wrote:
> 
> > 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.
> 
>  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.

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

  Ralf

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Wed, 4 Apr 2001, Ralf Baechle wrote:

> 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Carsten Langgaard]

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


"Maciej W. Rozycki" wrote:

> On Wed, 4 Apr 2001, Ralf Baechle wrote:
>
> > 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.
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Wed, 4 Apr 2001, Carsten Langgaard wrote:

> 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 ?

 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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Carsten Langgaard]

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

"Maciej W. Rozycki" wrote:

> On Wed, 4 Apr 2001, Carsten Langgaard wrote:
>
> > 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 ?
>
>  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
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Thu, 5 Apr 2001, Carsten Langgaard wrote:

> 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/ ?

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Carsten Langgaard]

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

"Maciej W. Rozycki" wrote:

> On Thu, 5 Apr 2001, Carsten Langgaard wrote:
>
> > 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/ ?
>
>  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.
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Thu, 5 Apr 2001, Carsten Langgaard wrote:

> 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

 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Ralf Baechle]

On Thu, Apr 05, 2001 at 12:54:44PM +0200, Carsten Langgaard wrote:

> 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/ ?

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

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Thu, 5 Apr 2001, Ralf Baechle wrote:

> 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.

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Joe deBlaquiere]

Maciej W. Rozycki wrote:

> On Wed, 4 Apr 2001, Ralf Baechle wrote:
> 
> 
>> 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.

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

Re: Dumb Question on Cross-Development

[Maciej W. Rozycki]

On Sat, 7 Apr 2001, Joe deBlaquiere wrote:

> 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...

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Dumb Question on Cross-Development

[Thiemo Seufer]

Kevin D. Kissell wrote:
[snip]
>> 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.

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]
>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?).

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


Thiemo

Binutils fixed to deal with 'insmod' issue and discussion...

[Steven J. Hill]

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

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Thiemo Seufer]

Steven J. Hill wrote:
[snip]
>Without the binutils patch, all binaries compiled for MIPS/Linux
>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
>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.

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


Thiemo

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Ralf Baechle]

On Tue, Apr 03, 2001 at 04:17:40AM +0200, Thiemo Seufer wrote:

> >Without the binutils patch, all binaries compiled for MIPS/Linux
> >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.

> Changing the MIPS/Linux ABI to circumvent a toolchain bug seems
> 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

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Steven J. Hill]

Ralf Baechle wrote:
> 
> 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 ...
> 
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

-- 
 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

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Andreas Jaeger]

"Steven J. Hill" <sjhill@cotw.com> writes:

> Ralf Baechle wrote:
> > 
> > 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 ...
> > 
> 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.

Please send the patch to binutils@sources.redhat.com and get it
integrated into the official sources!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Thiemo Seufer]

Ralf Baechle wrote:
>On Tue, Apr 03, 2001 at 04:17:40AM +0200, Thiemo Seufer wrote:
>
>> >Without the binutils patch, all binaries compiled for MIPS/Linux
>> >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.
>
>> Changing the MIPS/Linux ABI to circumvent a toolchain bug seems
>> 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.

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

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Steven J. Hill]

Thiemo Seufer wrote:
> 
> >Without the binutils patch, all binaries compiled for MIPS/Linux
> >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.
> 
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.

> Changing the MIPS/Linux ABI to circumvent a toolchain bug seems
> 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

-- 
 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

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Maciej W. Rozycki]

On Mon, 2 Apr 2001, Steven J. Hill wrote:

> 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.

 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'.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Steven J. Hill]

"Maciej W. Rozycki" wrote:
> 
>  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'.
> 
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

-- 
 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

Re: Binutils fixed to deal with 'insmod' issue and discussion...

[Maciej W. Rozycki]

On Tue, 3 Apr 2001, Steven J. Hill wrote:

> 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

 Yep, I know.

> 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 :).

 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. :-(

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +