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