For the last few days, I've been writing posts that advocate cross compiling packages for Fedora. Some appear skeptical of this approach, so I want to share a bit more of where I am coming from.
Inside Red Hat, my group (GES) creates custom compilers and embedded Linux systems for our customers. We have done this for many years, using various upstream sources, building natively and with cross tools. For the last few years, we have used either RHEL or Fedora as our upstream source base.
Along the way, we stopped compiling our packages on the target hardware. It was just too slow, or didn't have enough RAM, or there weren't enough of them, or real hardware didn't even exist yet. Regardless, there were always less expensive commodity PC CPU cycles to be had.
We have gone through several generations of build methods, trying new systems, modifying them, trying to get an optimal environment for relatively fast, cyclic builds. Much of this time has been consumed by making packages build with rpm and using a cross compiler to do the work. We've had some success here, though not without considerable effort. We spend quite a bit of time chasing Fedora development.
We cross-compile every package that we build(a subset of packages from the aforementioned distributions). There is no simulator or native hardware employed. Judging by messages on the list, other people and businesses are working toward a similar goal, though each with their own infrastructure and method. All the messages about adding arm to Fedora are very exciting! Everybody who has their own private way of getting Fedora built for arm could instead contribute toward the common goal.
I would like to see cross compilation become a standard method in Fedora. It scales where native builds don't. There might be faster arm chips these days, but lets not forget all the underpowered embedded CPUs and costly systems like s390. Bootstrapping is simplified. People without access to hardware can work on build problems (Simulators are good for this too).
What are the hurdles to adoption? Broadly, they break down into technical and social:
Technical: There must be cross compilers before we can cross compile. The build system must be enhanced to support cross compilation. Finally, packages must be modified to support cross compilation.
Social: As a volunteer effort, it is unreasonable to expect existing package maintainers to do the work necessary to support cross compilation. There must be people to take on that responsibility and work with upstream and package maintainers to integrate the necessary changes.
I don't have fast and easy answers to all of the above, but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think?
On 6/7/07, Brendan Conoboy blc@redhat.com wrote:
I don't have fast and easy answers to all of the above, but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think?
I think that would be wonderful to have Fedora (or a significant subset of it) available for my Linksys NSLU2, since it's the only way to resurrect it from the drawer I buried it after I had enough of the unslung (debian based) firmware...
On 06/07/2007 11:42 PM, Gianluca Sforna wrote:
On 6/7/07, Brendan Conoboy blc@redhat.com wrote:
I don't have fast and easy answers to all of the above, but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think?
I think that would be wonderful to have Fedora (or a significant subset of it) available for my Linksys NSLU2, since it's the only way to resurrect it from the drawer I buried it after I had enough of the unslung (debian based) firmware...
Seems there are a lot of of people who want to run Fedora on everything that has some CPU. I wonder when the first watch and coffee machine comes out; Running Fedora of course. :-)
Just joking. If there would be a Fedora port to NSLU, I would think about buying such a piece and replacing my old Pentium box. :-)
-of
On Thu, Jun 07, 2007 at 11:42:42PM +0200, Gianluca Sforna wrote:
I don't have fast and easy answers to all of the above, but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think?
I think that would be wonderful to have Fedora (or a significant subset of it) available for my Linksys NSLU2, since it's the only way to resurrect it from the drawer I buried it after I had enough of the unslung (debian based) firmware...
The Fedora ARM port should run on the NSLU2 just fine.
It's just that we don't provide HOWTOs/install images/installation help for the NSLU2 at this point, but in theory it should work...
On 6/12/07, Lennert Buytenhek buytenh@wantstofly.org wrote:
The Fedora ARM port should run on the NSLU2 just fine.
It's just that we don't provide HOWTOs/install images/installation help for the NSLU2 at this point, but in theory it should work...
mmm this starts to be interesting. So, where should I start? Any wiki, mailing list, forum I could join for discussing this stuff?
Hi Brendan!
On 06/07/2007 10:41 PM, Brendan Conoboy wrote: [ ... ]
Inside Red Hat, my group (GES) creates custom compilers and embedded Linux systems for our customers. We have done this for many years, using various upstream sources, building natively and with cross tools. For the last few years, we have used either RHEL or Fedora as our upstream source base.
Good self introduction. Now we know, that you know what you're talking 'bout. :-)
[ ... ]
I would like to see cross compilation become a standard method in Fedora. It scales where native builds don't. There might be faster arm chips these days, but lets not forget all the underpowered embedded CPUs and costly systems like s390. Bootstrapping is simplified. People without access to hardware can work on build problems (Simulators are good for this too).
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
What are the hurdles to adoption? Broadly, they break down into technical and social:
Technical: There must be cross compilers before we can cross compile. The build system must be enhanced to support cross compilation. Finally, packages must be modified to support cross compilation.
If you would have not written this, I would. :-) Yes, that's the first part. There where already a few threads about cross compilers for Fedora; I don't know what the outcome is/was. It seems to be some never ending story. :-( <quiet>I saw some cross compilers in CentOS</quiet> :-)
Social: As a volunteer effort, it is unreasonable to expect existing package maintainers to do the work necessary to support cross compilation. There must be people to take on that responsibility and work with upstream and package maintainers to integrate the necessary changes.
I think that's the same as with secondary arches. Yes, there must be some team supporting the arch, if it's done via cross compilers or on native hardware; But with one difference: The people who are involved in the 2ndary arch stuff, might not be very experienced with cross compilation; Like me and Alpha for example.
I don't have fast and easy answers to all of the above,
Nobody would expect... I don't have as well. Just posting my 2 cent...
but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think?
I think for Alpha we will have enough fast machines that can get the job done. I don't know about the other arches....
If there are volunteers for a arch and you have some man power who can support the ArchTeam, that would be great - I think. If the arch-team doesn't want cross compilation..... Let 'em alone. :-)
Best, Oliver
Oliver Falk wrote:
I would like to see cross compilation become a standard method in Fedora. It scales where native builds don't. There might be faster arm chips these days, but lets not forget all the underpowered embedded CPUs and costly systems like s390. Bootstrapping is simplified. People without access to hardware can work on build problems (Simulators are good for this too).
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Cross toolchains are made like this: you use your normal host compiler, for i386 say, to compile the gcc sources configured to emit target, say ARM, code. So you end up with an i386 executable compiler that emits ARM code.
Native compilers would be built on an ARM box or emulation creating an ARM executable compiler that emits ARM code. But in both cases, the compiler is coming from the same gcc sources.
In either case, if you give it some C to compile, it should emit the same ARM object file, one happens to emit that ARM object code with a compiler that is built from i386 instructions itself and another does it with the same compiler built from ARM instructions itself. In this way "real native hardware" has absolutely *nothing* to do with it.
I also went through Brendan's wandering through the desert of alternative build methods, I started with an NBD-mounted filesystem on a n x86 box and native compilers in there that ran on my 180MHz ARM9 board with 32MB of SDRAM (and swap over NBD that worked incidentally). Compiling a kernel on that worked, but gave me plenty of time, 8 hours or so IIRC, to ruminate over how addressing the 'fearsome' cross monster would probably be less painful than going on that way. And it really was just another way to get the same compiler sources to emit the same object faster by running it on a better box... it's just a few minutes now.
If there are volunteers for a arch and you have some man power who can support the ArchTeam, that would be great - I think. If the arch-team doesn't want cross compilation..... Let 'em alone. :-)
Cross is a lot less mysterious and magical than it sounds. Once it is sorted out according to Fedora's high engineering standards, being able to build for any supported arch on one physical platform with one filesystem at native platform speed will in fact be simpler, faster, more conistent and cheaper than the workarounds.
-Andy
On 06/08/2007 11:21 AM, Andy Green wrote:
Oliver Falk wrote:
I would like to see cross compilation become a standard method in Fedora. It scales where native builds don't. There might be faster arm chips these days, but lets not forget all the underpowered embedded CPUs and costly systems like s390. Bootstrapping is simplified. People without access to hardware can work on build problems (Simulators are good for this too).
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Cross toolchains are made like this: you use your normal host compiler, for i386 say, to compile the gcc sources configured to emit target, say ARM, code. So you end up with an i386 executable compiler that emits ARM code.
Native compilers would be built on an ARM box or emulation creating an ARM executable compiler that emits ARM code. But in both cases, the compiler is coming from the same gcc sources.
Of course so far I understood the system already. :-)
[ ... ]
If there are volunteers for a arch and you have some man power who can support the ArchTeam, that would be great - I think. If the arch-team doesn't want cross compilation..... Let 'em alone. :-)
Cross is a lot less mysterious and magical than it sounds. Once it is sorted out according to Fedora's high engineering standards, being able to build for any supported arch on one physical platform with one filesystem at native platform speed will in fact be simpler, faster, more conistent and cheaper than the workarounds.
Sure it's not much magic and mystery, but there are some issues we need to think about... (See later posts that I'll write now :-) ).
-of
Oliver Falk wrote:
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Cross toolchains are made like this: you use your normal host compiler, for i386 say, to compile the gcc sources configured to emit target, say ARM, code. So you end up with an i386 executable compiler that emits ARM code.
Native compilers would be built on an ARM box or emulation creating an ARM executable compiler that emits ARM code. But in both cases, the compiler is coming from the same gcc sources.
Of course so far I understood the system already. :-)
I wrote it because you mentioned "real native hardware". For testing the resulting packages I completely agree, but for building them it shouldn't matter. If it does matter it's a problem with the compiler or how the package is being built.
-Andy
On Fri, Jun 08, 2007 at 10:21:56AM +0100, Andy Green wrote:
Native compilers would be built on an ARM box or emulation creating an ARM executable compiler that emits ARM code. But in both cases, the compiler is coming from the same gcc sources.
In either case, if you give it some C to compile, it should emit the same ARM object file, one happens to emit that ARM object code with a compiler that is built from i386 instructions itself and another does it with the same compiler built from ARM instructions itself. In this way "real native hardware" has absolutely *nothing* to do with it.
I don't think that a cross-compiler always generates the very same binary code (e.g. I've been told that you can't always pre-compute constant floating point operations on the compiling host as you would on the target), but cross-compiling _should_ produce functionally identical code.
Oliver Falk wrote:
Good self introduction. Now we know, that you know what you're talking 'bout. :-)
I pretend well, anyway :-) I'll see if some more folks from my group will jump in here.
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Reliable? Sure. But there are problems unique to cross compiling which must be addressed. You don't want to pull in a host-header instead of a target-header. You also can't run the resulting executables so post-build testsuites can't be run. That said, object and executable generation is pretty much the same whether your cross compile or natively compile, so you're going to get functionally identical bits.
I think that's the same as with secondary arches. Yes, there must be some team supporting the arch, if it's done via cross compilers or on native hardware; But with one difference: The people who are involved in the 2ndary arch stuff, might not be very experienced with cross compilation; Like me and Alpha for example.
Right- I hope I'm not alienating the folks who want to bring Arm to the Fedora fold even if it means native compilation. New arches and cross compiling aren't directly related, but when you put them together successfully it's very beneficial, but not necessary. Still, I bet there are more people per capita in the secondary-arch camp interested in cross compiling than the primary arches.
I think for Alpha we will have enough fast machines that can get the job done. I don't know about the other arches....
That's handy- how will you bootstrap?
If there are volunteers for a arch and you have some man power who can support the ArchTeam, that would be great - I think. If the arch-team doesn't want cross compilation..... Let 'em alone. :-)
I'm picturing more of a CrossTeam with a similar cross-sectional responsibility.
On 06/08/2007 09:32 PM, Brendan Conoboy wrote:
Oliver Falk wrote:
Good self introduction. Now we know, that you know what you're talking 'bout. :-)
I pretend well, anyway :-) I'll see if some more folks from my group will jump in here.
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Reliable? Sure. But there are problems unique to cross compiling which must be addressed. You don't want to pull in a host-header instead of a target-header.
Issue number 1.
You also can't run the resulting executables so post-build testsuites can't be run.
Issue number 2.
That said, object and executable generation is pretty much the same whether your cross compile or natively compile, so you're going to get functionally identical bits.
OK. That might be true for gcc, but how about gcj? Or other compilers? I'm also thinking about python that emits byte-code. Is this code machine independent? I'm not sure; Could google or read, but just want to mention....
I think that's the same as with secondary arches. Yes, there must be some team supporting the arch, if it's done via cross compilers or on native hardware; But with one difference: The people who are involved in the 2ndary arch stuff, might not be very experienced with cross compilation; Like me and Alpha for example.
Right- I hope I'm not alienating the folks who want to bring Arm to the Fedora fold even if it means native compilation. New arches and cross compiling aren't directly related, but when you put them together successfully it's very beneficial, but not necessary. Still, I bet there are more people per capita in the secondary-arch camp interested in cross compiling than the primary arches.
Yes, cross compilation is an interesting; At least for me and I would be happy to be a bit involved; You never stop learning...
I think for Alpha we will have enough fast machines that can get the job done. I don't know about the other arches....
That's handy- how will you bootstrap?
alphacore.info. We have AC3 (FC5 based). I also was able to update large parts to FC6 and fcdevel. glibc and gcc, well and also a newer 2.6.21 kernel: [root@tyskie ~]# uname -a Linux tyskie.linux-kernel.at 2.6.21-1.3125.fc7 #1 Tue May 15 14:52:47 CEST 2007 alpha alpha alpha GNU/Linux
Not all pieces of my/our specs are perfect to be commited to fedora cvs... But I'm bugzilla-ing as much as I can and most pkg-maintainers are helpful and willing to include alpha support; Thinking of secondary arch support...
[ ... ]
-of
Oliver Falk wrote:
On 06/08/2007 09:32 PM, Brendan Conoboy wrote:
Oliver Falk wrote:
Good self introduction. Now we know, that you know what you're talking 'bout. :-)
I pretend well, anyway :-) I'll see if some more folks from my group will jump in here.
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Reliable? Sure. But there are problems unique to cross compiling which must be addressed. You don't want to pull in a host-header instead of a target-header.
Issue number 1.
From gcc manpage
--sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler would normally search for headers in /usr/include and libraries in /usr/lib, it will instead search dir/usr/include and dir/usr/lib.
You also can't run the resulting executables so post-build testsuites can't be run.
Issue number 2.
Well they can't be run on the build box, that is true. But they can be packaged and run on the real target along with the binary itself, which will still need testing on a real target anyway.
That said, object and executable generation is pretty much the same whether your cross compile or natively compile, so you're going to get functionally identical bits.
OK. That might be true for gcc, but how about gcj? Or other compilers? I'm also thinking about python that emits byte-code. Is this code machine independent? I'm not sure; Could google or read, but just want to mention....
Well look, if I compile "Hello World" on an ARM using an ARM native compiler, it should do the same result as if I compile it on an x86 using an x86 native compiler or I cross compile it somehow, right? All of them print "Hello World" when run on something that can run the result. gcc shouldn't be any different, bugs in the compiler notwithstanding, no matter how you build the same sources they should work identically when you run them, no matter what platform or CPU.
-Andy
On 06/11/2007 10:28 AM, Andy Green wrote:
Oliver Falk wrote:
On 06/08/2007 09:32 PM, Brendan Conoboy wrote:
Oliver Falk wrote:
Good self introduction. Now we know, that you know what you're talking 'bout. :-)
I pretend well, anyway :-) I'll see if some more folks from my group will jump in here.
True. But is cross compilation really as reliable as native compilation is? I'm not experienced with cross compilation... But I think some errors will only occur on *real native hardware*...
Reliable? Sure. But there are problems unique to cross compiling which must be addressed. You don't want to pull in a host-header instead of a target-header.
Issue number 1.
From gcc manpage
--sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler would normally search for headers in /usr/include and libraries in /usr/lib, it will instead search dir/usr/include and dir/usr/lib.
Sure, Andy I got it. :-) I just wanted to address it. I understand that there is an easy solution to use another sysroot, but we need to get the packages/headers/libs there :-)
You also can't run the resulting executables so post-build testsuites can't be run.
Issue number 2.
Well they can't be run on the build box, that is true. But they can be packaged and run on the real target along with the binary itself, which will still need testing on a real target anyway.
Sure, testing is needed anyway, but if testing at %build level doesn't work, we normally stop and don't build packages... If there would be some automation for this, that would be great.
That said, object and executable generation is pretty much the same whether your cross compile or natively compile, so you're going to get functionally identical bits.
OK. That might be true for gcc, but how about gcj? Or other compilers? I'm also thinking about python that emits byte-code. Is this code machine independent? I'm not sure; Could google or read, but just want to mention....
Well look, if I compile "Hello World" on an ARM using an ARM native compiler, it should do the same result as if I compile it on an x86 using an x86 native compiler or I cross compile it somehow, right? All of them print "Hello World" when run on something that can run the result. gcc shouldn't be any different, bugs in the compiler notwithstanding, no matter how you build the same sources they should work identically when you run them, no matter what platform or CPU.
Andy, I guess you have enough experience with cross compilers and so I have to believe you. I'm not so ("cross-)experienced(") and that's why I don't *trust* it until I haven't *tried* it :-)
-of
Oliver Falk wrote:
Reliable? Sure. But there are problems unique to cross compiling which must be addressed. You don't want to pull in a host-header instead of a target-header.
Issue number 1.
It's a pretty rare issue these days. You have to provide an absolute pathname, which is always frowned upon. Further, if you cross-build in a chroot, it's a non-issue.
You also can't run the resulting executables so post-build testsuites can't be run.
Issue number 2.
Yep- but only relevant for a small set of packages.
OK. That might be true for gcc, but how about gcj? Or other compilers? I'm also thinking about python that emits byte-code. Is this code machine independent? I'm not sure; Could google or read, but just want to mention....
Gcj?! Er, no problem there...
I'm sure there could be some Python issues (We have not had to tackle that one). When we start implementing a cross compile feature, we would naturally would take on the easy and critical packages first. Python could come later.
Yes, cross compilation is an interesting; At least for me and I would be happy to be a bit involved; You never stop learning...
Great!
On Fri, Jun 08, 2007 at 01:32:12PM -0600, Brendan Conoboy wrote:
I think for Alpha we will have enough fast machines that can get the job done. I don't know about the other arches....
That's handy- how will you bootstrap?
That's a bit of a false argument. How are you ever going to get your x86 distro bootstrapped? I.e. how are you ever going to produce a chicken without eggs?
Lennert Buytenhek wrote:
That's a bit of a false argument. How are you ever going to get your x86 distro bootstrapped? I.e. how are you ever going to produce a chicken without eggs?
Toggle switches, man.
Cross compiling, it's all about artificial insemination.
Thought I'd follow up on my own post with some specificity on what I'm imagining:
Brendan Conoboy wrote:
Technical: There must be cross compilers before we can cross compile.
This is actually two packages: Gcc and Binutils. Both are already quite easy to build such that they use a sys-root. If you're not familiar with sys-roots, this is path prefix to /. Thus you usually have something like $sysroot/usr/lib and $sysroot/usr/include. When the compiler sees #include <stdio.h> it actually reads in $sysroot/usr/include/stdio.h. Same for -l.
Building a cross binutils requires kernel headers for the target architecture. Building gcc requires kernel headers and glibc. There are scripts to solve the initial chicken/egg problem of where to get that glibc for a new arch. At some point in the future gcc might not require glibc to build, but we aren't there yet.
The build system must be enhanced to support cross compilation.
This is a really interesting (to me) extension of the build system requiring enhancements in many areas.
First, there are primitives in Koji that need to be built up such that, for instance, x86 knows it can cross build arm tools.
Second, the x86 host needs to be able to retrieve and install arm dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc).
Third, a native/cross hybrid environment needs to be setup to facilitate the common assumptions made by packages. Previous cross compilation efforts inside my group have spent a lot of time on this. I bet others have as well
Finally, packages must be modified to support cross compilation.
This is really a one-at-a-time process. It's often a matter of using relative paths so that #include <header> gets the right header. Or using headers instead of directly reading from /proc. Every package is different. Autotools using packages are frequently much easier than non.
Social: As a volunteer effort, it is unreasonable to expect existing package maintainers to do the work necessary to support cross compilation. There must be people to take on that responsibility and work with upstream and package maintainers to integrate the necessary changes.
I have read the Secondary Architectures proposal and thread with great interest. While there may be some overlap of interest with cross compiling, it's not inherently true. Thus, I'd suggest a cross-team who would generally be responsible for cross-compilation efforts. This might break down like so:
1. Responsible for parts of the build system dedicated to cross compilation.
2. Maintainers of the cross compilation tools (These would presumably be rebuilds of gcc and binutils for the cross-targets).
3. Make changes to existing packages in cooperation with the package maintainer.
4. Be responsible for fixing builds that fail because of cross compiling, but succeed when natively built.
Anybody whose turf I just suggested stepping on, please chime in!
On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote:
Building a cross binutils requires kernel headers for the target architecture. Building gcc requires kernel headers and glibc. There are scripts to solve the initial chicken/egg problem of where to get that glibc for a new arch. At some point in the future gcc might not require glibc to build, but we aren't there yet.
Before we get to actually cross-compiling something for release, it would be good to get cross-compilers into Fedora.
Making a cross-binutils package isn't hard; it's a relatively modification to our existing binutils package to make it build for multiple %targets.
Making a cross-gcc package which targets linux-elf is harder, because of the evil recursive dependencies to which you refer above. It would be good if we could get that working though.
Unfortunately the scripts to which you refer just 'solve' the problem by throwing everything together into one huge lump and building gcc, then glibc, then rebuilding gcc again. That's not really very useful for us when we want the compiler and glibc to be entirely separate packages -- and in fact glibc would be a .$TARGET.rpm to be installed into the sysroot, while the compiler is a native package.
I haven't looked at this for a while, but IIRC we can build gcc and libgcc.a directly, using 'only' header files which can be provided in advance. The problem is that we have to dynamically link libgcc.so with libc.so? We don't actually need a _real_ libc.so for that though, do we? We could just make a dummy DSO with the functions we want, and link against that? If we do that, what else still has recursive dependencies?
David Woodhouse wrote:
On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote:
Building a cross binutils requires kernel headers for the target architecture. Building gcc requires kernel headers and glibc. There are scripts to solve the initial chicken/egg problem of where to get that glibc for a new arch. At some point in the future gcc might not require glibc to build, but we aren't there yet.
Before we get to actually cross-compiling something for release, it would be good to get cross-compilers into Fedora.
Making a cross-binutils package isn't hard; it's a relatively modification to our existing binutils package to make it build for multiple %targets.
Making a cross-gcc package which targets linux-elf is harder, because of the evil recursive dependencies to which you refer above. It would be good if we could get that working though.
Unfortunately the scripts to which you refer just 'solve' the problem by throwing everything together into one huge lump and building gcc, then glibc, then rebuilding gcc again. That's not really very useful for us when we want the compiler and glibc to be entirely separate packages -- and in fact glibc would be a .$TARGET.rpm to be installed into the sysroot, while the compiler is a native package.
I haven't looked at this for a while, but IIRC we can build gcc and libgcc.a directly, using 'only' header files which can be provided in advance. The problem is that we have to dynamically link libgcc.so with libc.so? We don't actually need a _real_ libc.so for that though, do we? We could just make a dummy DSO with the functions we want, and link against that? If we do that, what else still has recursive dependencies?
Notice that I have spends weeks on fixing exactly the problems, with creating a cross compiling gcc targeting linux with glibc, described here to build an cross arm toolchain for the gp2x handheld for Fedora.
Please check: http://people.atrpms.net/~hdegoede/
For all my SRPMS / SPECS for this, with regards to solving the above metioned problems esp arm-gp2x-linux-gcc.spec is interesting. I think I've got this one nailed, so before other people start pouring time into this please first check my work, doing this for other linux-glibc targets, using Fedora sources instead of the open2x sources I'm using should be mostly identical. I'll gladly answer any questions.
Reviews would be welcome to, see: http://fedoraproject.org/wiki/SIGs/Embedded
For links to all the review tickets.
Regards,
Hans
On 06/09/2007 11:23 AM, Hans de Goede wrote:
David Woodhouse wrote:
On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote:
Building a cross binutils requires kernel headers for the target architecture. Building gcc requires kernel headers and glibc. There are scripts to solve the initial chicken/egg problem of where to get that glibc for a new arch. At some point in the future gcc might not require glibc to build, but we aren't there yet.
Before we get to actually cross-compiling something for release, it would be good to get cross-compilers into Fedora.
Making a cross-binutils package isn't hard; it's a relatively modification to our existing binutils package to make it build for multiple %targets.
Making a cross-gcc package which targets linux-elf is harder, because of the evil recursive dependencies to which you refer above. It would be good if we could get that working though.
Unfortunately the scripts to which you refer just 'solve' the problem by throwing everything together into one huge lump and building gcc, then glibc, then rebuilding gcc again. That's not really very useful for us when we want the compiler and glibc to be entirely separate packages -- and in fact glibc would be a .$TARGET.rpm to be installed into the sysroot, while the compiler is a native package.
I haven't looked at this for a while, but IIRC we can build gcc and libgcc.a directly, using 'only' header files which can be provided in advance. The problem is that we have to dynamically link libgcc.so with libc.so? We don't actually need a _real_ libc.so for that though, do we? We could just make a dummy DSO with the functions we want, and link against that? If we do that, what else still has recursive dependencies?
Notice that I have spends weeks on fixing exactly the problems, with creating a cross compiling gcc targeting linux with glibc, described here to build an cross arm toolchain for the gp2x handheld for Fedora.
Please check: http://people.atrpms.net/~hdegoede/
For all my SRPMS / SPECS for this, with regards to solving the above metioned problems esp arm-gp2x-linux-gcc.spec is interesting. I think I've got this one nailed, so before other people start pouring time into this please first check my work, doing this for other linux-glibc targets, using Fedora sources instead of the open2x sources I'm using should be mostly identical. I'll gladly answer any questions.
Reviews would be welcome to, see: http://fedoraproject.org/wiki/SIGs/Embedded
For links to all the review tickets.
Thanks for your post Hans; Didn't knew there already is an Embedded SIG; And also that there are already people working on good cross compilers.
So there's another cross specialist :-)
-of
On Sat, 2007-06-09 at 11:23 +0200, Hans de Goede wrote:
Notice that I have spends weeks on fixing exactly the problems, with creating a cross compiling gcc targeting linux with glibc, described here to build an cross arm toolchain for the gp2x handheld for Fedora.
Please check: http://people.atrpms.net/~hdegoede/
For all my SRPMS / SPECS for this, with regards to solving the above metioned problems esp arm-gp2x-linux-gcc.spec is interesting. I think I've got this one nailed, so before other people start pouring time into this please first check my work, doing this for other linux-glibc targets, using Fedora sources instead of the open2x sources I'm using should be mostly identical. I'll gladly answer any questions.
I see you've actually pulled in glibc sources and you're using them in the gcc build. I was trying to avoid that.
I suppose if we can depend on having a sysroot populated with appropriate glibc-*.$ARCH.rpm packages then the bootstrap approach isn't _so_ bad, but that might be a lot to expect of yum/koji.
David Woodhouse wrote:
I see you've actually pulled in glibc sources and you're using them in the gcc build. I was trying to avoid that.
Yeah, it's nasty but necessary until you have binaries for your dependencies. Hopefully gcc will split out all its support libraries in time such that it isn't necessary. Meanwhile, it's only a problem for arches that the build system doesn't already have a glibc for.
I suppose if we can depend on having a sysroot populated with appropriate glibc-*.$ARCH.rpm packages then the bootstrap approach isn't _so_ bad, but that might be a lot to expect of yum/koji.
It's an area of the build system that has to be extended for cross compiling to work in general. Making the cross compiler build is but a small example of the general case. There are plenty of packages which have multi-layer dependencies. The build system needs to resolve those, installing the packages into the sys-root for the cross compiler to compile and link against. This falls to the build system because it would be silly for each and every package to have to do that itself.
On Sat, 2007-06-09 at 09:20 +0100, David Woodhouse wrote:
On Fri, 2007-06-08 at 13:56 -0600, Brendan Conoboy wrote:
Building a cross binutils requires kernel headers for the target architecture. Building gcc requires kernel headers and glibc. There are scripts to solve the initial chicken/egg problem of where to get that glibc for a new arch. At some point in the future gcc might not require glibc to build, but we aren't there yet.
Before we get to actually cross-compiling something for release, it would be good to get cross-compilers into Fedora.
Making a cross-binutils package isn't hard; it's a relatively modification to our existing binutils package to make it build for multiple %targets.
Making a cross-gcc package which targets linux-elf is harder, because of the evil recursive dependencies to which you refer above. It would be good if we could get that working though.
Unfortunately the scripts to which you refer just 'solve' the problem by throwing everything together into one huge lump and building gcc, then glibc, then rebuilding gcc again. That's not really very useful for us when we want the compiler and glibc to be entirely separate packages -- and in fact glibc would be a .$TARGET.rpm to be installed into the sysroot, while the compiler is a native package.
I haven't looked at this for a while, but IIRC we can build gcc and libgcc.a directly, using 'only' header files which can be provided in advance. The problem is that we have to dynamically link libgcc.so with libc.so? We don't actually need a _real_ libc.so for that though, do we? We could just make a dummy DSO with the functions we want, and link against that? If we do that, what else still has recursive dependencies?
-- dwmw2
[bottom post :-)]
Building cross toolchains is a common exercise in the embedded systems world. Take a look at Dan Kegel's "crosstools"
which is RPM based and extensible. crosstools "auto-magically" handles the recursive dependency problems that you mention
If you are seeking an entire cross tool chain development environment, take a look at two open source offerings from the embedded systems world:
* Embedded Linux Development Kit
http://www.denx.de/wiki/DULG/WebHome
* Linux Target Image Builder
http://savannah.nongnu.org/projects/ltib/
Both are RPM based and extensible.
-Joseph
Joseph Sacco wrote:
which is RPM based and extensible. crosstools "auto-magically" handles the recursive dependency problems that you mention
It's the doing-it-the-rpm-way that is a problem. All from-scratch gcc cross compiler-generating scripts that I have seen require glibc sources as part of the compiler build. In an rpm universe you only need headers and libraries to build a package, not sources from some other package. My scripts, Hans's scripts, and crosstool all have this limitation. This is because gcc contains both an independent compiler and libc-intertwined support libraries.
Both are RPM based and extensible.
Doesn't seem like the sort of thing we could simply bolt onto the side of the existing build system and enjoy. It's possibly not even that big of a change to the build system since it's just a slight twist on something it's already doing.
David Woodhouse wrote:
Before we get to actually cross-compiling something for release, it would be good to get cross-compilers into Fedora.
Making a cross-binutils package isn't hard; it's a relatively modification to our existing binutils package to make it build for multiple %targets.
Making a cross-gcc package which targets linux-elf is harder, because of the evil recursive dependencies to which you refer above. It would be good if we could get that working though.
Hi,
Yep, we've been through this a few times. Having discussed this with you a number of times before, I know where you're coming from. We really should be able to build gcc without having to build parts of glibc in the process. That said, this is really only an exercise in bootstrapping which doesn't happen very often.
Let us, for example, pretend we're just discussing cross compilation for existing archs. Because of the iterative nature of these builds, everything we need is already there to build the cross compiler. We have kernel headers and we have a glibc rpm for the target arch. All that we need in some machinery to pull in files from a different arch and extract them into a sys-root.
As gcc matures, it's likely that the libgcc problem will go away by it being split out. At that time, the chicken/egg problem will be solved without having to resort to clever hacks.
On Mon, 2007-06-11 at 15:42 -0600, Brendan Conoboy wrote:
Yep, we've been through this a few times. Having discussed this with you a number of times before, I know where you're coming from. We really should be able to build gcc without having to build parts of glibc in the process.
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
Or do we even need to build the dynamic libgcc _with_ the compiler at all?
That said, this is really only an exercise in bootstrapping which doesn't happen very often.
Actually it happens for me every time I build a cross-compiler. But perhaps it doesn't _need_ to; you're right.
Let us, for example, pretend we're just discussing cross compilation for existing archs.
That's a very good place to start. Especially if you realise that it doesn't _really_ restrict us to 'existing architectures' -- it restricts us to those architectures for which we can cobble together 'native' packages for gcc, etc. Which is actually not much of a restriction at all.
Because of the iterative nature of these builds, everything we need is already there to build the cross compiler. We have kernel headers and we have a glibc rpm for the target arch. All that we need in some machinery to pull in files from a different arch and extract them into a sys-root.
That would be an interesting answer, yes. It only solves the _build_ part of the problem though. The packaging side remains -- you'll want to end up a cross-compiler package for the host arch, but libgcc etc. for the target.
RPM doesn't currently let you spit out even .noarch.rpm and $ARCH.rpm simultaneously -- to build both i686-linux-gnu-gcc-$V-$R.ppc.rpm and libgcc-$V-$R.i386.rpm you'll almost certainly need a separate rpmbuild run _anyway_. So how will we handle that?
As gcc matures, it's likely that the libgcc problem will go away by it being split out. At that time, the chicken/egg problem will be solved without having to resort to clever hacks.
I think we need to accelerate that rather than waiting for it.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Index: binutils.spec =================================================================== RCS file: /cvs/pkgs/rpms/binutils/F-7/binutils.spec,v retrieving revision 1.115 diff -u -p -r1.115 binutils.spec --- binutils.spec 14 Apr 2007 15:21:02 -0000 1.115 +++ binutils.spec 12 Jun 2007 15:30:56 -0000 @@ -1,5 +1,13 @@ +%if "%{?binutils_target}" == "" +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.17.50.0.12 Release: 4 License: GPL @@ -51,7 +59,7 @@ have a stable ABI. Developers starting to consider using libelf instead of BFD.
%prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -66,7 +74,7 @@ to consider using libelf instead of BFD. %patch8 -p0 -b .osabi~ %patch9 -p0 -b .rh235747~
-# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i[3-7]86/i[34567]86/g' */conf* @@ -78,24 +86,36 @@ sed -i -e 's/^libbfd_la_LDFLAGS = /&-Wl, sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure
%build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS=--enable-64-bit-bfd + ;; + ia64*) + CARGS=--enable-targets=i386-linux + ;; +esac +%if %isnative + SHAREDARGS=--enable-shared + TARGET=%{binutils_target} + SYSROOT= +%else + SHAREDARGS=--disable-shared + TARGET="--target %{binutils_target} --host %{_target_platform}" + SYSROOT="--with-sysroot=/usr/%{binutils_target}" %endif CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ + $TARGET --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror + --infodir=%{_infodir} $SHAREDARGS $CARGS --disable-werror $SYSROOT make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info make -k check < /dev/null > check.log 2>&1 || : @@ -107,8 +127,9 @@ cd .. %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %isnative make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info*
@@ -130,10 +151,6 @@ rm -f %{buildroot}%{_prefix}/%{_lib}/lib # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la
-# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include <bits/wordsize.h>~;}' \ %ifarch %{ix86} x86_64 @@ -151,22 +168,36 @@ sed -i -e '/^#include "ansidecl.h"/{p;s~ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h
+%else # native +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # native + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +rm -rf %{buildroot}%{_prefix}/%{binutils_target} + + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang
%clean rm -rf %{buildroot}
+%if %isnative %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -197,12 +228,14 @@ exit 0 if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # native
-%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if %isnative %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -212,6 +245,7 @@ fi %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # native
%changelog * Sat Apr 14 2007 Jakub Jelinek jakub@redhat.com 2.17.50.0.12-4
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
1. One srpm to rule them all. This seems like a bad idea as it doesn't scale.
2. One srpm which generates multiple crosses. This might be in the form of one package for the Fedora mesh, another for all mips targets, and so forth. The realm of when somebody wants to be a cross-arch-czar or there is some technical reason to bunch them together.
3. One srpm which generates packages for a single cross, like Hans's arm-gp2x-linux-package effort
I favor a combination of #2 and #3. I'll see about adapting your binutils patch to accommodate multiple targets, unless people think this is a really bad idea.
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
- One srpm to rule them all. This seems like a bad idea as it doesn't
scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets.
- One srpm which generates multiple crosses. This might be in the
form of one package for the Fedora mesh, another for all mips targets, and so forth. The realm of when somebody wants to be a cross-arch-czar or there is some technical reason to bunch them together.
I am having doubts this can work, either, because different architectures/target OS aren't necessarily in a shape to be using the same sources.
It definitely don't apply to embedded targets, which tend to require different versions on different architectures.
- One srpm which generates packages for a single cross, like Hans's
arm-gp2x-linux-package effort
IMO, this is the only viable approach. It bloats the repos and requires some effort to assure packaging consistency when targeting several architectures/OSes, but it's basically what I am doing.
I favor a combination of #2 and #3.
FWI: What I am doing for my cross-toolchain rpms is to generate the specs from a other, shared spec templates/fragments.
I'll see about adapting your binutils patch to accommodate multiple targets, unless people think this is a really bad idea.
This idea probably can be made functional for targets addressing different archs of the same OS, but it doesn't work across OSes nor for embedded targets, because vendors often have different patches applied, even to binutils.
Also, there occasionally are problems stemming from certain host/target combinations which render one of binutils/gcc/gdb components unbuildable for one host/target pair. A combined binutils is not unlikely to suffer from the same issues, which would mean "one broken" host/target pair is likely to block out all (E.g. I recently found binutils-2.17 for target sparc-rtems* to bomb out on x86_64, which they build flawlessly on i386).
Ralf
Ralf Corsepius wrote:
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
- One srpm to rule them all. This seems like a bad idea as it doesn't
scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets.
Yet if you can put the clutter issue aside, this is definitely the Holy Grail. The spec file is the single point at which the uncontrolled variance of the raw tarballs are smoothed into a normalized Fedora package.
Having multiple specs is going to lead to duplication of information and loss of coherence when changes are made.
How about... a single Holy Spec, exactly what Fedora has right now, but which gets dynamically pre-patched if there is stuff needed for cross on a particular package that can't be hidden in the rpmmacros? The set of arch spec patches lives in the SRPM like the other patches. This:
- keeps a single Fedora basic spec - allows non-cross folks to totally ignore the existence of cross if they like - allows maintainability - visibility of what is done for per-arch cross
-Andy
Andy Green wrote:
Ralf Corsepius wrote:
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
- One srpm to rule them all. This seems like a bad idea as it doesn't
scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets.
Yet if you can put the clutter issue aside, this is definitely the Holy Grail. The spec file is the single point at which the uncontrolled variance of the raw tarballs are smoothed into a normalized Fedora package.
Having multiple specs is going to lead to duplication of information and loss of coherence when changes are made.
How about... a single Holy Spec, exactly what Fedora has right now, but which gets dynamically pre-patched if there is stuff needed for cross on a particular package that can't be hidden in the rpmmacros? The set of arch spec patches lives in the SRPM like the other patches. This:
- keeps a single Fedora basic spec
- allows non-cross folks to totally ignore the existence of cross if
they like
- allows maintainability
- visibility of what is done for per-arch cross
One single spec might be an idea for Fedora-Fedora cross packages, but it is not the answer for Fedora-Other (Embedded) OS target.
For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I don't think stuffing this into the main Fedora binutils and glibc specs is a good idea.
Regards,
Hans
Hans de Goede wrote:
Andy Green wrote:
Ralf Corsepius wrote:
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
- One srpm to rule them all. This seems like a bad idea as it
doesn't scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets.
Yet if you can put the clutter issue aside, this is definitely the Holy Grail. The spec file is the single point at which the uncontrolled variance of the raw tarballs are smoothed into a normalized Fedora package.
Having multiple specs is going to lead to duplication of information and loss of coherence when changes are made.
How about... a single Holy Spec, exactly what Fedora has right now, but which gets dynamically pre-patched if there is stuff needed for cross on a particular package that can't be hidden in the rpmmacros? The set of arch spec patches lives in the SRPM like the other patches. This:
- keeps a single Fedora basic spec
- allows non-cross folks to totally ignore the existence of cross if
they like
- allows maintainability
- visibility of what is done for per-arch cross
One single spec might be an idea for Fedora-Fedora cross packages, but it is not the answer for Fedora-Other (Embedded) OS target.
For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I don't think stuffing this into the main Fedora binutils and glibc specs is a good idea.
Maybe I didn't make my actual point clear in that (or maybe I don't get your objection)... the idea is you maintain a patch against the existing Fedora spec file for any package and arch that needs meddling with. So there is one spec file same as right now - unchanged - but you have additional per-arch pre-patches in the SRPM as well for cross cases that need them. Non-cross people who don't go look at the patches aren't even aware anything has changed let alone see things "stuffed" or "cluttered".
-Andy
Andy Green wrote:
Hans de Goede wrote:
Andy Green wrote:
Ralf Corsepius wrote:
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
- One srpm to rule them all. This seems like a bad idea as it
doesn't scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets.
Yet if you can put the clutter issue aside, this is definitely the Holy Grail. The spec file is the single point at which the uncontrolled variance of the raw tarballs are smoothed into a normalized Fedora package.
Having multiple specs is going to lead to duplication of information and loss of coherence when changes are made.
How about... a single Holy Spec, exactly what Fedora has right now, but which gets dynamically pre-patched if there is stuff needed for cross on a particular package that can't be hidden in the rpmmacros? The set of arch spec patches lives in the SRPM like the other patches. This:
- keeps a single Fedora basic spec
- allows non-cross folks to totally ignore the existence of cross if
they like
- allows maintainability
- visibility of what is done for per-arch cross
One single spec might be an idea for Fedora-Fedora cross packages, but it is not the answer for Fedora-Other (Embedded) OS target.
For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I don't think stuffing this into the main Fedora binutils and glibc specs is a good idea.
Maybe I didn't make my actual point clear in that (or maybe I don't get your objection)... the idea is you maintain a patch against the existing Fedora spec file for any package and arch that needs meddling with. So there is one spec file same as right now - unchanged - but you have additional per-arch pre-patches in the SRPM as well for cross cases that need them. Non-cross people who don't go look at the patches aren't even aware anything has changed let alone see things "stuffed" or "cluttered".
You don't get my objectino, I'm crossing from Fedora but not too Fedora, therefore what is in Fedora's specfile is completely irrelevant. Extreme example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to 8051 (and other) microcontrollers. It uses its own assembler and is its own C-compiler, binutils and gcc are not used at all (except for building the asm / compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's specfile, a patch effectively replacing 100% of it, just because its a c-compiler too?
Also see my reaction to David Woodhouse last mail.
Regards,
Hans
-Andy
Hans de Goede wrote:
You don't get my objectino, I'm crossing from Fedora but not too Fedora, therefore what is in Fedora's specfile is completely irrelevant. Extreme example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to 8051 (and other) microcontrollers. It uses its own assembler and is its own C-compiler, binutils and gcc are not used at all (except for building the asm / compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's specfile, a patch effectively replacing 100% of it, just because its a c-compiler too?
Should Fedora packages have to deal with it at all "just because its a c-compiler too?" I think the scenario of striving to be able to build glibc for 8051 on sdcc needs to be triaged into a different discussion.
What seems to be in the world of the possible is to retrofit the Fedora - Fedora cross case into what exists already. The benefits that fall out of that in terms of regularizing upstreams for cross and making definitive cross recipes (for gcc anyway!) will only help everyone else.
-Andy
Andy Green wrote:
Hans de Goede wrote:
You don't get my objectino, I'm crossing from Fedora but not too Fedora, therefore what is in Fedora's specfile is completely irrelevant. Extreme example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to 8051 (and other) microcontrollers. It uses its own assembler and is its own C-compiler, binutils and gcc are not used at all (except for building the asm / compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's specfile, a patch effectively replacing 100% of it, just because its a c-compiler too?
Should Fedora packages have to deal with it at all "just because its a c-compiler too?" I think the scenario of striving to be able to build glibc for 8051 on sdcc needs to be triaged into a different discussion.
I'm not talking about building glibc for 8051 (that would be kinda hard as an average 8051 comes with 256 bytes of ram, and no I didn't forget an K or M there).
What I'm saying that using the same spec for sdcc and gcc makes no sense, iow that when crossing to something not fedora using Fedora's specs as a base makes no sense, because for example we might be dealing with a different compiler (version).
Please read my reply to David Woodhouse.
What seems to be in the world of the possible is to retrofit the Fedora
- Fedora cross case into what exists already. The benefits that fall
out of that in terms of regularizing upstreams for cross and making definitive cross recipes (for gcc anyway!) will only help everyone else.
Agreed, all that I'm saying is that the one spec file (with or without overlays) might be a good idea for Fedora-Fedora crosses, but is not for Fedora-Foo crosses.
Regards,
Hans
Hans de Goede wrote:
What I'm saying that using the same spec for sdcc and gcc makes no sense, iow that when crossing to something not fedora using Fedora's specs as a base makes no sense, because for example we might be dealing with a different compiler (version).
We agree on it, but I think accepting that it makes no sense then it is out of scope and just confusing the issue with a need that can't be met.
Please read my reply to David Woodhouse.
Yep I understood it. I also build for 8051 derivatives and so on, but I don't expect Fedora packaging to give me any help for what to build down there: it doesn't seem reasonable. ARM9 that can handle the kernel and so on -- and gcc -- is a different matter.
What seems to be in the world of the possible is to retrofit the Fedora
- Fedora cross case into what exists already. The benefits that fall
out of that in terms of regularizing upstreams for cross and making definitive cross recipes (for gcc anyway!) will only help everyone else.
Agreed, all that I'm saying is that the one spec file (with or without overlays) might be a good idea for Fedora-Fedora crosses, but is not for Fedora-Foo crosses.
Sure. But nothing Fedora can do can help with Fedora-Foo crosses where Foo is a wildcard and your plan is to replace their spec file anyway.
What it can do something about is the Fedora-Fedora cross case, and specfile patching would be a neat solution.
-Andy
Hans de Goede writes:
Andy Green wrote:
Hans de Goede wrote:
You don't get my objectino, I'm crossing from Fedora but not too Fedora, therefore what is in Fedora's specfile is completely irrelevant. Extreme example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to 8051 (and other) microcontrollers. It uses its own assembler and is its own C-compiler, binutils and gcc are not used at all (except for building the asm / compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's specfile, a patch effectively replacing 100% of it, just because its a c-compiler too?
Should Fedora packages have to deal with it at all "just because its a c-compiler too?" I think the scenario of striving to be able to build glibc for 8051 on sdcc needs to be triaged into a different discussion.
I'm not talking about building glibc for 8051 (that would be kinda hard as an average 8051 comes with 256 bytes of ram, and no I didn't forget an K or M there).
No, that's the 8052, the de luxe version. The 8051 has 128 bytes of RAM...
:-)
Andrew.
Andrew Haley wrote:
Hans de Goede writes:
Andy Green wrote:
Hans de Goede wrote:
You don't get my objectino, I'm crossing from Fedora but not too Fedora, therefore what is in Fedora's specfile is completely irrelevant. Extreme example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to 8051 (and other) microcontrollers. It uses its own assembler and is its own C-compiler, binutils and gcc are not used at all (except for building the asm / compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's specfile, a patch effectively replacing 100% of it, just because its a c-compiler too?
Should Fedora packages have to deal with it at all "just because its a c-compiler too?" I think the scenario of striving to be able to build glibc for 8051 on sdcc needs to be triaged into a different discussion.
I'm not talking about building glibc for 8051 (that would be kinda hard as an average 8051 comes with 256 bytes of ram, and no I didn't forget an K or M there).
No, that's the 8052, the de luxe version. The 8051 has 128 bytes of RAM...
I know, but actually most 8051 deratives are 8052's hence I wrote "average"
Regards,
Hans
On Wed, 2007-06-13 at 08:48 +0200, Ralf Corsepius wrote:
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it were.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build it for each target architecture we want?
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
- One srpm to rule them all. This seems like a bad idea as it doesn't
scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with cases and many (unused) patches, because different vendors apply different patch sets.
The same was true of the kernel until we started slapping people and making them push their code upstream rather than dumping it in the RPM, and banning the use of %ifarch in the specfile (at least for applying patches).
Having applied that discipline, this approach _does_ seem to work for the kernel. (So far, at least).
I think Jakub does a good job of keeping patches to a minimum for the toolchain, just as we do for the kernel. Why should we expect less from those involved in cross-compilers?
When I build an i386-fedora-linux-gnu cross-compiler package, I want that to be exactly the same compiler as the 'native' i386 compiler. The approach I've taken with binutils allows that.
Perhaps we wouldn't get away with the same for gcc, but it would be nice if we could.
- One srpm which generates multiple crosses. This might be in the
form of one package for the Fedora mesh, another for all mips targets, and so forth. The realm of when somebody wants to be a cross-arch-czar or there is some technical reason to bunch them together.
I am having doubts this can work, either, because different architectures/target OS aren't necessarily in a shape to be using the same sources.
It definitely don't apply to embedded targets, which tend to require different versions on different architectures.
We really don't want to pander to this. If an architecture cannot work with a current toolchain, then we should just ignore it until the toolchain is fixed. They can get it working upstream, or they can sod off.
Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel next... and then we'll have to hurt them.
- One srpm which generates packages for a single cross, like Hans's
arm-gp2x-linux-package effort
IMO, this is the only viable approach. It bloats the repos and requires some effort to assure packaging consistency when targeting several architectures/OSes, but it's basically what I am doing.
This would be a little nicer once we move to git and can just pull changes from Jakub's 'master' Fedora toolchain packages.
David Woodhouse wrote:
- One srpm which generates multiple crosses. This might be in the
form of one package for the Fedora mesh, another for all mips targets, and so forth. The realm of when somebody wants to be a cross-arch-czar or there is some technical reason to bunch them together.
I am having doubts this can work, either, because different architectures/target OS aren't necessarily in a shape to be using the same sources.
It definitely don't apply to embedded targets, which tend to require different versions on different architectures.
We really don't want to pander to this. If an architecture cannot work with a current toolchain, then we should just ignore it until the toolchain is fixed. They can get it working upstream, or they can sod off.
I think you on the one side and I and Ralf on the other side are talking about different things, let me try to clarify. I believe you are talking about cross building the Fedora distro to run as a replacement distro on embedded devices, in which case I agree with what you say above.
However I (and Ralf to some extend to AFAIK) am talking about building executables to run on an embedded platform using the manufacturer provided distro for that platform. For example with the gp2x (a handheld game device / video player) there is a distro in onboard FLASH and you can insert an sd-card with your own applications.
In this case completely different rules apply.
Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel next... and then we'll have to hurt them.
No we won't (be shipping their hacked kernel) as that is already in the device, we are "merely" shipping a toolchain (+ headers / libs needed to compile / link) to build applications to install into an already existing OS/platform.
- One srpm which generates packages for a single cross, like Hans's
arm-gp2x-linux-package effort
IMO, this is the only viable approach. It bloats the repos and requires some effort to assure packaging consistency when targeting several architectures/OSes, but it's basically what I am doing.
This would be a little nicer once we move to git and can just pull changes from Jakub's 'master' Fedora toolchain packages.
Again this is not Fedora-Fedora cross this is Fedora-XXXX cross, where XXXX migh not even be Linux (it isn't in Ralf's scenario), so Jukub's Fedora packages are about as much "master" packages as mandrake's, suse's or debians.
For starters a completely different version of some of the major toolchain components may be used, in which case its madness todo this a a patch on top of Jakub's specfile, because 90% of jakubs specfile would get replaced.
Regards,
Hans
On Wed, 2007-06-13 at 09:38 +0200, Hans de Goede wrote:
I think you on the one side and I and Ralf on the other side are talking about different things, let me try to clarify. I believe you are talking about cross building the Fedora distro to run as a replacement distro on embedded devices, in which case I agree with what you say above.
Yes. To start with, I have been thinking about Fedora->Fedora (or at least Fedora->Linux) cross-compilation.
However I (and Ralf to some extend to AFAIK) am talking about building executables to run on an embedded platform using the manufacturer provided distro for that platform. For example with the gp2x (a handheld game device / video player) there is a distro in onboard FLASH and you can insert an sd-card with your own applications.
In this case completely different rules apply.
Yes, this is true. Where there are ABI differences, it makes sense to have a toolchain version which matches your target environment.
On Wed, 2007-06-13 at 08:55 +0100, David Woodhouse wrote:
On Wed, 2007-06-13 at 09:38 +0200, Hans de Goede wrote:
I think you on the one side and I and Ralf on the other side are talking about different things, let me try to clarify. I believe you are talking about cross building the Fedora distro to run as a replacement distro on embedded devices, in which case I agree with what you say above.
Yes. To start with, I have been thinking about Fedora->Fedora (or at least Fedora->Linux) cross-compilation.
Let me try to clarify.
I am referring to general Fedora-><any target/any-OS> cross toolchains, not necessarily restricted to Fedora targets.
My primary focus is on <Fedora|RHEL>->*rtems* cross toolchains (rtems: A free rt-OS for embedded targets) for which I am co-maintaining/co-leading OS- and toolchain-development and also am providing toolchain rpms.
Peculiar about such targets is them often addressing "2nd class architectures", which have little attention in upstream binutils/GCC/gdb and therefore often require custom patches, or particular hand-selected "known to work" source versions.
My secondary focus is on sys-rooted Fedora-><BigOS> toolchains, reusing target binaries, in first place aiming at Canadian cross building <BigOS>->*rtems* toolchains on Fedora, in second place serving as "test beds" for portability issues in packages.
However I (and Ralf to some extend to AFAIK) am talking about building executables to run on an embedded platform using the manufacturer provided distro for that platform. For example with the gp2x (a handheld game device / video player) there is a distro in onboard FLASH and you can insert an sd-card with your own applications.
In this case completely different rules apply.
Yes, this is true. Where there are ABI differences, it makes sense to have a toolchain version which matches your target environment.
ABI is one thing. But there are other things, not necessarily in binutils, but more in GCC and gdb. E.g. consider Fedora->FreeBSD, Fedora->SuSE, Fedora->MinGW toolchains.
Though they share the same basis, they are substantially different in many details. One lesson I've learned through all these years, I am building cross-toolchains: Use upstream binaries whenever possible, only they are 100% compatible to native toolchains/run-time, use upstream source whenever possible to minimize the risk of producing incompatible toolchains.
Ralf
Brendan Conoboy wrote:
<snip>
Generally, I think Hans and the rest at http://fedoraproject.org/wiki/SIGs/Embedded have the right idea here. Prefixing the target name to the package is a good plan for most crosses. More fully, I see 3 options:
<snip>
- One srpm which generates packages for a single cross, like Hans's
arm-gp2x-linux-package effort
<shameless plug>
I keep seeing my name mentioned here, but unfortunately I'm receiving little feedback on my arm-gp2x-linux review tickets. Which is a bit of a shame as I spend a lot of time on getting gcc for linux+glibc to build and install inside a buildroot and getting this right, as is needed for proper rpm / mock building. Luckily I eventually found that Mandrake is already doing cross building of most of the distro, and their gcc comes with a patch to make --with-build-sysroot work for this.
So does the lack of feedback mean that my SPECS are good? Or do people just not have the time to look at / review them?
</shameless plug>
Regards,
Hans
On Wed, 2007-06-13 at 09:11 +0200, Hans de Goede wrote:
I keep seeing my name mentioned here, but unfortunately I'm receiving little feedback on my arm-gp2x-linux review tickets. Which is a bit of a shame as I spend a lot of time on getting gcc for linux+glibc to build and install inside a buildroot and getting this right, as is needed for proper rpm / mock building. Luckily I eventually found that Mandrake is already doing cross building of most of the distro, and their gcc comes with a patch to make --with-build-sysroot work for this.
So does the lack of feedback mean that my SPECS are good? Or do people just not have the time to look at / review them?
Wrt. me it's more the latter.
More precisely, unlike with your avr-toolchain (which I reviewed/am reviewing), which resemble very much to my toolchains (i.e. I knew about potential issues in advance), I am not familiar with glibc's details.
A detail inside of your specs causing me head-ache is the "bootstrap" stuff. I am not yet convinced this to be "the right thing(tm)".
Ralf
Ralf Corsepius wrote:
On Wed, 2007-06-13 at 09:11 +0200, Hans de Goede wrote:
I keep seeing my name mentioned here, but unfortunately I'm receiving little feedback on my arm-gp2x-linux review tickets. Which is a bit of a shame as I spend a lot of time on getting gcc for linux+glibc to build and install inside a buildroot and getting this right, as is needed for proper rpm / mock building. Luckily I eventually found that Mandrake is already doing cross building of most of the distro, and their gcc comes with a patch to make --with-build-sysroot work for this.
So does the lack of feedback mean that my SPECS are good? Or do people just not have the time to look at / review them?
Wrt. me it's more the latter.
More precisely, unlike with your avr-toolchain (which I reviewed/am reviewing), which resemble very much to my toolchains (i.e. I knew about potential issues in advance), I am not familiar with glibc's details.
I understand, thanks for the clarification.
A detail inside of your specs causing me head-ache is the "bootstrap" stuff. I am not yet convinced this to be "the right thing(tm)".
Afaik when it comes to linux-glibc details its the only way, notice that bootstrap=1 will be needed only once, but I though it would be good to have configurable in the spec, becaue maybe oneday with a new binutils /glibc it might be a good idea to redo from start.
Regards,
Hans
Hans de Goede wrote:
Afaik when it comes to linux-glibc details its the only way, notice that bootstrap=1 will be needed only once, but I though it would be good to have configurable in the spec, becaue maybe oneday with a new binutils /glibc it might be a good idea to redo from start.
Without some gcc surgery, it is indeed the only way. This is what dwmw2 is trying to talk about and I am trying to artfully avoid :-)
On Wed, 2007-06-13 at 09:16 -0600, Brendan Conoboy wrote:
Hans de Goede wrote:
Afaik when it comes to linux-glibc details its the only way, notice that bootstrap=1 will be needed only once, but I though it would be good to have configurable in the spec, becaue maybe oneday with a new binutils /glibc it might be a good idea to redo from start.
Without some gcc surgery, it is indeed the only way. This is what dwmw2 is trying to talk about and I am trying to artfully avoid :-)
Nah, wrt. to cross linux toolchains there are other ways.
1. If a native target distro exists, one can repackage the target's glibc binaries into a <target>-sys-root rpm, and then build gcc against this glibc. It's what I do in my toolchain packages. Some people hate it because "I don't build everything from scratch", but it has tremendous advantages.
2. The approach dwmw2 seems to hate is the nominal way to build gcc (build a --with-newlib c-only gcc, use this to build glibc, then rebuild a full fledged gcc)
3. Build incrementally. All you need to is to once insert a glibc sys-root binary into the buildsystem (by "bootstrap" or 1. or 2.), then subsequently build gcc and glibc from source. Some people also hate this, but it's essentally the same approach as glibc and gcc are being built on Fedora.
Ralf
Ralf Corsepius wrote:
Nah, wrt. to cross linux toolchains there are other ways.
Well, if you want to be pedantic, sure. To be more precise, it is, at present, the only way to get from nothing but sources to having fully functional binaries. If you already have binaries that's another matter.
- If a native target distro exists, one can repackage the target's
glibc binaries into a <target>-sys-root rpm, and then build gcc against this glibc. It's what I do in my toolchain packages. Some people hate it because "I don't build everything from scratch", but it has tremendous advantages.
You can, but you end up with binaries for one arch inside an rpm designated for another. I'm hoping to take this to the point where you can bring in rpms from one arch to cross build another another. This makes a mismatched target-sys-root rpm very undesirable as it's going in the wrong direction. The target sys-root should be provided by the build system for use by the the cross compiler.
- Build incrementally. All you need to is to once insert a glibc
sys-root binary into the buildsystem (by "bootstrap" or 1. or 2.), then subsequently build gcc and glibc from source. Some people also hate this, but it's essentally the same approach as glibc and gcc are being built on Fedora.
I think of this as The Fedora Way (tm). After discussing with dwmw2 some more, there are still some drawbacks wrt gcc for my own goals: We actually want to produce gcc support libraries for the target in an rpm for the target arch. If there is indeed a strong resistance to having rpm emit multiple arches from a single build, two builds are required (One to make the cross compiler, another to make the target libraries perhaps in the form a cross compiled cross compiler:-). Though not insurmountable, it does mean duplicate copies of the target libraries- one for the host to use, one for the native.
On Wed, 2007-06-13 at 15:46 -0600, Brendan Conoboy wrote:
Ralf Corsepius wrote:
Nah, wrt. to cross linux toolchains there are other ways.
Well, if you want to be pedantic, sure. To be more precise, it is, at present, the only way to get from nothing but sources to having fully functional binaries. If you already have binaries that's another matter.
- If a native target distro exists, one can repackage the target's
glibc binaries into a <target>-sys-root rpm, and then build gcc against this glibc. It's what I do in my toolchain packages. Some people hate it because "I don't build everything from scratch", but it has tremendous advantages.
You can, but you end up with binaries for one arch inside an rpm designated for another.
Not quite. You end up with the target's sys-root's files ("target binaries", blobs of arbitrary binary data) inside of a "noarch" rpm.
I'm hoping to take this to the point where you can bring in rpms from one arch to cross build another another.
You can. sys-root packages aiming at cross-compilers are "noarch" rpms to the host.
- Build incrementally. All you need to is to once insert a glibc
sys-root binary into the buildsystem (by "bootstrap" or 1. or 2.), then subsequently build gcc and glibc from source. Some people also hate this, but it's essentally the same approach as glibc and gcc are being built on Fedora.
I think of this as The Fedora Way (tm).
Right, this way should be applicable for Fedora->Fedora toolchains. However, it is more generally applicable.
After discussing with dwmw2 some more, there are still some drawbacks wrt gcc for my own goals: We actually want to produce gcc support libraries for the target in an rpm for the target arch.
Well, IMO this plan is not useful and doesn't fit into the working principles of rpm, because it confuses host architecture with target architecture.
What I could envision to be made functional is a wrapper around rpm, using another "per-cross-target" rpmdb to add native target rpms into sys-roots.
Ralf
Ralf Corsepius wrote:
Not quite. You end up with the target's sys-root's files ("target binaries", blobs of arbitrary binary data) inside of a "noarch" rpm.
Er, if you're building an arm-linux toolchain and store the sysroot in a noarch rpm, that's still wrong arch :-) Not *as* wrong as having it in an RPM for the build host's arch, but not as right as having it for the target arch.
Well, IMO this plan is not useful and doesn't fit into the working principles of rpm, because it confuses host architecture with target architecture.
Eh?
What I could envision to be made functional is a wrapper around rpm, using another "per-cross-target" rpmdb to add native target rpms into sys-roots.
If I understand you correctly, that sounds about right. When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote:
Ralf Corsepius wrote:
Not quite. You end up with the target's sys-root's files ("target binaries", blobs of arbitrary binary data) inside of a "noarch" rpm.
Er, if you're building an arm-linux toolchain and store the sysroot in a noarch rpm, that's still wrong arch :-)
Why? To the host, a target's binaries are non-executable, host-independent blobs of binary data (==arch).
Not *as* wrong as having it in an RPM for the build host's arch, but not as right as having it for the target arch.
That's right.
But consider: a cross-toolchain is an ordinary (host) native application, accessing target-files as ordinary data files when its is executed.
I.e. a <target>-gcc running on <host> accessing the target's libc basically does the same as a GUI application loading a *.png.
Well, IMO this plan is not useful and doesn't fit into the working principles of rpm, because it confuses host architecture with target architecture.
Eh?
Let me try to elaborate: You want to mix different archs inside of the host's rpmdb.
This doesn't harmonize with current rpm/rpmdb's concepts, because rpm/rpmdb doesn't have a concept of "targets".
All it has is "host-independent" (==noarch) and "host-dependent" (==<arch>)
What I could envision to be made functional is a wrapper around rpm, using another "per-cross-target" rpmdb to add native target rpms into sys-roots.
If I understand you correctly, that sounds about right.
I noticed some mails outlining similar thoughts had crossed when writing the sentence above :)
What I had in mind was to "installing foreign rpms" onto a secondary "target rpmdb" and to reuse them for cross-compilers:
Very oversimplified, this would mean to install target-rpms into a separate rpm-based "root" with it's own rpmdb, similar to this:
/usr/bin/<target>-gcc /var/lib/rpm/ <--- "host rpmdb" ... /usr/share/<target>/sys-root/var/lib/rpm <--- "target rpmdb".
In this example, target files administered inside of the "target rpmdb" would be used for applications administered inside of the "host rpmdb".
rpm-wise the working principle probably would be very similar to that of how mock and mach setup their chroots.
When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
Well, I question the "need", but consider this kind of implementation to be "an option".
Ralf
Ralf Corsepius wrote:
On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote:
Ralf Corsepius wrote:
Not quite. You end up with the target's sys-root's files ("target binaries", blobs of arbitrary binary data) inside of a "noarch" rpm.
Er, if you're building an arm-linux toolchain and store the sysroot in a noarch rpm, that's still wrong arch :-)
Why? To the host, a target's binaries are non-executable, host-independent blobs of binary data (==arch).
Not *as* wrong as having it in an RPM for the build host's arch, but not as right as having it for the target arch.
That's right.
But consider: a cross-toolchain is an ordinary (host) native application, accessing target-files as ordinary data files when its is executed.
Yep clearly a cross compiler that runs on an i386 host and emits ARM or any other target code is an i386 app destined for installation on i386 boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm.
What I could envision to be made functional is a wrapper around rpm, using another "per-cross-target" rpmdb to add native target rpms into sys-roots.
If I understand you correctly, that sounds about right.
I noticed some mails outlining similar thoughts had crossed when writing the sentence above :)
Agreement is usually a good sign :-)
When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
Well, I question the "need", but consider this kind of implementation to be "an option".
It can be necessary though, for example if the package build wants yacc or bison or whatever to build, with cross building they are going to be host yacc and bison despite you are building for a different target arch -- it should go look in the host rpmdb to confirm they are available. But if it wants libsomething-devel to build, because it knows it will be compiling against it, it is talking about the target arch libsomething-devel that it wants to see installed in the arch chroot rpmdb. The only full answer I can think of is to improve rpmbuild and the BuildRequires syntax to allow, eg, yacc.host to be specified and to have it check in the right rpmdb, the cheap dirty answer is to ignore the build requires for cross and wait for the build error.
Another idea, I think fakeroot would be super good for accessing the target arch chroots. For example that way your build user can automate refresh of the libs and -devel stuff in the chroot, ie, you rebuild libblah for a traget arch, and after a successful build libblah.arch and libblah-devel.arch are rpm -Uvf'd into the arch chroot using fakeroot as part of a cross build script, without needing true root.
-Andy
On Fri, 2007-06-15 at 07:01 +0100, Andy Green wrote:
Ralf Corsepius wrote:
On Thu, 2007-06-14 at 11:53 -0600, Brendan Conoboy wrote:
Ralf Corsepius wrote:
Not quite. You end up with the target's sys-root's files ("target binaries", blobs of arbitrary binary data) inside of a "noarch" rpm.
Er, if you're building an arm-linux toolchain and store the sysroot in a noarch rpm, that's still wrong arch :-)
Why? To the host, a target's binaries are non-executable, host-independent blobs of binary data (==arch).
Typo: s/arch/noarch/
Not *as* wrong as having it in an RPM for the build host's arch, but not as right as having it for the target arch.
That's right.
But consider: a cross-toolchain is an ordinary (host) native application, accessing target-files as ordinary data files when its is executed.
Yep clearly a cross compiler that runs on an i386 host and emits ARM or any other target code is an i386 app destined for installation on i386 boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm.
I prefer using <target>-gcc-*.i386.rpm
If sys-rooting such a toolchain, it's toolchain's target-libs could be packaged into a <target>-sys-root-*.noarch.rpm
Due to rpm's limitations, this isn't easy to implement with "one-tree style builts" (building GCC and libc in one build run) of a toolchain, but it is pretty straight forward, when repackaging target-library binaries or building a toolchain incrementally.
When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
Well, I question the "need", but consider this kind of implementation to be "an option".
It can be necessary though, for example if the package build wants yacc or bison or whatever to build, with cross building they are going to be host yacc and bison despite you are building for a different target arch
If I understand you correctly the problem you are referring to is separating "tools being used at build-time on the host" from "tools being used at run-time on the target". (Classic situation: building inserts hard-coded directories/paths referring to files on the build-host into target-files)
Yes, this is a problem. I am not aware about a general solution nor do I have solution, either.
-- it should go look in the host rpmdb to confirm they are available. But if it wants libsomething-devel to build, because it knows it will be compiling against it, it is talking about the target arch libsomething-devel that it wants to see installed in the arch chroot rpmdb. The only full answer I can think of is to improve rpmbuild and the BuildRequires syntax to allow, eg, yacc.host to be specified and to have it check in the right rpmdb, the cheap dirty answer is to ignore the build requires for cross and wait for the build error.
This is a different problem, it's cross-"rpmbuild-ing" target-native-rpms. The result would be a *.<target>.rpm.
What I am doing is aiming at cross-building target-binaries, not target packages/rpms.
Another idea, I think fakeroot would be super good for accessing the target arch chroots. For example that way your build user can automate refresh of the libs and -devel stuff in the chroot, ie, you rebuild libblah for a traget arch, and after a successful build libblah.arch and libblah-devel.arch are rpm -Uvf'd into the arch chroot using fakeroot as part of a cross build script, without needing true root.
Ralf
Ralf Corsepius wrote:
Yep clearly a cross compiler that runs on an i386 host and emits ARM or any other target code is an i386 app destined for installation on i386 boxes, it would be something like gcc-arm5-linux-4.2-123.i386.rpm.
I prefer using <target>-gcc-*.i386.rpm
Well it's not important to me either way sounds good.
Due to rpm's limitations, this isn't easy to implement with "one-tree style builts" (building GCC and libc in one build run) of a toolchain, but it is pretty straight forward, when repackaging target-library binaries or building a toolchain incrementally.
When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
Well, I question the "need", but consider this kind of implementation to be "an option".
It can be necessary though, for example if the package build wants yacc or bison or whatever to build, with cross building they are going to be host yacc and bison despite you are building for a different target arch
If I understand you correctly the problem you are referring to is separating "tools being used at build-time on the host" from "tools being used at run-time on the target". (Classic situation: building inserts hard-coded directories/paths referring to files on the build-host into target-files)
No the issue I (and Brendan I believe) am talking about is, "BuildRequires... required where?". Consider
BuildRequires: yacc libblah-devel
rpmbuild should go and confirm that the packages mentioned here are installed before doing the build.
The issue is that for cross, it has to go and check that yacc is installed in the *host* rpmdb, and that libblah-devel is installed in the *arch chroot* rpmdb. The reason is that yacc is going to get executed on the host as part of the build action, but libblah-devel is going to get linked against in the target arch chroot world.
It's therefore not useful if you have a host version of libblah-devel installed or you have a target arch version of yacc installed in the arch chroot.
At the moment there is no way to differentiate between these two kind of Build requirements, I propose a full solution is
BuildRequires: yacc.host libblah-devel
and rpmbuild is enhanced to check in the right rpmdb accordingly.
A cheap and dirty solution is to ignore BuildRequires completely when the target arch != host arch and you will find out if there is a problem from build errors... hm I guess ./configure might be too smart if there are missing libs though and just turn stuff off without errors... hm...
Yes, this is a problem. I am not aware about a general solution nor do I have solution, either.
-- it should go look in the host rpmdb to confirm they are available. But if it wants libsomething-devel to build, because it knows it will be compiling against it, it is talking about the target arch libsomething-devel that it wants to see installed in the arch chroot rpmdb. The only full answer I can think of is to improve rpmbuild and the BuildRequires syntax to allow, eg, yacc.host to be specified and to have it check in the right rpmdb, the cheap dirty answer is to ignore the build requires for cross and wait for the build error.
This is a different problem, it's cross-"rpmbuild-ing" target-native-rpms. The result would be a *.<target>.rpm.
What I am doing is aiming at cross-building target-binaries, not target packages/rpms.
I assume this was a misunderstanding of what I was describing above (or perhaps I can say the fruit of my not explaining it well enough).
-Andy
On Fri, 2007-06-15 at 08:25 +0100, Andy Green wrote:
Ralf Corsepius wrote:
When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
Well, I question the "need", but consider this kind of implementation to be "an option".
It can be necessary though, for example if the package build wants yacc or bison or whatever to build, with cross building they are going to be host yacc and bison despite you are building for a different target arch
If I understand you correctly the problem you are referring to is separating "tools being used at build-time on the host" from "tools being used at run-time on the target". (Classic situation: building inserts hard-coded directories/paths referring to files on the build-host into target-files)
No the issue I (and Brendan I believe) am talking about is, "BuildRequires... required where?". Consider
BuildRequires: yacc libblah-devel
Understood.
rpmbuild should go and confirm that the packages mentioned here are installed before doing the build.
Hmm, difficult.
One would have find a way to map "native BuildRequires" into * build-requires on "build-tools" on the host (e.g. to translate BR: gcc => <target>-gcc) * cross-host's target-link-library build-requires (E.g. to translate BR: libncurses-devel => <target>-libncurses-devel).
The issue is that for cross, it has to go and check that yacc is installed in the *host* rpmdb, and that libblah-devel is installed in the *arch chroot* rpmdb. The reason is that yacc is going to get executed on the host as part of the build action, but libblah-devel is going to get linked against in the target arch chroot world.
It's therefore not useful if you have a host version of libblah-devel installed or you have a target arch version of yacc installed in the arch chroot.
Right.
At the moment there is no way to differentiate between these two kind of Build requirements, I propose a full solution is
BuildRequires: yacc.host libblah-devel
and rpmbuild is enhanced to check in the right rpmdb accordingly.
Hmm, ...
A cheap and dirty solution is to ignore BuildRequires completely when the target arch != host arch and you will find out if there is a problem from build errors...
Wrt. Fedora->Fedora there probably is simpler "hack": Treat BuildRequires as identical on target and on host => install them both.
hm I guess ./configure might be too smart if there are missing libs though and just turn stuff off without errors... hm...
Yes, such cases exist.
One classical case is configure --build=<host> --host=<target> and not having a <host>-><target>-gcc installed.
The standard autoconf checks will then fall back to using the native tools. Depending on a package's details the result will either be building for the wrong architecture, or a package bombing out somewhere midst building.
What I am doing is aiming at cross-building target-binaries, not target packages/rpms.
I assume this was a misunderstanding of what I was describing above (or perhaps I can say the fruit of my not explaining it well enough).
Seems so :)
Ralf
Ralf Corsepius wrote:
On Fri, 2007-06-15 at 08:25 +0100, Andy Green wrote:
Ralf Corsepius wrote:
When cross building you need to pull in a mixture of native (host-arch) and cross (target arch) packages to meet the build dependencies. This is part of where the "fun" is.
Well, I question the "need", but consider this kind of implementation to be "an option".
It can be necessary though, for example if the package build wants yacc or bison or whatever to build, with cross building they are going to be host yacc and bison despite you are building for a different target arch
If I understand you correctly the problem you are referring to is separating "tools being used at build-time on the host" from "tools being used at run-time on the target". (Classic situation: building inserts hard-coded directories/paths referring to files on the build-host into target-files)
No the issue I (and Brendan I believe) am talking about is, "BuildRequires... required where?". Consider
BuildRequires: yacc libblah-devel
Understood.
rpmbuild should go and confirm that the packages mentioned here are installed before doing the build.
Hmm, difficult.
The problem is actually a bit worse than that. bison and flex are actually required for the host *and* target. You need the host version for the actual bison/flex executable and you need the target version for the static library both typically include.
I used to be part of Brendan's group. Here's how we solved this problem in the past (they might have changed things since I last looked).
Assume a package that originally has the following line for native compiles:
BuildPrereq: autoconf, bison, flex, libblah-devel, sed
For cross compiles we change it to look like this:
%if "%{_arch}" == %{_build_arch} BuildPrereq: autoconf, bison, flex, libblah-devel, sed %else BuildPrereq: bison, flex, libblah-devel %endif%
Note that we leave things so that native compiles still work. We then check native dependencies (_arch == _build_arch) against our mock chroot's native rpm database, then check cross dependencies (_arch != _build_arch) against the mock chroot's target rpm database.
Target versions of autoconf and sed aren't needed since nothing links against anything in those packages (those packages are only run natively). The only problem with this scheme is that we end up with an extra native dependency of libblah-devel (which really isn't needed since nothing links against it in the cross compile). But the benefit of unaffected native compiles outweighed the extra dependency.
On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote:
Note that we leave things so that native compiles still work. We then check native dependencies (_arch == _build_arch) against our mock chroot's native rpm database, then check cross dependencies (_arch != _build_arch) against the mock chroot's target rpm database.
Target versions of autoconf and sed aren't needed since nothing links against anything in those packages (those packages are only run natively). The only problem with this scheme is that we end up with an extra native dependency of libblah-devel (which really isn't needed since nothing links against it in the cross compile). But the benefit of unaffected native compiles outweighed the extra dependency.
I might go so far as to suggest that the benefit of avoiding that %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh the extra dependencies on autoconf and sed, too.
One way of handling dependencies in mock for cross-builds might be to install the full set of dependencies for _both_ host and target architectures.
On Fri, 2007-06-15 at 14:20 +0100, David Woodhouse wrote:
On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote:
Note that we leave things so that native compiles still work. We then check native dependencies (_arch == _build_arch) against our mock chroot's native rpm database, then check cross dependencies (_arch != _build_arch) against the mock chroot's target rpm database.
Target versions of autoconf and sed aren't needed since nothing links against anything in those packages (those packages are only run natively). The only problem with this scheme is that we end up with an extra native dependency of libblah-devel (which really isn't needed since nothing links against it in the cross compile). But the benefit of unaffected native compiles outweighed the extra dependency.
I might go so far as to suggest that the benefit of avoiding that %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh the extra dependencies on autoconf and sed, too.
ACK, esp. because "%_arch and %_build_arch", aren't the correct defines to use. They should be %_host and %target.
One way of handling dependencies in mock for cross-builds might be to install the full set of dependencies for _both_ host and target architectures.
Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"?
e.g. to run rpm -i -r /usr/share/<target>/var/lib/rpm xxx.sparc.rpm on non-sparc systems?
Ralf
Ralf Corsepius wrote:
Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"?
e.g. to run rpm -i -r /usr/share/<target>/var/lib/rpm xxx.sparc.rpm on non-sparc systems?
Sure. I believe we used the '--root PATH' feature of rpm.
On Fri, 2007-06-15 at 08:42 -0500, David Smith wrote:
Ralf Corsepius wrote:
Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"?
e.g. to run rpm -i -r /usr/share/<target>/var/lib/rpm xxx.sparc.rpm on non-sparc systems?
Sure. I believe we used the '--root PATH' feature of rpm.
How about scriptlets?
One could try to run the host tools with paths altered, but ...
Ralf
Ralf Corsepius wrote:
On Fri, 2007-06-15 at 08:42 -0500, David Smith wrote:
Ralf Corsepius wrote:
Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"?
e.g. to run rpm -i -r /usr/share/<target>/var/lib/rpm xxx.sparc.rpm on non-sparc systems?
Sure. I believe we used the '--root PATH' feature of rpm.
How about scriptlets?
One could try to run the host tools with paths altered, but ...
We just ran with '--noscripts' for cross rpms when installing build dependencies (if I remember correctly). Probably more than %90 of build dependencies (libfoo-devel) just run ldconfig, which isn't needed for link purposes.
On Fri, 2007-06-15 at 08:54 -0500, David Smith wrote:
We just ran with '--noscripts' for cross rpms when installing build dependencies (if I remember correctly). Probably more than %90 of build dependencies (libfoo-devel) just run ldconfig, which isn't needed for link purposes.
Hm. Would be it be sensible for us to use --noscripts to speed up mock/koji builds? And just run ldconfig once before actually starting the build?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ralf Corsepius wrote:
On Fri, 2007-06-15 at 08:42 -0500, David Smith wrote:
Ralf Corsepius wrote:
Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"?
e.g. to run rpm -i -r /usr/share/<target>/var/lib/rpm xxx.sparc.rpm on non-sparc systems?
Sure. I believe we used the '--root PATH' feature of rpm.
How about scriptlets?
One could try to run the host tools with paths altered, but ...
We actually do that.
When composing a rootfs from a bag of target rpms, we extract the %pre's, move the 'binaries' directories (bin, lib, ...) in the target rootfs to <name>.save, symlink in the host equivalents, run the scriptlets, undo the moves, do an rpm install with --noscripts, extract the %posts, move off the binaries, link in the hosts, run the posts, undo the moves.
Surprisingly effective for 90% or more of scriptlets, since most of them just modify a data file.
Of course this is Python wrapper code that utilized the RPM module to pull scriptlets, etc.
Clark
Ralf Corsepius rc040203@freenet.de writes:
On Fri, 2007-06-15 at 14:20 +0100, David Woodhouse wrote: Is rpm able to install arbitrary "foreign arch'ed rpms" to a non-default "rpmroot"?
e.g. to run rpm -i -r /usr/share/<target>/var/lib/rpm xxx.sparc.rpm on non-sparc systems?
Yes, with --noscripts as mentioned elsewhere.
I posted a patch to Yum the other day that adds cross-arch build installs. The patch needs to be reworked some so people don't try to use it to do, say, cross-arch NFS root installs, which do need the scripts to run natively or some other solution ultimately.
Also posted were patches to mock to support building a target filesystem and cross-tools root. I'm updating this to current mock and some suggested cleanups.
I mis-posted the earlier patch notice so people probably didn't see it, https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01716.html
The patch does not address BuildRequires but my thought was to go with the approach suggested here: BuildRequires is the target native build requirements and a new header or other way to give HostBuildRequires, if different.
-- Ken
David Woodhouse wrote:
On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote:
Note that we leave things so that native compiles still work. We then check native dependencies (_arch == _build_arch) against our mock chroot's native rpm database, then check cross dependencies (_arch != _build_arch) against the mock chroot's target rpm database.
Target versions of autoconf and sed aren't needed since nothing links against anything in those packages (those packages are only run natively). The only problem with this scheme is that we end up with an extra native dependency of libblah-devel (which really isn't needed since nothing links against it in the cross compile). But the benefit of unaffected native compiles outweighed the extra dependency.
I might go so far as to suggest that the benefit of avoiding that %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh the extra dependencies on autoconf and sed, too.
One way of handling dependencies in mock for cross-builds might be to install the full set of dependencies for _both_ host and target architectures.
I certainly see your point, but when bootstrapping an arch you sometimes get in these cases where X requires Y which requires Z which requires X, so you have to start chopping requires down to the minimal.
Plus, if a native require is for something quite complicated like perl or python, you typically want to postpone that pain for as long as possible...
On Fri, 2007-06-15 at 08:38 -0500, David Smith wrote:
I certainly see your point, but when bootstrapping an arch you sometimes get in these cases where X requires Y which requires Z which requires X, so you have to start chopping requires down to the minimal.
For bootstrapping, yes. But that mess doesn't see the light of day -- by the time you get close to applying to become a secondary architecture for Fedora, that should all be a thing of the past.
Plus, if a native require is for something quite complicated like perl or python, you typically want to postpone that pain for as long as possible...
Again, you're talking about the initial bootstrap. In which case ignore me -- I wasn't thinking about that.
David Woodhouse wrote:
On Fri, 2007-06-15 at 07:59 -0500, David Smith wrote:
Note that we leave things so that native compiles still work. We then check native dependencies (_arch == _build_arch) against our mock chroot's native rpm database, then check cross dependencies (_arch != _build_arch) against the mock chroot's target rpm database.
Target versions of autoconf and sed aren't needed since nothing links against anything in those packages (those packages are only run natively). The only problem with this scheme is that we end up with an extra native dependency of libblah-devel (which really isn't needed since nothing links against it in the cross compile). But the benefit of unaffected native compiles outweighed the extra dependency.
I might go so far as to suggest that the benefit of avoiding that %if "%{_arch" == "%{_build_arch}" stuff in the specfile might outweigh the extra dependencies on autoconf and sed, too.
One way of handling dependencies in mock for cross-builds might be to install the full set of dependencies for _both_ host and target architectures.
I would be the first to reach for a dirty but unanswerably effective hack to get me where I am going... But in this case I think the only true answer is to tag BuildRequires as being host or target in the spec file, not to unmanageably duplicate the target-world dependencies in the host. Eg
HostBuildRequires: byacc (<-- for it is he) BuildRequires: libblah-devel
...where they are considered the same deal when hostArch == buildArch.
We can see if this logic raises objections anywhere given the effective forkage of rpm but I suspect it is a basic fact necessary for cross to work in rpm semantics.
-Andy
Andy Green wrote:
I would be the first to reach for a dirty but unanswerably effective hack to get me where I am going... But in this case I think the only true answer is to tag BuildRequires as being host or target in the spec file, not to unmanageably duplicate the target-world dependencies in the host. Eg
HostBuildRequires: byacc (<-- for it is he) BuildRequires: libblah-devel
...where they are considered the same deal when hostArch == buildArch.
Or TargetBuildRequires. Either way it's invasive and should be avoided if it can be worked around. You really want the build system to do as much as it can so you don't impact package maintainers unless absolutely necessary.
We can see if this logic raises objections anywhere given the effective forkage of rpm but I suspect it is a basic fact necessary for cross to work in rpm semantics.
Forkage?
Brendan Conoboy wrote:
Andy Green wrote:
I would be the first to reach for a dirty but unanswerably effective hack to get me where I am going... But in this case I think the only true answer is to tag BuildRequires as being host or target in the spec file, not to unmanageably duplicate the target-world dependencies in the host. Eg
HostBuildRequires: byacc (<-- for it is he) BuildRequires: libblah-devel
...where they are considered the same deal when hostArch == buildArch.
Or TargetBuildRequires. Either way it's invasive and should be avoided if it can be worked around. You really want the build system to do as much as it can so you don't impact package maintainers unless absolutely necessary.
Yep, it is invasive but it is also defensible I think. It's the kind of thing that could be patched into the specfile at buildtime per-arch if that is what ends up happening.
But here's an alternative Heuristic that isn't as reliable but might cope and has no specfile footprint
1) Package is called lib* or *-devel? goto 8
2) Check build host rpmdb
3) If present, check if any of the files in the package match /usr/lib/*.so or /usr/lib/*.a or /usr/include/*... if not, consider it present, else...
4) Check target arch rpmdb
5) If absent, goto 7
6) check if any of the files in the package match /usr/lib/*.so or /usr/lib/*.a or /usr/include/*... if so, consider it present, else...
7) error out with "package not installed on build host" (it didn't have a footprint in /usr/lib or /usr/include, take as a host utility)
8) Check target arch rpmdb
9) if absent, error out with "package not installed for $arch"
10) consider it present
-Andy
We can see if this logic raises objections anywhere given the effective forkage of rpm but I suspect it is a basic fact necessary for cross to work in rpm semantics.
Forkage?
There's rpm5.org and there's rpm.org trees now. If it was the plan to add a new spec keyword, one would want it to be globally accepted and not become one tree's special sauce.
-Andy
Ralf Corsepius wrote:
I prefer using <target>-gcc-*.i386.rpm
Likewise.
If sys-rooting such a toolchain, it's toolchain's target-libs could be packaged into a <target>-sys-root-*.noarch.rpm
To add a little granularity to the discussion, I'm going to point out that there are (at least) two camps of people who want cross compilers in Fedora:
1) Those who want cross compilers for nifty gadgets, generally not running Linux at all. Having a <target>-sys-root-*.noarch.rpm such as Ralf suggests makes sense in this context.
2) Those who want cross compilers that target other linux architectures such as arm, ppc, s390, etc. Having a <target>-sys-root-*.noarch.rpm does not make sense in this context. That is because you want to work with and make packages for your target arch rather than nebulous binary blobs.
I'm particularly interested in #2, but believe Fedora can accommodate both. It's also a logical line along which to split package maintainership duties since the tools in question are used for such very different purposes.
What I am doing is aiming at cross-building target-binaries, not target packages/rpms.
Yep. Ok, I concede your noarch binary blob answer for non-linux targets.
Ralf Corsepius wrote:
Why? To the host, a target's binaries are non-executable, host-independent blobs of binary data (==arch).
I see where you're coming from here, but can't quite agree. For the greater purpose of cross compilation discussion, I'll leave it there for now.
Let me try to elaborate: You want to mix different archs inside of the host's rpmdb.
Yes, definitely a place the build system has to intervene.
[snip]
rpm-wise the working principle probably would be very similar to that of how mock and mach setup their chroots.
Yes, in-fact, leveraging mock is going to a key to cross building bliss.
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
You can do that, but it's a bad idea. Since glibc is a moving target, libgcc's configurey might not turn on something that is valid because it can't detect the support for it. That's why we have the two stage process to begin with.
Or do we even need to build the dynamic libgcc _with_ the compiler at all?
Need? Depends on what you're willing to put into it...
Actually it happens for me every time I build a cross-compiler. But perhaps it doesn't _need_ to; you're right.
What if you're not building from scratch- instead building iteratively? What if it's in Fedora so you aren't building one in the first place?
That's a very good place to start. Especially if you realise that it doesn't _really_ restrict us to 'existing architectures' -- it restricts us to those architectures for which we can cobble together 'native' packages for gcc, etc. Which is actually not much of a restriction at all.
Yep, seems like an excellent starting point. Especially while gcc is being disentangled.
That would be an interesting answer, yes. It only solves the _build_ part of the problem though. The packaging side remains -- you'll want to end up a cross-compiler package for the host arch, but libgcc etc. for the target.
RPM doesn't currently let you spit out even .noarch.rpm and $ARCH.rpm simultaneously -- to build both i686-linux-gnu-gcc-$V-$R.ppc.rpm and libgcc-$V-$R.i386.rpm you'll almost certainly need a separate rpmbuild run _anyway_. So how will we handle that?
Cross compile the native compiler. You need one anyway. All the resulting packages are target arch. Your cross compiler can then depend on the native compiler's libgcc rpm for the next iteration.
I think we need to accelerate [splitting gcc libs] rather than waiting for it.
The wait might be so long. Libgcc is a subdiectory of gcc in upstream development (to be 4.3).
On Wed, 2007-06-13 at 15:59 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away with a fake DSO which just provides the few symbols libgcc uses?
You can do that, but it's a bad idea. Since glibc is a moving target, libgcc's configurey might not turn on something that is valid because it can't detect the support for it. That's why we have the two stage process to begin with.
You're speaking of the things which libgcc requires from glibc. That really is a _minimal_ set of functions. Is there _anything_ it actually tries to automatically detect -- _anything_ which might be turned off in libgcc because autocrap thinks glibc won't support it?
Or do we even need to build the dynamic libgcc _with_ the compiler at all?
Need? Depends on what you're willing to put into it...
Que?
Actually it happens for me every time I build a cross-compiler. But perhaps it doesn't _need_ to; you're right.
What if you're not building from scratch- instead building iteratively? What if it's in Fedora so you aren't building one in the first place?
Heh, the latter would be nice :)
Cross compile the native compiler. You need one anyway. All the resulting packages are target arch. Your cross compiler can then depend on the native compiler's libgcc rpm for the next iteration.
That works, if we can get the build system issues sorted out. RPM doesn't currently even handle arch-specific dependencies, let alone "I need foo.i386 and I need it in a /usr/i386-linux-gnu chroot" :)
And since you're using the native packages in the sysroot, your cross-compiler package doesn't even need to bother building the shared libraries.
David Woodhouse wrote:
That works, if we can get the build system issues sorted out. RPM doesn't currently even handle arch-specific dependencies, let alone "I need foo.i386 and I need it in a /usr/i386-linux-gnu chroot" :)
Well it does "work" to do rpm --root=/usr/i386-linux-gnu --ignorearch -i foo (although last time I looked I didn't yet find a way to set dbpath on Fedora rpm that worked). If "handling it" in separate chroot worlds is good enough it shows a way forward though, presumably if yum can eat --root= it too will play along nicely in each chroot world.
-Andy
On Wed, 2007-06-13 at 23:53 +0100, Andy Green wrote:
Well it does "work" to do rpm --root=/usr/i386-linux-gnu --ignorearch -i foo (although last time I looked I didn't yet find a way to set dbpath on Fedora rpm that worked). If "handling it" in separate chroot worlds is good enough it shows a way forward though, presumably if yum can eat --root= it too will play along nicely in each chroot world.
Yeah, it's not impossible. Then we just need to let koji/mock know that it must do this when building a cross-compiler...
On Tue, Jun 12, 2007 at 04:31:51PM +0100, David Woodhouse wrote:
As gcc matures, it's likely that the libgcc problem will go away by it being split out. At that time, the chicken/egg problem will be solved without having to resort to clever hacks.
I think we need to accelerate that rather than waiting for it.
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Works fine for me on arm. (One packaging issue with 'as'/'nm', see below.)
Attached is a very hacky patch to the gcc spec file to make it cross build (Fedora -> Fedora.) It requires that you already have glibc and kernel headers installed in your sysroot (/usr/%{_target_platform}). (If you're doing Fedora -> Fedora, presumably you already have glibc packages for the target, which will suffice for bootstrapping.)
There's a couple of issues: - Whereas your binutils patch is pretty clean, I can't really seem to find a way to make the cross changes to the gcc spec file not very intrusive.
I'm starting to wonder whether the gcc cross stuff should just be in a separate spec file. We _do_ want to use exactly the same sources to build the cross-compiler, so maybe the regular gcc package can provide gcc-source, which can then be pulled in by the gcc-cross variant?
- binutils puts as/nm binaries into the sysroot, even though they are host binaries. Your binutils spec patch doesn't package those, which makes sense (I don't fully understand why binutils puts them there to begin with), but gcc insists on being able to invoke the target 'as' as 'as'. I've hacked around that by making /usr/libexec/gcc/$target/$version/as a symlink to $target-as (and the same thing with 'nm'), which seems to work.
- There's also two issues with building libstdc++ -- it doesn't pick up the sysroot info correctly (and subsequently tries to link against the host's /lib/libc.so.6 after reading the target libc.so script in the sysroot), and its install target installs various target files not in the sysroot but in the host's directory space.
Index: SPECS/gcc41.spec =================================================================== --- SPECS.orig/gcc41.spec +++ SPECS/gcc41.spec @@ -1,32 +1,32 @@ +%if "%{?gcc_target}" == "" +%define gcc_target %{_target_platform} +%define isnative 1 +%else +%define isnative 0 +%define cross %{gcc_target}- +%endif + %define DATE 20070503 %define gcc_version 4.1.2 %define gcc_release 12 %define _unpackaged_files_terminate_build 0 %define multilib_64_archs sparc64 ppc64 s390x x86_64 %define include_gappletviewer 1 +%if !%{isnative} +%define build_ada 0 +%else %ifarch %{ix86} x86_64 ia64 ppc alpha %define build_ada 1 %else %define build_ada 0 %endif +%endif %define build_fortran 0 %define build_java 0 %define build_objc 0 %define run_tests 0 -%ifarch s390x -%define multilib_32_arch s390 -%endif -%ifarch sparc64 -%define multilib_32_arch sparc -%endif -%ifarch ppc64 -%define multilib_32_arch ppc -%endif -%ifarch x86_64 -%define multilib_32_arch i386 -%endif Summary: Various compilers (C, C++, Objective-C, Java, ...) -Name: gcc +Name: %{?cross}gcc Version: %{gcc_version} Release: %{gcc_release}.fa1 License: GPL @@ -44,7 +44,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version # Need binutils which support --hash-style=gnu >= 2.17.50.0.2-7 # Need binutils which support mffgpr and mftgpr >= 2.17.50.0.2-8 # Need binutils which support 2-argument .movsp >= 2.17.50.0.5 -BuildRequires: binutils >= 2.17.50.0.5 +BuildRequires: %{?cross}binutils >= 2.17.50.0.5 BuildRequires: zlib-devel, gettext, dejagnu, bison, flex, texinfo, sharutils %if %{build_java} BuildRequires: gcc-java, libgcj, /usr/share/java/eclipse-ecj.jar, zip, unzip @@ -52,7 +52,7 @@ BuildRequires: gcc-java, libgcj, /usr/sh # Make sure pthread.h doesn't contain __thread tokens # Make sure glibc supports stack protector # Make sure glibc supports DT_GNU_HASH -BuildRequires: glibc-devel >= 2.4.90-13 +BuildRequires: %{?cross}glibc-devel >= 2.4.90-13 BuildRequires: elfutils-devel >= 0.72 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double @@ -69,7 +69,7 @@ BuildRequires: gcc-gnat >= 3.1, libgnat %ifarch ia64 BuildRequires: libunwind >= 0.98 %endif -Requires: cpp = %{version}-%{release} +Requires: %{?cross}cpp = %{version}-%{release} # Need .eh_frame ld optimizations # Need proper visibility support # Need -pie support @@ -80,37 +80,39 @@ Requires: cpp = %{version}-%{release} # Need binutils that supports --hash-style=gnu # Need binutils that support mffgpr/mftgpr # Need binutils that support 2-argument .movsp >= 2.17.50.0.5 -Requires: binutils >= 2.17.50.0.5 +Requires: %{?cross}binutils >= 2.17.50.0.5 # Make sure gdb will understand DW_FORM_strp -Conflicts: gdb < 5.1-2 -Requires: glibc-devel >= 2.2.90-12 +Conflicts: %{?cross}gdb < 5.1-2 +Requires: %{?cross}glibc-devel >= 2.2.90-12 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double -Requires: glibc >= 2.3.90-35 +Requires: %{?cross}glibc >= 2.3.90-35 +%endif +Requires: %{?cross}libgcc >= %{version}-%{release} +%if %{isnative} +Requires: %{?cross}libgomp = %{version}-%{release} %endif -Requires: libgcc >= %{version}-%{release} -Requires: libgomp = %{version}-%{release} -Obsoletes: gcc3 -Obsoletes: egcs +Obsoletes: %{?cross}gcc3 +Obsoletes: %{?cross}egcs %ifarch sparc -Obsoletes: gcc-sparc32 -Obsoletes: gcc-c++-sparc32 +Obsoletes: %{?cross}gcc-sparc32 +Obsoletes: %{?cross}gcc-c++-sparc32 %endif %ifarch ppc -Obsoletes: gcc-ppc32 -Obsoletes: gcc-c++-ppc32 +Obsoletes: %{?cross}gcc-ppc32 +Obsoletes: %{?cross}gcc-c++-ppc32 %endif -Obsoletes: gcc-chill +Obsoletes: %{?cross}gcc-chill %if !%{build_ada} -Obsoletes: gcc-gnat < %{version}-%{release} -Obsoletes: libgnat < %{version}-%{release} +Obsoletes: %{?cross}gcc-gnat < %{version}-%{release} +Obsoletes: %{?cross}libgnat < %{version}-%{release} %endif %ifarch sparc sparc64 -Obsoletes: egcs64 +Obsoletes: %{?cross}egcs64 %endif -Obsoletes: gcc34 -Obsoletes: gcc35 -Obsoletes: gcc4 +Obsoletes: %{?cross}gcc34 +Obsoletes: %{?cross}gcc35 +Obsoletes: %{?cross}gcc4 Prereq: /sbin/install-info AutoReq: true
@@ -160,6 +162,7 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch %{arm} %define _gnu %{nil} %endif +%if "%{?gcc_target}" == "" %ifarch sparc %define gcc_target_platform sparc64-%{_vendor}-%{_target_os} %endif @@ -169,17 +172,20 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch sparc ppc %define gcc_target_platform %{_target_platform} %endif +%else +%define gcc_target_platform %{gcc_target} +%endif
%description The gcc package contains the GNU Compiler Collection version 4.1. You'll need this package in order to compile C code.
-%package -n libgcc +%package -n %{?cross}libgcc Summary: GCC version 4.1 shared support library Group: System Environment/Libraries Autoreq: false
-%description -n libgcc +%description -n %{?cross}libgcc This package contains GCC shared support library which is needed e.g. for exception handling support.
@@ -200,18 +206,18 @@ This package adds C++ support to the GNU It includes support for most of the current C++ specification, including templates and exception handling.
-%package -n libstdc++ +%package -n %{?cross}libstdc++ Summary: GNU Standard C++ Library Group: System Environment/Libraries Obsoletes: libstdc++3 Obsoletes: libstdc++34 Autoreq: true
-%description -n libstdc++ +%description -n %{?cross}libstdc++ The libstdc++ package contains a rewritten standard compliant GCC Standard C++ Library.
-%package -n libstdc++-devel +%package -n %{?cross}libstdc++-devel Summary: Header files and libraries for C++ development Group: Development/Libraries Requires: libstdc++ = %{version}-%{release}, %{_prefix}/%{_lib}/libstdc++.so.6 @@ -219,7 +225,7 @@ Obsoletes: libstdc++3-devel Obsoletes: libstdc++34-devel Autoreq: true
-%description -n libstdc++-devel +%description -n %{?cross}libstdc++-devel This is the GNU implementation of the standard C++ libraries. This package includes the header files and libraries needed for C++ development. This includes rewritten implementation of STL. @@ -246,12 +252,12 @@ Autoreq: true %description objc++ gcc-objc++ package provides Objective-C++ support for the GCC.
-%package -n libobjc +%package -n %{?cross}libobjc Summary: Objective-C runtime Group: System Environment/Libraries Autoreq: true
-%description -n libobjc +%description -n %{?cross}libobjc This package contains Objective-C shared library which is needed to run Objective-C dynamically linked programs.
@@ -271,39 +277,39 @@ Autoreq: true The gcc-gfortran package provides support for compiling Fortran 95 programs with the GNU Compiler Collection.
-%package -n libgfortran +%package -n %{?cross}libgfortran Summary: Fortran 95 runtime Group: System Environment/Libraries Obsoletes: libf2c Autoreq: true
-%description -n libgfortran +%description -n %{?cross}libgfortran This package contains Fortran 95 shared library which is needed to run Fortran 95 dynamically linked programs.
-%package -n libgomp +%package -n %{?cross}libgomp Summary: GCC OpenMP 2.5 shared support library Group: System Environment/Libraries
-%description -n libgomp +%description -n %{?cross}libgomp This package contains GCC shared support library which is needed for OpenMP 2.5 support.
-%package -n libmudflap +%package -n %{?cross}libmudflap Summary: GCC mudflap shared support library Group: System Environment/Libraries
-%description -n libmudflap +%description -n %{?cross}libmudflap This package contains GCC shared support library which is needed for mudflap support.
-%package -n libmudflap-devel +%package -n %{?cross}libmudflap-devel Summary: GCC mudflap support Group: Development/Libraries Requires: libmudflap = %{version}-%{release} Requires: gcc = %{version}-%{release}
-%description -n libmudflap-devel +%description -n %{?cross}libmudflap-devel This package contains headers and static libraries for building mudflap-instrumented programs.
@@ -329,7 +335,7 @@ Autoreq: true This package adds support for compiling Java(tm) programs and bytecode into native code.
-%package -n libgcj +%package -n %{?cross}libgcj Summary: Java runtime library for gcc Group: System Environment/Libraries Prereq: /sbin/install-info @@ -352,11 +358,11 @@ Obsoletes: libgcj34 Obsoletes: libgcj4 Autoreq: true
-%description -n libgcj +%description -n %{?cross}libgcj The Java(tm) runtime library. You will need this package to run your Java programs compiled using the Java compiler from GNU Compiler Collection (gcj).
-%package -n libgcj-devel +%package -n %{?cross}libgcj-devel Summary: Libraries for Java development using GCC Group: Development/Languages Requires: libgcj = %{version}-%{release}, %{_prefix}/%{_lib}/libgcj.so.8rh @@ -368,21 +374,21 @@ Obsoletes: libgcj4-devel Autoreq: false Autoprov: false
-%description -n libgcj-devel +%description -n %{?cross}libgcj-devel The Java(tm) static libraries and C header files. You will need this package to compile your Java programs using the GCC Java compiler (gcj).
-%package -n libgcj-src +%package -n %{?cross}libgcj-src Summary: Java library sources from GCC4 preview Group: System Environment/Libraries Requires: libgcj = %{version}-%{release} Obsoletes: libgcj4-src Autoreq: true
-%description -n libgcj-src +%description -n %{?cross}libgcj-src The Java(tm) runtime library sources for use in Eclipse.
-%package -n cpp +%package -n %{?cross}cpp Summary: The C Preprocessor. Group: Development/Languages Prereq: /sbin/install-info @@ -391,7 +397,7 @@ Obsoletes: gnupro %endif Autoreq: true
-%description -n cpp +%description -n %{?cross}cpp Cpp is the GNU C-Compatible Compiler Preprocessor. Cpp is a macro processor which is used automatically by the C compiler to transform your program before actual @@ -425,13 +431,13 @@ Autoreq: true GNAT is a GNU Ada 95 front-end to GCC. This package includes development tools, the documents and Ada 95 compiler.
-%package -n libgnat +%package -n %{?cross}libgnat Summary: GNU Ada 95 runtime shared libraries Group: System Environment/Libraries Obsoletes: gnat libgnat3 Autoreq: true
-%description -n libgnat +%description -n %{?cross}libgnat GNAT is a GNU Ada 95 front-end to GCC. This package includes shared libraries, which are required to run programs compiled with the GNAT.
@@ -511,6 +517,7 @@ if [ -d libstdc++-v3/config/abi/sparc64- rm -rf libstdc++-v3/config/abi/sparc64-linux-gnu/32 fi %endif +find -name configure | xargs sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/'
%build
@@ -583,6 +590,7 @@ case "$OPT_FLAGS" in ../gcc/Makefile.in ;; esac +%if %{isnative} CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="$OPT_FLAGS" XCFLAGS="$OPT_FLAGS" TCFLAGS="$OPT_FLAGS" \ GCJFLAGS="$OPT_FLAGS" \ ../configure --prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \ @@ -632,7 +640,6 @@ CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="$ --host=%{gcc_target_platform} %endif
-#GCJFLAGS="$OPT_FLAGS" make %{?_smp_mflags} BOOT_CFLAGS="$OPT_FLAGS" bootstrap GCJFLAGS="$OPT_FLAGS" make %{?_smp_mflags} BOOT_CFLAGS="$OPT_FLAGS" profiledbootstrap
%if %{run_tests} @@ -663,6 +670,19 @@ rm -rf testlogs-%{_target_platform}-%{ve
# Make protoize make -C gcc CC="./xgcc -B ./ -O2" proto +%else +CC="$CC" CFLAGS="-O2 -g" CXXFLAGS="-O2 -g" XCFLAGS="-O2 -g" TCFLAGS="-O2 -g" \ + GCJFLAGS="-O2 -g" \ + ../configure --prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \ + --enable-shared --enable-threads=posix --enable-checking=release \ + --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions \ + --enable-languages=c --disable-libgcj --disable-libssp \ + --disable-libgomp --disable-libmudflap \ + --with-sysroot=/usr/%{gcc_target_platform} \ + --target=%{gcc_target_platform} + +GCJFLAGS="-O2 -g" make %{?_smp_mflags} BOOT_CFLAGS="-O2 -g" +%endif
# Make generated man pages even if Pod::Man is not new enough perl -pi -e 's/head3/head2/' ../contrib/texi2pod.pl @@ -730,10 +750,10 @@ fi export PATH=`pwd`/java_hacks${PATH:+:$PATH} %endif
-TARGET_PLATFORM=%{gcc_target_platform} - +%if %{isnative} # There are some MP bugs in libstdc++ Makefiles make -C %{gcc_target_platform}/libstdc++-v3 +%endif
make prefix=$RPM_BUILD_ROOT%{_prefix} mandir=$RPM_BUILD_ROOT%{_mandir} \ infodir=$RPM_BUILD_ROOT%{_infodir} install @@ -748,16 +768,26 @@ FULLPATH=$RPM_BUILD_ROOT%{_prefix}/lib/g FULLEPATH=$RPM_BUILD_ROOT%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}
# fix some things +%if %{isnative} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/cc mkdir -p $RPM_BUILD_ROOT/lib ln -sf ..%{_prefix}/bin/cpp $RPM_BUILD_ROOT/lib/cpp +%endif %if %{build_fortran} ln -sf gfortran $RPM_BUILD_ROOT%{_prefix}/bin/f95 %endif rm -f $RPM_BUILD_ROOT%{_infodir}/dir gzip -9 $RPM_BUILD_ROOT%{_infodir}/*.info* +%if %{build_ada} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/gnatgcc +%endif
+%if !%{isnative} +ln -s ../../../../bin/%{gcc_target}-as $FULLEPATH/as +ln -s ../../../../bin/%{gcc_target}-nm $FULLEPATH/nm +%endif + +%if %{isnative} cxxconfig="`find %{gcc_target_platform}/libstdc++-v3/include -name c++config.h`" for i in `find %{gcc_target_platform}/[36]*/libstdc++-v3/include -name c++config.h 2>/dev/null`; do if ! diff -up $cxxconfig $i; then @@ -783,6 +813,7 @@ EOF break fi done +%endif
%ifarch sparc sparc64 ln -f $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-gcc \ @@ -818,11 +849,13 @@ sed -i -e 's/lib: /&%%{static:%%eJava pr $FULLPATH/libgcj.spec %endif
+%if %{isnative} mkdir -p $RPM_BUILD_ROOT/%{_lib} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcc_s.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 chmod 755 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 ln -sf libgcc_s-%{gcc_version}-%{DATE}.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s.so.1 ln -sf /%{_lib}/libgcc_s.so.1 $FULLPATH/libgcc_s.so +%endif %ifarch sparc ppc ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64/libgcc_s.so %endif @@ -830,8 +863,10 @@ ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64 ln -sf /lib/libgcc_s.so.1 $FULLPATH/32/libgcc_s.so %endif
+%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.spec $FULLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/include/omp.h $FULLPATH/include/ +%endif
%if %{build_ada} mv -f $FULLPATH/adalib/libgnarl-*.so $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ @@ -856,16 +891,21 @@ fi
pushd $FULLPATH if [ "%{_lib}" = "lib" ]; then +true %if %{build_objc} ln -sf ../../../libobjc.so.1 libobjc.so %endif +%if %{isnative} ln -sf ../../../libstdc++.so.6.* libstdc++.so +%endif %if %{build_fortran} ln -sf ../../../libgfortran.so.1.* libgfortran.so %endif +%if %{isnative} ln -sf ../../../libgomp.so.1.* libgomp.so ln -sf ../../../libmudflap.so.0.* libmudflap.so ln -sf ../../../libmudflapth.so.0.* libmudflapth.so +%endif %if %{build_java} ln -sf ../../../libgcj.so.8rh.* libgcj.so ln -sf ../../../libgcj-tools.so.8rh.* libgcj-tools.so @@ -883,7 +923,9 @@ else %if %{build_objc} ln -sf ../../../../%{_lib}/libobjc.so.1 libobjc.so %endif +%if %{isnative} ln -sf ../../../../%{_lib}/libstdc++.so.6.* libstdc++.so +%endif %if %{build_fortran} ln -sf ../../../../%{_lib}/libgfortran.so.1.* libgfortran.so %endif @@ -907,8 +949,10 @@ fi %if %{build_java} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcj_bc.so $FULLLPATH/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libstdc++.*a $FULLLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libsupc++.*a . +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortranbegin.*a . @@ -916,21 +960,27 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.*a . %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/include/mf-runtime.h include/ +%endif
%ifarch sparc ppc %if %{build_objc} ln -sf ../../../../../lib64/libobjc.so.1 64/libobjc.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib/libstdc++.so.6.* | sed s~/lib/~/lib64/~` 64/libstdc++.so +%endif %if %{build_fortran} ln -sf ../`echo ../../../../lib/libgfortran.so.1.* | sed s~/lib/~/lib64/~` 64/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib/libgomp.so.1.* | sed s~/lib/~/lib64/~` 64/libgomp.so ln -sf ../`echo ../../../../lib/libmudflap.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflap.so ln -sf ../`echo ../../../../lib/libmudflapth.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib/libgcj.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj.so ln -sf ../`echo ../../../../lib/libgcj-tools.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj-tools.so @@ -938,7 +988,9 @@ ln -sf ../`echo ../../../../lib/libgij.s ln -sf lib32/libgcj_bc.so libgcj_bc.so ln -sf ../lib64/libgcj_bc.so 64/libgcj_bc.so %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libsupc++.*a 64/ +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgfortran.*a 64/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgfortranbegin.*a 64/ @@ -946,29 +998,37 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/li %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libobjc.*a 64/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgomp.*a 64/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libmudflap{,th}.*a 64/ ln -sf lib32/libstdc++.a libstdc++.a ln -sf ../lib64/libstdc++.a 64/libstdc++.a %endif +%endif %ifarch %{multilib_64_archs} mkdir -p 32 %if %{build_objc} ln -sf ../../../../libobjc.so.1 32/libobjc.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib64/libstdc++.so.6.* | sed s~/../lib64/~/~` 32/libstdc++.so +%endif %if %{build_fortran} ln -sf ../`echo ../../../../lib64/libgfortran.so.1.* | sed s~/../lib64/~/~` 32/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib64/libgomp.so.1.* | sed s~/../lib64/~/~` 32/libgomp.so ln -sf ../`echo ../../../../lib64/libmudflap.so.0.* | sed s~/../lib64/~/~` 32/libmudflap.so ln -sf ../`echo ../../../../lib64/libmudflapth.so.0.* | sed s~/../lib64/~/~` 32/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib64/libgcj.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj.so ln -sf ../`echo ../../../../lib64/libgcj-tools.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj-tools.so ln -sf ../`echo ../../../../lib64/libgij.so.8rh.* | sed s~/../lib64/~/~` 32/libgij.so %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libsupc++.*a 32/ +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgfortran.*a 32/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgfortranbegin.*a 32/ @@ -976,21 +1036,41 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libg %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libobjc.*a 32/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgomp.*a 32/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libmudflap{,th}.*a 32/ %endif +%endif %ifarch sparc64 ppc64 +%if %{isnative} ln -sf ../lib32/libstdc++.a 32/libstdc++.a ln -sf lib64/libstdc++.a libstdc++.a +%endif %if %{build_java} ln -sf ../lib32/libgcj_bc.so 32/libgcj_bc.so ln -sf lib64/libgcj_bc.so libgcj_bc.so %endif %else +case %{gcc_target} in + s390x*) + MULTILIB_32_ARCH=s390 + ;; + sparc64*) + MULTILIB_32_ARCH=sparc + ;; + ppc64*) + MULTILIB_32_ARCH=ppc + ;; + x86_64*) + MULTILIB_32_ARCH=i386 + ;; +esac %ifarch %{multilib_64_archs} -ln -sf ../../../%{multilib_32_arch}-%{_vendor}-%{_target_os}/%{gcc_version}/libstdc++.a 32/libstdc++.a +%if %{isnative} +ln -sf ../../../${MULTILIB_32_ARCH}-%{_vendor}-%{_target_os}/%{gcc_version}/libstdc++.a 32/libstdc++.a +%endif %if %{build_java} -ln -sf ../../../%{multilib_32_arch}-%{_vendor}-%{_target_os}/%{gcc_version}/libgcj_bc.so 32/libgcj_bc.so +ln -sf ../../../${MULTILIB_32_ARCH}-%{_vendor}-%{_target_os}/%{gcc_version}/libgcj_bc.so 32/libgcj_bc.so %endif %endif %endif @@ -1003,8 +1083,10 @@ popd %if %{build_fortran} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.so.1.* %endif +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.so.1.* chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.so.0.* +%endif %if %{build_objc} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.so.1.* %endif @@ -1022,7 +1104,11 @@ for h in `find $FULLPATH/include -name \ fi done
+%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c89 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c89 <<"EOF" +%endif #!/bin/sh fl="-std=c89" for opt; do @@ -1034,7 +1120,11 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c99 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c99 <<"EOF" +%endif #!/bin/sh fl="-std=c99" for opt; do @@ -1046,17 +1136,25 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/c?9 +%else +chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c?9 +%endif
+%if %{isnative} %ifnarch %{arm} mkdir -p $RPM_BUILD_ROOT%{_prefix}/sbin gcc -static -Os %{SOURCE1} -o $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade strip $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade %endif +%endif
cd .. +%if %{isnative} %find_lang %{name} %find_lang cpplib +%endif
# Remove binaries we will not be including, so that they don't end up in # gcc-debuginfo @@ -1102,11 +1200,11 @@ if [ $1 = 0 ]; then --info-dir=%{_infodir} %{_infodir}/gcc.info.gz || : fi
-%post -n cpp +%post -n %{?cross}cpp /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || :
-%preun -n cpp +%preun -n %{?cross}cpp if [ $1 = 0 ]; then /sbin/install-info --delete \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || : @@ -1154,48 +1252,53 @@ fi # Because glibc Prereq's libgcc and /sbin/ldconfig # comes from glibc, it might not exist yet when # libgcc is installed -%post -n libgcc -p %{_prefix}/sbin/libgcc_post_upgrade +%post -n %{?cross}libgcc -p %{_prefix}/sbin/libgcc_post_upgrade %endif
-%post -n libstdc++ -p /sbin/ldconfig +%post -n %{?cross}libstdc++ -p /sbin/ldconfig
-%postun -n libstdc++ -p /sbin/ldconfig +%postun -n %{?cross}libstdc++ -p /sbin/ldconfig
-%post -n libobjc -p /sbin/ldconfig +%post -n %{?cross}libobjc -p /sbin/ldconfig
-%postun -n libobjc -p /sbin/ldconfig +%postun -n %{?cross}libobjc -p /sbin/ldconfig
-%post -n libgcj +%post -n %{?cross}libgcj /sbin/ldconfig /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/fastjar.info.gz || :
-%preun -n libgcj +%preun -n %{?cross}libgcj if [ $1 = 0 ]; then /sbin/install-info --delete \ --info-dir=%{_infodir} %{_infodir}/fastjar.info.gz || : fi
-%postun -n libgcj -p /sbin/ldconfig +%postun -n %{?cross}libgcj -p /sbin/ldconfig
-%post -n libgfortran -p /sbin/ldconfig +%post -n %{?cross}libgfortran -p /sbin/ldconfig
-%postun -n libgfortran -p /sbin/ldconfig +%postun -n %{?cross}libgfortran -p /sbin/ldconfig
-%post -n libgnat -p /sbin/ldconfig +%post -n %{?cross}libgnat -p /sbin/ldconfig
-%postun -n libgnat -p /sbin/ldconfig +%postun -n %{?cross}libgnat -p /sbin/ldconfig
-%post -n libgomp -p /sbin/ldconfig +%post -n %{?cross}libgomp -p /sbin/ldconfig
-%postun -n libgomp -p /sbin/ldconfig +%postun -n %{?cross}libgomp -p /sbin/ldconfig
-%post -n libmudflap -p /sbin/ldconfig +%post -n %{?cross}libmudflap -p /sbin/ldconfig
-%postun -n libmudflap -p /sbin/ldconfig +%postun -n %{?cross}libmudflap -p /sbin/ldconfig
+%if %{isnative} %files -f %{name}.lang +%else +%files +%endif %defattr(-,root,root) +%if %{isnative} %{_prefix}/bin/cc %{_prefix}/bin/c89 %{_prefix}/bin/c99 @@ -1203,6 +1306,11 @@ fi %{_prefix}/bin/gcov %{_prefix}/bin/protoize %{_prefix}/bin/unprotoize +%else +%{_prefix}/bin/%{gcc_target_platform}-c89 +%{_prefix}/bin/%{gcc_target_platform}-c99 +%{_prefix}/bin/%{gcc_target_platform}-gcov +%endif %ifarch sparc ppc %{_prefix}/bin/%{_target_platform}-gcc %endif @@ -1213,11 +1321,16 @@ fi %{_prefix}/bin/ppc-%{_vendor}-%{_target_os}-gcc %endif %{_prefix}/bin/%{gcc_target_platform}-gcc +%if %{isnative} %{_mandir}/man1/gcc.1* %{_mandir}/man1/gcov.1* %{_mandir}/man1/protoize.1* %{_mandir}/man1/unprotoize.1* %{_infodir}/gcc* +%else +%{_mandir}/man1/%{gcc_target_platform}-gcc.1* +%{_mandir}/man1/%{gcc_target_platform}-gcov.1* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} @@ -1225,7 +1338,9 @@ fi %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/SYSCALLS.c.X +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stddef.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stdarg.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/varargs.h @@ -1235,6 +1350,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/iso646.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/syslimits.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind.h +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/omp.h %ifarch %{ix86} x86_64 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h @@ -1254,12 +1370,14 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/altivec.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spe.h %endif +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/README %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/crt*.o %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcov.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_eh.a +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_s.so %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.spec %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.a @@ -1284,30 +1402,50 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.so %endif +%endif +%if !%{isnative} +%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/as +%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/nm +%endif %dir %{_prefix}/libexec/getconf %{_prefix}/libexec/getconf/default %doc gcc/README* rpm.doc/changelogs/gcc/ChangeLog* gcc/COPYING*
+%if %{isnative} %files -n cpp -f cpplib.lang +%else +%files -n %{?cross}cpp +%endif %defattr(-,root,root) +%if %{isnative} /lib/cpp %{_prefix}/bin/cpp %{_mandir}/man1/cpp.1* %{_infodir}/cpp* +%else +%{_prefix}/bin/%{gcc_target_platform}-cpp +%endif %dir %{_prefix}/libexec/gcc %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/cc1
-%files -n libgcc +%files -n %{?cross}libgcc %defattr(-,root,root) +%if %{isnative} /%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 /%{_lib}/libgcc_s.so.1 +%else +/%{_prefix}/%{gcc_target_platform}/%{_lib}/libgcc_s.so.1 +%endif +%if %{isnative) %ifnarch %{arm} %{_prefix}/sbin/libgcc_post_upgrade %endif +%endif %doc gcc/COPYING.LIB
+%if %{isnative} %files c++ %defattr(-,root,root) %{_prefix}/bin/%{gcc_target_platform}-*++ @@ -1342,11 +1480,11 @@ fi %endif %doc rpm.doc/changelogs/gcc/cp/ChangeLog*
-%files -n libstdc++ +%files -n %{?cross}libstdc++ %defattr(-,root,root) %{_prefix}/%{_lib}/libstdc++.so.6*
-%files -n libstdc++-devel +%files -n %{?cross}libstdc++-devel %defattr(-,root,root) %dir %{_prefix}/include/c++ %dir %{_prefix}/include/c++/%{gcc_version} @@ -1372,6 +1510,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libsupc++.a %endif %doc rpm.doc/changelogs/libstdc++-v3/ChangeLog* libstdc++-v3/README* libstdc++-v3/docs/html/ +%endif
%if %{build_objc} %files objc @@ -1407,7 +1546,7 @@ fi %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/cc1objplus
-%files -n libobjc +%files -n %{?cross}libobjc %defattr(-,root,root) %{_prefix}/%{_lib}/libobjc.so.1* %endif @@ -1448,7 +1587,7 @@ fi %endif %doc rpm.doc/gfortran/*
-%files -n libgfortran +%files -n %{?cross}libgfortran %defattr(-,root,root) %{_prefix}/%{_lib}/libgfortran.so.1* %endif @@ -1496,7 +1635,7 @@ fi %endif %doc rpm.doc/changelogs/gcc/java/ChangeLog*
-%files -n libgcj +%files -n %{?cross}libgcj %defattr(-,root,root) %{_prefix}/bin/jv-convert %{_prefix}/bin/gij @@ -1555,7 +1694,7 @@ fi %doc rpm.doc/README.libgcjwebplugin.so %endif
-%files -n libgcj-devel +%files -n %{?cross}libgcj-devel %defattr(-,root,root) %{_prefix}/bin/addr2name.awk %dir %{_prefix}/lib/gcc @@ -1589,7 +1728,7 @@ fi %doc rpm.doc/boehm-gc/* rpm.doc/fastjar/* rpm.doc/libffi/* %doc rpm.doc/libjava/*
-%files -n libgcj-src +%files -n %{?cross}libgcj-src %defattr(-,root,root) %dir %{_prefix}/share/java %{_prefix}/share/java/src*.zip @@ -1613,23 +1752,24 @@ fi %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/gnat1 %doc rpm.doc/changelogs/gcc/ada/ChangeLog*
-%files -n libgnat +%files -n %{?cross}libgnat %defattr(-,root,root) %{_prefix}/%{_lib}/libgnat-*.so %{_prefix}/%{_lib}/libgnarl-*.so %endif
-%files -n libgomp +%if %{isnative} +%files -n %{?cross}libgomp %defattr(-,root,root) %{_prefix}/%{_lib}/libgomp.so.1* %doc rpm.doc/changelogs/libgomp/ChangeLog*
-%files -n libmudflap +%files -n %{?cross}libmudflap %defattr(-,root,root) %{_prefix}/%{_lib}/libmudflap.so.0* %{_prefix}/%{_lib}/libmudflapth.so.0*
-%files -n libmudflap-devel +%files -n %{?cross}libmudflap-devel %defattr(-,root,root) %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} @@ -1655,6 +1795,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflapth.so %endif %doc rpm.doc/changelogs/libmudflap/ChangeLog* +%endif
%changelog * Thu May 3 2007 Jakub Jelinek jakub@redhat.com 4.1.2-12
On Wed, 2007-06-27 at 15:54 +0200, Lennert Buytenhek wrote:
On Tue, Jun 12, 2007 at 04:31:51PM +0100, David Woodhouse wrote:
There's a couple of issues:
- There's also two issues with building libstdc++ -
... it install target installs various target files not in the sysroot but in the host's directory space.
--enable-version-specific-runtime-libs
Ralf
On Wed, Jun 27, 2007 at 03:59:55PM +0200, Ralf Corsepius wrote:
There's a couple of issues:
- There's also two issues with building libstdc++ -
... it install target installs various target files not in the sysroot but in the host's directory space.
--enable-version-specific-runtime-libs
Thanks, that worked.
Here is a new version of the Fedora -> Fedora gcc cross patch. It results in a working C/C++ cross compiler (at least, it manages to cross-compile several programs for ARM, and manages to cross-compile a native ARM gcc from sources.)
There's a couple of issues left: - The current cross-libgcc and cross-libstdc++ packages put their libraries in the sysroot (/usr/%{target}/sys-root), since they are target libraries, but this might collide with installed native versions of the same packages down the road. - rpm's %ifarch handling doesn't go together with cross-compiling very well, neither does handling of macros such as %{__strip}, %{__objdump}. Find a proper solution for this.
Again, I don't know whether adding cross support to the main gcc package is the best idea. Maybe splitting the cross bits out into a separate source package is a better option, I'm not sure.
Comments? Ideas?
Index: SPECS/gcc41.spec =================================================================== --- SPECS.orig/gcc41.spec +++ SPECS/gcc41.spec @@ -1,9 +1,25 @@ +%if "%{?gcc_target}" == "" +%define gcc_target %{_target_platform} +%define isnative 1 +%else +%define isnative 0 +%define cross %{gcc_target}- +%define __strip %{gcc_target}-strip +%endif + %define DATE 20070503 %define gcc_version 4.1.2 %define gcc_release 12 %define _unpackaged_files_terminate_build 0 -%define multilib_64_archs sparc64 ppc64 s390x x86_64 %define include_gappletviewer 1 +%if !%{isnative} +%define build_ada 0 +%define build_fortran 0 +%define build_java 0 +%define build_objc 0 +%define run_tests 0 +%else +%define multilib_64_archs sparc64 ppc64 s390x x86_64 %ifarch %{ix86} x86_64 ia64 ppc alpha %define build_ada 1 %else @@ -25,8 +41,9 @@ %ifarch x86_64 %define multilib_32_arch i386 %endif +%endif Summary: Various compilers (C, C++, Objective-C, Java, ...) -Name: gcc +Name: %{?cross}gcc Version: %{gcc_version} Release: %{gcc_release}.fa1 License: GPL @@ -44,7 +61,7 @@ BuildRoot: %{_tmppath}/%{name}-%{version # Need binutils which support --hash-style=gnu >= 2.17.50.0.2-7 # Need binutils which support mffgpr and mftgpr >= 2.17.50.0.2-8 # Need binutils which support 2-argument .movsp >= 2.17.50.0.5 -BuildRequires: binutils >= 2.17.50.0.5 +BuildRequires: %{?cross}binutils >= 2.17.50.0.5 BuildRequires: zlib-devel, gettext, dejagnu, bison, flex, texinfo, sharutils %if %{build_java} BuildRequires: gcc-java, libgcj, /usr/share/java/eclipse-ecj.jar, zip, unzip @@ -52,7 +69,7 @@ BuildRequires: gcc-java, libgcj, /usr/sh # Make sure pthread.h doesn't contain __thread tokens # Make sure glibc supports stack protector # Make sure glibc supports DT_GNU_HASH -BuildRequires: glibc-devel >= 2.4.90-13 +BuildRequires: %{?cross}glibc-devel >= 2.4.90-13 BuildRequires: elfutils-devel >= 0.72 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double @@ -69,7 +86,7 @@ BuildRequires: gcc-gnat >= 3.1, libgnat %ifarch ia64 BuildRequires: libunwind >= 0.98 %endif -Requires: cpp = %{version}-%{release} +Requires: %{?cross}cpp = %{version}-%{release} # Need .eh_frame ld optimizations # Need proper visibility support # Need -pie support @@ -80,25 +97,29 @@ Requires: cpp = %{version}-%{release} # Need binutils that supports --hash-style=gnu # Need binutils that support mffgpr/mftgpr # Need binutils that support 2-argument .movsp >= 2.17.50.0.5 -Requires: binutils >= 2.17.50.0.5 +Requires: %{?cross}binutils >= 2.17.50.0.5 # Make sure gdb will understand DW_FORM_strp -Conflicts: gdb < 5.1-2 -Requires: glibc-devel >= 2.2.90-12 +Conflicts: %{?cross}gdb < 5.1-2 +Requires: %{?cross}glibc-devel >= 2.2.90-12 %ifarch ppc ppc64 s390 s390x sparc sparcv9 alpha # Make sure glibc supports TFmode long double -Requires: glibc >= 2.3.90-35 +Requires: %{?cross}glibc >= 2.3.90-35 %endif -Requires: libgcc >= %{version}-%{release} +Requires: %{?cross}libgcc >= %{version}-%{release} +%if %{isnative} Requires: libgomp = %{version}-%{release} +%endif +%if %{isnative} Obsoletes: gcc3 Obsoletes: egcs +%endif %ifarch sparc -Obsoletes: gcc-sparc32 -Obsoletes: gcc-c++-sparc32 +Obsoletes: %{?cross}gcc-sparc32 +Obsoletes: %{?cross}gcc-c++-sparc32 %endif %ifarch ppc -Obsoletes: gcc-ppc32 -Obsoletes: gcc-c++-ppc32 +Obsoletes: %{?cross}gcc-ppc32 +Obsoletes: %{?cross}gcc-c++-ppc32 %endif Obsoletes: gcc-chill %if !%{build_ada} @@ -160,6 +181,7 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch %{arm} %define _gnu %{nil} %endif +%if "%{?gcc_target}" == "" %ifarch sparc %define gcc_target_platform sparc64-%{_vendor}-%{_target_os} %endif @@ -169,30 +191,33 @@ Patch40: gcc41-unbreak-armv4t.patch %ifnarch sparc ppc %define gcc_target_platform %{_target_platform} %endif +%else +%define gcc_target_platform %{gcc_target} +%endif
%description The gcc package contains the GNU Compiler Collection version 4.1. You'll need this package in order to compile C code.
-%package -n libgcc +%package -n %{?cross}libgcc Summary: GCC version 4.1 shared support library Group: System Environment/Libraries Autoreq: false
-%description -n libgcc +%description -n %{?cross}libgcc This package contains GCC shared support library which is needed e.g. for exception handling support.
%package c++ Summary: C++ support for GCC Group: Development/Languages -Requires: gcc = %{version}-%{release} -Requires: libstdc++ = %{version}-%{release} -Requires: libstdc++-devel = %{version}-%{release} -Obsoletes: gcc3-c++ -Obsoletes: gcc34-c++ -Obsoletes: gcc35-c++ -Obsoletes: gcc4-c++ +Requires: %{?cross}gcc = %{version}-%{release} +Requires: %{?cross}libstdc++ = %{version}-%{release} +Requires: %{?cross}libstdc++-devel = %{version}-%{release} +Obsoletes: %{?cross}gcc3-c++ +Obsoletes: %{?cross}gcc34-c++ +Obsoletes: %{?cross}gcc35-c++ +Obsoletes: %{?cross}gcc4-c++ Autoreq: true
%description c++ @@ -200,26 +225,26 @@ This package adds C++ support to the GNU It includes support for most of the current C++ specification, including templates and exception handling.
-%package -n libstdc++ +%package -n %{?cross}libstdc++ Summary: GNU Standard C++ Library Group: System Environment/Libraries -Obsoletes: libstdc++3 -Obsoletes: libstdc++34 +Obsoletes: %{?cross}libstdc++3 +Obsoletes: %{?cross}libstdc++34 Autoreq: true
-%description -n libstdc++ +%description -n %{?cross}libstdc++ The libstdc++ package contains a rewritten standard compliant GCC Standard C++ Library.
-%package -n libstdc++-devel +%package -n %{?cross}libstdc++-devel Summary: Header files and libraries for C++ development Group: Development/Libraries -Requires: libstdc++ = %{version}-%{release}, %{_prefix}/%{_lib}/libstdc++.so.6 -Obsoletes: libstdc++3-devel +Requires: %{?cross}libstdc++ = %{version}-%{release}, %{_prefix}/%{_lib}/libstdc++.so.6 +Obsoletes: %{?cross}libstdc++3-devel Obsoletes: libstdc++34-devel Autoreq: true
-%description -n libstdc++-devel +%description -n %{?cross}libstdc++-devel This is the GNU implementation of the standard C++ libraries. This package includes the header files and libraries needed for C++ development. This includes rewritten implementation of STL. @@ -382,7 +407,7 @@ Autoreq: true %description -n libgcj-src The Java(tm) runtime library sources for use in Eclipse.
-%package -n cpp +%package -n %{?cross}cpp Summary: The C Preprocessor. Group: Development/Languages Prereq: /sbin/install-info @@ -391,7 +416,7 @@ Obsoletes: gnupro %endif Autoreq: true
-%description -n cpp +%description -n %{?cross}cpp Cpp is the GNU C-Compatible Compiler Preprocessor. Cpp is a macro processor which is used automatically by the C compiler to transform your program before actual @@ -583,6 +608,7 @@ case "$OPT_FLAGS" in ../gcc/Makefile.in ;; esac +%if %{isnative} CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="$OPT_FLAGS" XCFLAGS="$OPT_FLAGS" TCFLAGS="$OPT_FLAGS" \ GCJFLAGS="$OPT_FLAGS" \ ../configure --prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \ @@ -663,6 +689,20 @@ rm -rf testlogs-%{_target_platform}-%{ve
# Make protoize make -C gcc CC="./xgcc -B ./ -O2" proto +%else +CC="$CC" CFLAGS="-O2 -g" CXXFLAGS="-O2 -g" XCFLAGS="-O2 -g" TCFLAGS="-O2 -g" \ + GCJFLAGS="-O2 -g" \ + ../configure --prefix=%{_prefix} --mandir=%{_mandir} \ + --infodir=%{_infodir} --enable-shared --enable-threads=posix \ + --enable-checking=release --with-system-zlib --enable-__cxa_atexit \ + --disable-libunwind-exceptions --enable-languages=c,c++ \ + --disable-libgcj --disable-libssp --disable-libgomp \ + --disable-libmudflap --with-sysroot=yes \ + --enable-version-specific-runtime-libs \ + --target=%{gcc_target_platform} + +GCJFLAGS="-O2 -g" make %{?_smp_mflags} BOOT_CFLAGS="-O2 -g" +%endif
# Make generated man pages even if Pod::Man is not new enough perl -pi -e 's/head3/head2/' ../contrib/texi2pod.pl @@ -730,8 +770,6 @@ fi export PATH=`pwd`/java_hacks${PATH:+:$PATH} %endif
-TARGET_PLATFORM=%{gcc_target_platform} - # There are some MP bugs in libstdc++ Makefiles make -C %{gcc_target_platform}/libstdc++-v3
@@ -748,15 +786,19 @@ FULLPATH=$RPM_BUILD_ROOT%{_prefix}/lib/g FULLEPATH=$RPM_BUILD_ROOT%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}
# fix some things +%if %{isnative} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/cc mkdir -p $RPM_BUILD_ROOT/lib ln -sf ..%{_prefix}/bin/cpp $RPM_BUILD_ROOT/lib/cpp +%endif %if %{build_fortran} ln -sf gfortran $RPM_BUILD_ROOT%{_prefix}/bin/f95 %endif rm -f $RPM_BUILD_ROOT%{_infodir}/dir gzip -9 $RPM_BUILD_ROOT%{_infodir}/*.info* +%if %{build_ada} ln -sf gcc $RPM_BUILD_ROOT%{_prefix}/bin/gnatgcc +%endif
cxxconfig="`find %{gcc_target_platform}/libstdc++-v3/include -name c++config.h`" for i in `find %{gcc_target_platform}/[36]*/libstdc++-v3/include -name c++config.h 2>/dev/null`; do @@ -818,11 +860,26 @@ sed -i -e 's/lib: /&%%{static:%%eJava pr $FULLPATH/libgcj.spec %endif
+%if %{isnative} mkdir -p $RPM_BUILD_ROOT/%{_lib} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcc_s.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 chmod 755 $RPM_BUILD_ROOT/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 ln -sf libgcc_s-%{gcc_version}-%{DATE}.so.1 $RPM_BUILD_ROOT/%{_lib}/libgcc_s.so.1 ln -sf /%{_lib}/libgcc_s.so.1 $FULLPATH/libgcc_s.so +%else +mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/lib +mv -f $FULLPATH/libgcc_s.so.1 $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 +chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 +ln -sf libgcc_s-%{gcc_version}-%{DATE}.so.1 $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s.so.1 +ln -sf ../../../../%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s.so.1 $FULLPATH/libgcc_s.so + +mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include +mv -f $FULLPATH/include/c++ $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/ +ln -sf ../../../../../%{gcc_target_platform}/sys-root/%{_prefix}/include/c++ $FULLPATH/include/c++ + +mkdir -p $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/%{_lib} +mv $FULLPATH/libstdc++.so.* $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/%{_lib}/ +%endif %ifarch sparc ppc ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64/libgcc_s.so %endif @@ -830,8 +887,10 @@ ln -sf /lib64/libgcc_s.so.1 $FULLPATH/64 ln -sf /lib/libgcc_s.so.1 $FULLPATH/32/libgcc_s.so %endif
+%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.spec $FULLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/include/omp.h $FULLPATH/include/ +%endif
%if %{build_ada} mv -f $FULLPATH/adalib/libgnarl-*.so $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ @@ -859,13 +918,19 @@ if [ "%{_lib}" = "lib" ]; then %if %{build_objc} ln -sf ../../../libobjc.so.1 libobjc.so %endif +%if %{isnative} ln -sf ../../../libstdc++.so.6.* libstdc++.so +%else +ln -sf ../../../../%{gcc_target}/sys-root/%{_prefix}/%{_lib}/libstdc++.so.6.* libstdc++.so +%endif %if %{build_fortran} ln -sf ../../../libgfortran.so.1.* libgfortran.so %endif +%if %{isnative} ln -sf ../../../libgomp.so.1.* libgomp.so ln -sf ../../../libmudflap.so.0.* libmudflap.so ln -sf ../../../libmudflapth.so.0.* libmudflapth.so +%endif %if %{build_java} ln -sf ../../../libgcj.so.8rh.* libgcj.so ln -sf ../../../libgcj-tools.so.8rh.* libgcj-tools.so @@ -907,8 +972,10 @@ fi %if %{build_java} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgcj_bc.so $FULLLPATH/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libstdc++.*a $FULLLPATH/ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libsupc++.*a . +%endif %if %{build_fortran} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortranbegin.*a . @@ -916,9 +983,11 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.*a . %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.*a . mv -f $RPM_BUILD_ROOT%{_prefix}/include/mf-runtime.h include/ +%endif
%ifarch sparc ppc %if %{build_objc} @@ -928,9 +997,11 @@ ln -sf ../`echo ../../../../lib/libstdc+ %if %{build_fortran} ln -sf ../`echo ../../../../lib/libgfortran.so.1.* | sed s~/lib/~/lib64/~` 64/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib/libgomp.so.1.* | sed s~/lib/~/lib64/~` 64/libgomp.so ln -sf ../`echo ../../../../lib/libmudflap.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflap.so ln -sf ../`echo ../../../../lib/libmudflapth.so.0.* | sed s~/lib/~/lib64/~` 64/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib/libgcj.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj.so ln -sf ../`echo ../../../../lib/libgcj-tools.so.8rh.* | sed s~/lib/~/lib64/~` 64/libgcj-tools.so @@ -946,8 +1017,10 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/li %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libobjc.*a 64/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libgomp.*a 64/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib64/libmudflap{,th}.*a 64/ +%endif ln -sf lib32/libstdc++.a libstdc++.a ln -sf ../lib64/libstdc++.a 64/libstdc++.a %endif @@ -960,9 +1033,11 @@ ln -sf ../`echo ../../../../lib64/libstd %if %{build_fortran} ln -sf ../`echo ../../../../lib64/libgfortran.so.1.* | sed s~/../lib64/~/~` 32/libgfortran.so %endif +%if %{isnative} ln -sf ../`echo ../../../../lib64/libgomp.so.1.* | sed s~/../lib64/~/~` 32/libgomp.so ln -sf ../`echo ../../../../lib64/libmudflap.so.0.* | sed s~/../lib64/~/~` 32/libmudflap.so ln -sf ../`echo ../../../../lib64/libmudflapth.so.0.* | sed s~/../lib64/~/~` 32/libmudflapth.so +%endif %if %{build_java} ln -sf ../`echo ../../../../lib64/libgcj.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj.so ln -sf ../`echo ../../../../lib64/libgcj-tools.so.8rh.* | sed s~/../lib64/~/~` 32/libgcj-tools.so @@ -976,9 +1051,11 @@ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libg %if %{build_objc} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libobjc.*a 32/ %endif +%if %{isnative} mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libgomp.*a 32/ mv -f $RPM_BUILD_ROOT%{_prefix}/lib/libmudflap{,th}.*a 32/ %endif +%endif %ifarch sparc64 ppc64 ln -sf ../lib32/libstdc++.a 32/libstdc++.a ln -sf lib64/libstdc++.a libstdc++.a @@ -996,15 +1073,17 @@ ln -sf ../../../%{multilib_32_arch}-%{_v %endif
# Strip debug info from Fortran/ObjC/Java static libraries -strip -g `find . ( -name libgfortran.a -o -name libobjc.a -o -name libgomp.a \ +%{__strip} -g `find . ( -name libgfortran.a -o -name libobjc.a -o -name libgomp.a \ -o -name libmudflap.a -o -name libmudflapth.a \ -o -name libgcc.a -o -name libgcov.a ) -a -type f` popd %if %{build_fortran} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgfortran.so.1.* %endif +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libgomp.so.1.* chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libmudflap{,th}.so.0.* +%endif %if %{build_objc} chmod 755 $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libobjc.so.1.* %endif @@ -1022,7 +1101,11 @@ for h in `find $FULLPATH/include -name \ fi done
+%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c89 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c89 <<"EOF" +%endif #!/bin/sh fl="-std=c89" for opt; do @@ -1034,7 +1117,11 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} cat > $RPM_BUILD_ROOT%{_prefix}/bin/c99 <<"EOF" +%else +cat > $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c99 <<"EOF" +%endif #!/bin/sh fl="-std=c99" for opt; do @@ -1046,17 +1133,25 @@ for opt; do done exec gcc $fl ${1+"$@"} EOF +%if %{isnative} chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/c?9 +%else +chmod 755 $RPM_BUILD_ROOT%{_prefix}/bin/%{gcc_target_platform}-c?9 +%endif
+%if %{isnative} %ifnarch %{arm} mkdir -p $RPM_BUILD_ROOT%{_prefix}/sbin gcc -static -Os %{SOURCE1} -o $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade -strip $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade +%{__strip} $RPM_BUILD_ROOT%{_prefix}/sbin/libgcc_post_upgrade +%endif %endif
cd .. -%find_lang %{name} -%find_lang cpplib +%if %{isnative} +%find_lang %{?cross}%{name} +%find_lang %{?cross}cpplib +%endif
# Remove binaries we will not be including, so that they don't end up in # gcc-debuginfo @@ -1102,11 +1197,11 @@ if [ $1 = 0 ]; then --info-dir=%{_infodir} %{_infodir}/gcc.info.gz || : fi
-%post -n cpp +%post -n %{?cross}cpp /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || :
-%preun -n cpp +%preun -n %{?cross}cpp if [ $1 = 0 ]; then /sbin/install-info --delete \ --info-dir=%{_infodir} %{_infodir}/cpp.info.gz || : @@ -1150,16 +1245,18 @@ if [ $1 = 0 ]; then --info-dir=%{_infodir} %{_infodir}/gnat-style.info.gz || : fi
+%if %{isnative} %ifnarch %{arm} # Because glibc Prereq's libgcc and /sbin/ldconfig # comes from glibc, it might not exist yet when # libgcc is installed -%post -n libgcc -p %{_prefix}/sbin/libgcc_post_upgrade +%post -n %{?cross}libgcc -p %{_prefix}/sbin/libgcc_post_upgrade %endif
-%post -n libstdc++ -p /sbin/ldconfig +%post -n %{?cross}libstdc++ -p /sbin/ldconfig
-%postun -n libstdc++ -p /sbin/ldconfig +%postun -n %{?cross}libstdc++ -p /sbin/ldconfig +%endif
%post -n libobjc -p /sbin/ldconfig
@@ -1194,8 +1291,13 @@ fi
%postun -n libmudflap -p /sbin/ldconfig
+%if %{isnative} %files -f %{name}.lang +%else +%files +%endif %defattr(-,root,root) +%if %{isnative} %{_prefix}/bin/cc %{_prefix}/bin/c89 %{_prefix}/bin/c99 @@ -1203,6 +1305,11 @@ fi %{_prefix}/bin/gcov %{_prefix}/bin/protoize %{_prefix}/bin/unprotoize +%else +%{_prefix}/bin/%{gcc_target_platform}-c89 +%{_prefix}/bin/%{gcc_target_platform}-c99 +%{_prefix}/bin/%{gcc_target_platform}-gcov +%endif %ifarch sparc ppc %{_prefix}/bin/%{_target_platform}-gcc %endif @@ -1213,11 +1320,16 @@ fi %{_prefix}/bin/ppc-%{_vendor}-%{_target_os}-gcc %endif %{_prefix}/bin/%{gcc_target_platform}-gcc +%if %{isnative} %{_mandir}/man1/gcc.1* %{_mandir}/man1/gcov.1* %{_mandir}/man1/protoize.1* %{_mandir}/man1/unprotoize.1* %{_infodir}/gcc* +%else +%{_mandir}/man1/%{gcc_target_platform}-gcc.1* +%{_mandir}/man1/%{gcc_target_platform}-gcov.1* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} @@ -1225,7 +1337,9 @@ fi %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/SYSCALLS.c.X +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stddef.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/stdarg.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/varargs.h @@ -1235,6 +1349,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/iso646.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/syslimits.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind.h +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/omp.h %ifarch %{ix86} x86_64 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h @@ -1254,6 +1369,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/altivec.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spe.h %endif +%endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/README %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/crt*.o @@ -1261,6 +1377,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcov.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_eh.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc_s.so +%if %{isnative} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.spec %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.so @@ -1284,36 +1401,54 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgomp.so %endif +%endif %dir %{_prefix}/libexec/getconf %{_prefix}/libexec/getconf/default %doc gcc/README* rpm.doc/changelogs/gcc/ChangeLog* gcc/COPYING*
+%if %{isnative} %files -n cpp -f cpplib.lang +%else +%files -n %{?cross}cpp +%endif %defattr(-,root,root) +%if %{isnative} /lib/cpp %{_prefix}/bin/cpp %{_mandir}/man1/cpp.1* %{_infodir}/cpp* +%else +%{_prefix}/bin/%{gcc_target_platform}-cpp +%{_mandir}/man1/%{gcc_target_platform}-cpp.1* +%endif %dir %{_prefix}/libexec/gcc %dir %{_prefix}/libexec/gcc/%{gcc_target_platform} %dir %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version} %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/cc1
-%files -n libgcc +%files -n %{?cross}libgcc %defattr(-,root,root) +%if %{isnative} /%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 /%{_lib}/libgcc_s.so.1 %ifnarch %{arm} %{_prefix}/sbin/libgcc_post_upgrade %endif -%doc gcc/COPYING.LIB +%else +/%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s-%{gcc_version}-%{DATE}.so.1 +/%{_prefix}/%{gcc_target_platform}/sys-root/%{_lib}/libgcc_s.so.1 +%endif
%files c++ %defattr(-,root,root) %{_prefix}/bin/%{gcc_target_platform}-*++ +%if %{isnative} %{_prefix}/bin/g++ %{_prefix}/bin/c++ %{_mandir}/man1/g++.1* +%else +%{_mandir}/man1/%{gcc_target_platform}-g++.1* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} @@ -1342,20 +1477,32 @@ fi %endif %doc rpm.doc/changelogs/gcc/cp/ChangeLog*
-%files -n libstdc++ +%files -n %{?cross}libstdc++ %defattr(-,root,root) +%if %{isnative} %{_prefix}/%{_lib}/libstdc++.so.6* +%else +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/%{_lib}/libstdc++.so.6* +%endif
-%files -n libstdc++-devel +%files -n %{?cross}libstdc++-devel %defattr(-,root,root) +%if %{isnative} %dir %{_prefix}/include/c++ %dir %{_prefix}/include/c++/%{gcc_version} %{_prefix}/include/c++/%{gcc_version}/[^gjos]* %{_prefix}/include/c++/%{gcc_version}/os* %{_prefix}/include/c++/%{gcc_version}/s[^u]* +%endif %dir %{_prefix}/lib/gcc %dir %{_prefix}/lib/gcc/%{gcc_target_platform} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version} +%if !%{isnative} +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/c++/[^gjos]* +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/c++/os* +%{_prefix}/%{gcc_target_platform}/sys-root/%{_prefix}/include/c++/s[^u]* +%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/c++ +%endif %ifarch sparc ppc %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/lib32 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/lib32/libstdc++.a @@ -1619,6 +1766,7 @@ fi %{_prefix}/%{_lib}/libgnarl-*.so %endif
+%if %{isnative} %files -n libgomp %defattr(-,root,root) %{_prefix}/%{_lib}/libgomp.so.1* @@ -1655,6 +1803,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflapth.so %endif %doc rpm.doc/changelogs/libmudflap/ChangeLog* +%endif
%changelog * Thu May 3 2007 Jakub Jelinek jakub@redhat.com 4.1.2-12
On Tue, Jun 12, 2007 at 04:31:51PM +0100, David Woodhouse wrote:
Binutils at least should be relatively easy. Here's a patch against binutils/F-7 which lets me: make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
I've had to change two things to make cross-gcc happy with this:
1. Change the location of the sysroot. /usr/%{target} is not the right place to put the sysroot, as binutils/gcc use it to store target-specific binaries, etc. (binutils stores things like 'as' in /usr/%{target}/bin, which gcc expects to find there.)
If you use the default sysroot path (i.e. --with-sysroot=yes), the sysroot gets put in /usr/%{target}/sys-root. That seems like a sane default to me.
2. Do package /usr/%{target}, as the subsequently built gcc depends on (see #1) having 'as' in /usr/%{target}/bin and such.
Here's a new version (beware: against a locally modified tree) with these changes. Seems to work OK for me.
Index: SPECS/binutils.spec =================================================================== --- SPECS.orig/binutils.spec +++ SPECS/binutils.spec @@ -1,5 +1,13 @@ +%if "%{?binutils_target}" == "" +%define binutils_target %{_target_platform} +%define isnative 1 +%else +%define cross %{binutils_target}- +%define isnative 0 +%endif + Summary: A GNU collection of binary utilities. -Name: binutils +Name: %{?cross}binutils Version: 2.17.50.0.12 Release: 4.fa1 License: GPL @@ -55,7 +63,7 @@ have a stable ABI. Developers starting to consider using libelf instead of BFD.
%prep -%setup -q +%setup -q -n binutils-%{version} %patch1 -p0 -b .ltconfig-multilib~ %patch2 -p0 -b .ppc64-pie~ %patch3 -p0 -b .place-orphan~ @@ -70,7 +78,7 @@ to consider using libelf instead of BFD. %patch8 -p0 -b .osabi~ %patch9 -p0 -b .rh235747~
-# On ppc64 we might use 64K pages +# On ppc64 we might use 64KiB pages sed -i -e '/#define.*ELF_COMMONPAGESIZE/s/0x1000$/0x10000/' bfd/elf*ppc.c # LTP sucks perl -pi -e 's/i[3-7]86/i[34567]86/g' */conf* @@ -82,24 +90,36 @@ sed -i -e 's/^libbfd_la_LDFLAGS = /&-Wl, sed -i -e 's/^libopcodes_la_LDFLAGS = /&-Wl,-Bsymbolic-functions /' opcodes/Makefile.{am,in} fi touch */configure +sed -i -e 's/^ PACKAGE=/ PACKAGE=%{?cross}/' */configure
%build -mkdir build-%{_target_platform} -cd build-%{_target_platform} +mkdir build-%{binutils_target} +cd build-%{binutils_target} CARGS= -%ifarch sparc ppc s390 -CARGS=--enable-64-bit-bfd -%endif -%ifarch ia64 -CARGS=--enable-targets=i386-linux +case %{binutils_target} in + sparc*|ppc*|s390*) + CARGS=--enable-64-bit-bfd + ;; + ia64*) + CARGS=--enable-targets=i386-linux + ;; +esac +%if %isnative + SHAREDARGS=--enable-shared + TARGET=%{binutils_target} + SYSROOT= +%else + SHAREDARGS=--disable-shared + TARGET="--target %{binutils_target} --host %{_target_platform}" + SYSROOT="--with-sysroot=yes" %endif CC="gcc -L`pwd`/bfd/.libs/" CFLAGS="${CFLAGS:-%optflags}" ../configure \ - %{_target_platform} --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ + $TARGET --prefix=%{_prefix} --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} --sbindir=%{_sbindir} --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} --includedir=%{_includedir} --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} --mandir=%{_mandir} \ - --infodir=%{_infodir} --enable-shared $CARGS --disable-werror + --infodir=%{_infodir} $SHAREDARGS $CARGS --disable-werror $SYSROOT make %{_smp_mflags} tooldir=%{_prefix} all make %{_smp_mflags} tooldir=%{_prefix} info make -k check < /dev/null > check.log 2>&1 || : @@ -111,8 +131,9 @@ cd .. %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_prefix} -cd build-%{_target_platform} +cd build-%{binutils_target} %makeinstall +%if %isnative make prefix=%{buildroot}%{_prefix} infodir=%{buildroot}%{_infodir} install-info gzip -q9f %{buildroot}%{_infodir}/*.info*
@@ -134,10 +155,6 @@ rm -f %{buildroot}%{_prefix}/%{_lib}/lib # Remove libtool files, which reference the .so libs rm -f %{buildroot}%{_prefix}/%{_lib}/lib{bfd,opcodes}.la
-# This one comes from gcc -rm -f %{buildroot}%{_infodir}/dir -rm -rf %{buildroot}%{_prefix}/%{_target_platform} - %ifarch %{ix86} x86_64 ppc ppc64 s390 s390x sparc sparc64 sed -i -e '/^#include "ansidecl.h"/{p;s~^.*$~#include <bits/wordsize.h>~;}' \ %ifarch %{ix86} x86_64 @@ -155,22 +172,36 @@ sed -i -e '/^#include "ansidecl.h"/{p;s~ %endif touch -r ../bfd/bfd-in2.h %{buildroot}%{_prefix}/include/bfd.h
+%else # native +# For cross-binutils we drop the documentation. +rm -rf %{buildroot}%{_infodir} +#rm -rf %{buildroot}%{_prefix}/share/locale +#rm -rf %{buildroot}%{_mandir} +rm -rf %{buildroot}%{_prefix}/%{_lib}/libiberty.a +%endif # native + +# This one comes from gcc +rm -f %{buildroot}%{_infodir}/dir +#rm -rf %{buildroot}%{_prefix}/%{binutils_target} + + cd .. -%find_lang binutils -%find_lang opcodes -%find_lang bfd -%find_lang gas -%find_lang ld -%find_lang gprof -cat opcodes.lang >> binutils.lang -cat bfd.lang >> binutils.lang -cat gas.lang >> binutils.lang -cat ld.lang >> binutils.lang -cat gprof.lang >> binutils.lang +%find_lang %{?cross}binutils +%find_lang %{?cross}opcodes +%find_lang %{?cross}bfd +%find_lang %{?cross}gas +%find_lang %{?cross}ld +%find_lang %{?cross}gprof +cat %{?cross}opcodes.lang >> %{?cross}binutils.lang +cat %{?cross}bfd.lang >> %{?cross}binutils.lang +cat %{?cross}gas.lang >> %{?cross}binutils.lang +cat %{?cross}ld.lang >> %{?cross}binutils.lang +cat %{?cross}gprof.lang >> %{?cross}binutils.lang
%clean rm -rf %{buildroot}
+%if %isnative %post /sbin/ldconfig /sbin/install-info --info-dir=%{_infodir} %{_infodir}/as.info.gz @@ -201,12 +232,16 @@ exit 0 if [ $1 = 0 ] ;then /sbin/install-info --delete --info-dir=%{_infodir} %{_infodir}/bfd.info.gz || : fi +%endif # native
-%files -f binutils.lang +%files -f %{?cross}binutils.lang %defattr(-,root,root) %doc README %{_prefix}/bin/* %{_mandir}/man1/* +%if !%isnative +%{_prefix}/%{binutils_target} +%else %{_prefix}/%{_lib}/lib*.so %{_infodir}/[^b]*info* %{_infodir}/binutils*info* @@ -216,6 +251,7 @@ fi %{_prefix}/include/* %{_prefix}/%{_lib}/lib*.a %{_infodir}/bfd*info* +%endif # native
%changelog * Sat Apr 14 2007 Jakub Jelinek jakub@redhat.com 2.17.50.0.12-4
On 06/08/2007 09:56 PM, Brendan Conoboy wrote: [ ... ]
The build system must be enhanced to support cross compilation.
This is a really interesting (to me) extension of the build system requiring enhancements in many areas.
First, there are primitives in Koji that need to be built up such that, for instance, x86 knows it can cross build arm tools.
To make koji believe it can build arm on x86 should be no problem. But how to tell koji to don't do the %test's. We need to do this on rpm level...
Second, the x86 host needs to be able to retrieve and install arm dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc).
Now we need to touch yum... I'm sure Seth can hack up that bit of code. :-) Also mock needs to understand it.
Third, a native/cross hybrid environment needs to be setup to facilitate the common assumptions made by packages. Previous cross compilation efforts inside my group have spent a lot of time on this. I bet others have as well
If I'm picturing myself this process:
# koji build <something> 1) koji finds deps 2) mock uses yum to retrieve deps 2.1) if it sees gcc, it need to get gcc-cross-<target> 2.2) also true for binutils-cross-<target> 2.3) It needs to retrieve the binaries for the machine running on, else it will not be able to run it (I'm thinking of autoconf, automake, python, etc.) 3) rpm --rebuild --target <target> <something>-$v-$r.src.rpm
So for the buildsystem I see at least 4 tools we need to touch: rpm, yum, mock, koji; And eventually setarch.
So far the big picture that came up to my mind; Quick'n'dirty of course...
[ ... ]
Social: As a volunteer effort, it is unreasonable to expect existing package maintainers to do the work necessary to support cross compilation. There must be people to take on that responsibility and work with upstream and package maintainers to integrate the necessary changes.
I have read the Secondary Architectures proposal and thread with great interest. While there may be some overlap of interest with cross compiling, it's not inherently true. Thus, I'd suggest a cross-team who would generally be responsible for cross-compilation efforts. This might break down like so:
- Responsible for parts of the build system dedicated to cross
compilation.
- Maintainers of the cross compilation tools (These would presumably be
rebuilds of gcc and binutils for the cross-targets).
- Make changes to existing packages in cooperation with the package
maintainer.
- Be responsible for fixing builds that fail because of cross
compiling, but succeed when natively built.
Anybody whose turf I just suggested stepping on, please chime in!
At this point the big picture might be the goal, but to reach it, small steps must be taken:
*) Bring working cross-tools into Fedora I'm sure this is something more people would be happy to have; Not only the ArchTeam's. *) Make rpm --rebuild <target>² do something that _makes sense_ :-) Eg. Set the $sysroot and set gcc to gcc-<target>, ...... *) THINK: Do we need to touch setarch? <...> Add more <...>
My few cent. :-)
-of
------- Footnotes: ²) <target> in this case is a *strange* target for the platform running the command; eg. arm/ppc/alpha/s390 on x86. ³) <host> in this case is the host running yum (eg. i386, but downloading arm/ppc/alpha/s390 packages)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oliver Falk wrote:
On 06/08/2007 09:56 PM, Brendan Conoboy wrote: [ ... ]
The build system must be enhanced to support cross compilation.
This is a really interesting (to me) extension of the build system requiring enhancements in many areas.
First, there are primitives in Koji that need to be built up such that, for instance, x86 knows it can cross build arm tools.
To make koji believe it can build arm on x86 should be no problem. But how to tell koji to don't do the %test's. We need to do this on rpm level...
Second, the x86 host needs to be able to retrieve and install arm dependencies in the arm sys-root (arm's glibc, arm's libX11-devel, etc).
Now we need to touch yum... I'm sure Seth can hack up that bit of code. :-) Also mock needs to understand it.
We use mock and yum in our current cross build environment (I'm in Brendan's group as well). Mock doesn't really care what's going on in the chroot, it just installs package dependencies and periodically runs commands in the chroot. So, if you have a repository with cross tool binary RPMs in it, mock will happily use yum to fetch them, install them into your chroot and will run them in the chroot. I did add an option to mock (the --installdeps option) that will just pull the build depdendencies from an RPM and have yum install them into a chroot, but that's the only thing that's really cross-specific in mock. Haven't really had to do anything to yum.
We do have some ugly hackery in our tools that use mock/yum though. We override the RPM macros and rpmrc files, in an attempt to use the out-of-the-box specfile while overriding the compiler, linker, assembler, etc. The intent is to put together a chroot that contains cross tools, then run rpmbuild on a specfile in the chroot so that the outtput is a binary RPM targeted for the desired architecture (armv5l, mips32, etc.). Unfortunately not many specfiles work out-of-the-box.
I'll see if I can put together a (somewhat) coherent description of how we build and install cross RPMS. Not sure it'll be all that useful for Fedora, but it might stimulate a discussion that gets us there.
Clark
Hi!
I would suggest we create a Wiki (best under SIGs) and add our ideas there. Also the steps that must be done...
What do you think?
-of
On Thu, Jun 07, 2007 at 02:41:41PM -0600, Brendan Conoboy wrote:
I don't have fast and easy answers to all of the above, but I would like to have a discussion about them. My group may be able to offer expertise, patches and some man power toward this goal. What do you think?
The best way to convince people (in my experience) is to show them your patches, and let the patches do the convincing. :-)
If you could show your patches, and show that they are really non-intrusive, that might convince people. Can we see your patches anywhere?
Lennert Buytenhek wrote:
The best way to convince people (in my experience) is to show them your patches, and let the patches do the convincing. :-)
Definitely.
If you could show your patches, and show that they are really non-intrusive, that might convince people. Can we see your patches anywhere?
Not quite yet- The patches to packages are half of the equation. The other half is the changes to the build system that make the patches work. Let me see what I can share sooner than later.