Oron Peled wrote:
> On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote:
>> The right way to do cross toolchains is to cross-build sysrooted packages
>> from source in dedicated cross packages, which is how the Fedora cross
>> toolchains work. Mixing binaries for completely different machines in the
>> same directory tree, which will not even run on the host machine (or at
>> best, very slowly through software emulation), strikes me as a horrible
>> hack.
>
> We are not talking about running binaries, but rather linking with
> libraries.
With "binaries", in this context, I meant both executables and libraries.
>> The de-facto standard for cross compilers (i.e., what, e.g., the GNU
>> toolchain supports out of the box and defaults to) is /usr/$triplet
>> (sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason,
>> because the former can accomodate /usr/$triplet/bin,
>> /usr/$triplet/libexec etc. easily
>
> I've used and built such toolchains for years (thanks crosstools-ng).
> They are fine if all you use them for is building "leaf" applications.
>
> But when your project is composed of many developed libraries -- this is
> hell:
> * Let's say you use your toolchain to build some libfoo shared object:
> - On the target device, it may be located under /usr/lib
> - But this is useless for further development, because in order to
> link your applications with libfoo, it should be installed under
> your $sysroot, where your toolchain will search for it
> (e.g: /usr/$triplet/usr/lib)
> * The common hack was to build these packages for the target
> device (libraries located under /usr/lib) and than use some
> "conversion" scripts that create a new package (with only libraries,
> headers, pkg-config, etc.) that install them on the development
> host under $sysroot.
The clean approach there is to maintain 2 completely different specfiles, a
$triplet-libfoo noarch package to install on the development machine, and a
"native" libfoo package for $triplet (which may be natively compiled or
cross-compiled) to install on the actual target machine. Converting one to
the other from already-built packages is necessarily an ugly hack, I agree
with you there. You really want to build the source twice from separate
SRPMs.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
