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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
