[lug] Strange Ideas for Cross-Platform/Cross-Distribution Development

[stimits at comcast.net]

An x86-based package manager running on Fedora for use with an independent Ubuntu file system is indeed what I'm hoping to do. A bit more complicated since my host is Fedora instead of Ubuntu. If there were ports of apt and dpkg intended to run on Fedora or other non-Ubuntu/non-Debian systems I'd be quite happy (note that this implies working with an Ubuntu file system and not converting between Fedora and Debian packaging). I've never used cross-emerge, I'm wondering how hard it might be to get it working on Fedora...or whether it would even be possible. I want to avoid the emulator route...I could use the native hardware, but that kind of defeats the purpose of being able to develop from scratch on the host PC.
 
I may just check out what files are required to support the tools (lots of ldd) and manually copy them into some sort of chroot environment on Fedora and see if it works (I have my doubts, but it's just for curiosity so it isn't really too much wasted time). I'm guessing though that the linker environment on Fedora 27 (along with gcc 7) makes this unreasonable.
 
----- Original Message -----From: Lee Woodworth <blug-mail at duboulder.com>To: lug at lug.boulder.co.usSent: Wed, 13 Jun 2018 04:51:57 -0000 (UTC)Subject: Re: [lug] Strange Ideas for Cross-Platform/Cross-Distribution Development

If I understand correctly you want to use an x86-based package manager touse arm64 repositories to install arm64 binary packages in a sysroot. Ijust wonder about whether any package prerequisite checking or install phaseswould try to run target code. An emulator could be more reliable in that case.

Re existing tools, I think what gentoo calls cross-emerge (aka package install)is like what you want to do. This is for a full cross-compiled source installthough. And it doesn't work with all packages since some do run target codeduring the install. AFICT trying make it work for those cases gets complex, itinvolves binfmt handlers to run the target tools in an emulator whilechrooted into the target sysroot.

On 06/12/2018 01:09 PM, stimits at comcast.net wrote:> Hi,> > This is more or less just for fun, but could end up being quite valuable. I am looking at an image of an Ubuntu file system in a subdirectory of a Fedora 27 installation. Not only is this root file system Ubuntu instead of Fedora, it is also 64-bit ARM (and the Fedora holding it is x86_64). I have a number of cross-compile tools, and typically this Ubuntu file system gets edited and then flashed to an embedded system.> > The strangeness comes because I was thinking how cool it would be to chroot to that alternate root file system and to use "apt" and family (e.g., "apt-get") within that alternate root file system independently of what is on my Fedora host. Fedora actually has some cross-ubuntu apt tools, but they are designed to be some sort of bridge between RPM format and DEB format packages. I don't want to do that...I want this chroot to be purely within the alternate directory.> > If I just chroot (or "systemd-nspawn") nothing will work at all because everything there is arm64. However, I suppose it might be possible to place the x86_64 versions of apt and apt-get and dpkg within that directory tree and use those while pretending arm64 is a foreign architecture. Has anyone here heard of any kind of HOWTO for this? Or perhaps suggestions on which Ubuntu packages I might have to copy from an Ubuntu x86_64 system to make this work chroot?> > Thanks!> > > > _______________________________________________> Web Page: http://lug.boulder.co.us> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety> 

_______________________________________________Web Page: http://lug.boulder.co.usMailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lugJoin us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20180613/540a209f/attachment.html>