All of lore.kernel.org
 help / color / mirror / Atom feed
* [uml-devel] Problem with UML cross compilation
@ 2003-10-18 18:31 Dan Aloni
  2003-10-19 17:16 ` Jeff Dike
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Aloni @ 2003-10-18 18:31 UTC (permalink / raw)
  To: User-mode Linux Kernel Development

Hi,

Lately I have found a problem with UML and cross compilation. Cross 
compilation means that the architecture that the UML kernel will 
run on (target) is different than the one that it is compiled on 
(host). 

I attempted cross compilation and found that some utils are being
built and run during the build process. These utils were compiled
using the target compiler, which obviously didn't work (all which 
is run on the host needs to be compiled with HOSTCC instead of CC).
Fixing the Makefiles fixes the build procedure from breaking, 
however, the problem is that there is no gaurantee that the UML 
kernel that was built would work.

The reason for the problem is that those utils generate code that
depends on things like offsets inside structs, which obviously 
change between architectures that have different word size. 
It also relies on the target's libc headers, for that purpose.

I've discussed with Jeff about this problem in private E-Mail,
we both thought about solutions but didn't share them yet.

My solution is:

 * Let not build and run those utils on the build host, obviously.
 * All the required versions of the generated code for each of the
   targets will already reside in the tree, the build process will
   automatically pick up the right version and symlink to it.
 * Create a completely standalone program that embeds those utils 
   and generates the code. People who port UML to other 
   architectures will take this program, compile and run it on
   the target and put its output(s) in the tree.
   
The main problem with this method is when and if the target 
changes in such a way that requires those outputs to be 
regenerated. 

I would like your suggestions and opinions about how feasible 
this solution with the 2.4 and 2.6 trees, and if you have
other solutions I'd like to know.

Thanks,

-- 
Dan Aloni
da-x@gmx.net


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [uml-devel] Problem with UML cross compilation
  2003-10-18 18:31 [uml-devel] Problem with UML cross compilation Dan Aloni
@ 2003-10-19 17:16 ` Jeff Dike
  2003-10-19 20:28   ` Dan Aloni
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Dike @ 2003-10-19 17:16 UTC (permalink / raw)
  To: Dan Aloni; +Cc: User-mode Linux Kernel Development

da-x@gmx.net said:
> My solution is: 
> 
>  * Let not build and run those utils on the build host, obviously.
>  * All the required versions of the generated code for each of the
>    targets will already reside in the tree, the build process will
>    automatically pick up the right version and symlink to it.
>  * Create a completely standalone program that embeds those utils 
>    and generates the code. People who port UML to other 
>    architectures will take this program, compile and run it on
>    the target and put its output(s) in the tree.

I was thinking something similar, but differing in the details.  I was thinking
about shipping the generated code in the tree, but non-cross builds would
ignore it and just regenerate it.  Now, I'm thinking it shouldn't be in the
tree, and that cross builds should put it there.

The other difference is that you're proposing a small build process to run
on the target to generate the code.  I'm thinking that they should just copy
the entire kernel tree over, and 'make arch_headers ARCH=um' or something.
Then they would copy the directory containing the generated code back to the
build host.

				Jeff



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [uml-devel] Problem with UML cross compilation
  2003-10-19 17:16 ` Jeff Dike
@ 2003-10-19 20:28   ` Dan Aloni
  2003-10-25  1:34     ` Jeff Dike
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Aloni @ 2003-10-19 20:28 UTC (permalink / raw)
  To: Jeff Dike; +Cc: User-mode Linux Kernel Development

On Sun, Oct 19, 2003 at 01:16:34PM -0400, Jeff Dike wrote:
> da-x@gmx.net said:
> > My solution is: 
> > 
> >  * Let not build and run those utils on the build host, obviously.
> >  * All the required versions of the generated code for each of the
> >    targets will already reside in the tree, the build process will
> >    automatically pick up the right version and symlink to it.
> >  * Create a completely standalone program that embeds those utils 
> >    and generates the code. People who port UML to other 
> >    architectures will take this program, compile and run it on
> >    the target and put its output(s) in the tree.
> 
> I was thinking something similar, but differing in the details.  I was thinking
> about shipping the generated code in the tree, but non-cross builds would
> ignore it and just regenerate it.  Now, I'm thinking it shouldn't be in the
> tree, and that cross builds should put it there.
>
> 
> The other difference is that you're proposing a small build process to run
> on the target to generate the code.  I'm thinking that they should just copy
> the entire kernel tree over, and 'make arch_headers ARCH=um' or something.
> Then they would copy the directory containing the generated code back to the
> build host.
> 

Okay, so you say that a cross build procedure would need a one-time stage
where the person would generate the arch_headers at the host and then manually
copy the generated outputs back to the build host? Sounds difficult, but
people who are attempting cross builds are probably smart enough to understand
this, so it's good.

What sorts of changes are needed to be made in the build system to make 
it possible? I thought of adding $(CROSS_COMPILE) as a prefix to the filenames
of the generated outputs plus rules to generate symlinks that point from 
the normal filenames, in the case where $(CROSS_COMPILE) is activated.

Then, make arch_headers ARCH=um at the target will skip everything but 
running the helpers, packing their outputs to a .tar.gz, and something
like make install_arch_headers ARCH=um CROSS_COMPILE=[..] at the host 
will install those at the right spots in the tree with the given prefix
in CROSS_COMPILE.

Works for you?

-- 
Dan Aloni
da-x@gmx.net


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [uml-devel] Problem with UML cross compilation
  2003-10-19 20:28   ` Dan Aloni
@ 2003-10-25  1:34     ` Jeff Dike
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff Dike @ 2003-10-25  1:34 UTC (permalink / raw)
  To: Dan Aloni; +Cc: User-mode Linux Kernel Development

da-x@gmx.net said:
> Okay, so you say that a cross build procedure would need a one-time
> stage where the person would generate the arch_headers at the host and
> then manually copy the generated outputs back to the build host?
> Sounds difficult, but people who are attempting cross builds are
> probably smart enough to understand this, so it's good. 

Yeah, plus maybe a message at the end saying where the headers are located
and where they need to be copied to.

> Then, make arch_headers ARCH=um at the target will skip everything but
>  running the helpers, packing their outputs to a .tar.gz, and
> something like make install_arch_headers ARCH=um CROSS_COMPILE=[..] at
> the host  will install those at the right spots in the tree with the
> given prefix in CROSS_COMPILE. 

At this point, I'd be happy with something that just generates the headers
and leaves them in the tree somewhere.  Once that works, we can think about
packaging them up nicely for copying over to the build host.

				Jeff



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-10-25  1:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-18 18:31 [uml-devel] Problem with UML cross compilation Dan Aloni
2003-10-19 17:16 ` Jeff Dike
2003-10-19 20:28   ` Dan Aloni
2003-10-25  1:34     ` Jeff Dike

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.