The cross-compile thing..

steveL · Posted: Tue Mar 18, 2014 3:10 am Post subject: The cross-compile thing..

Carrying on a discussion from bugzilla CHOST dependencies required in ROOT at build-time (another form of LIB_DEPEND, usually which is the main one cross-compilers worry about, tho header-deps are also needed.)

@james:
It's different if either is not "/", but if you have ROOT=/ then there's no sane way for PORTAGE_CONFIGROOT to be something else, imo. I guess perhaps if you're doing an install and have non-local config over the network or something, but if you're doing that you're better off copying it to the local machine as part of preparation, ime. In any event a very odd situation, and not one where you'd expect help: you'd be doing something pretty custom.

There's more utility in ROOT=/some/path and PORTAGE_CONFIGROOT=/standard/setup so you'd vary ROOT as you try out different things, typically in a cross-compile situation. OFC having them both the same is much more common (default if you don't set CONFIGROOT iirc), as is ROOT=/some/path PORTAGE_CONFIGROOT=/ for chroot builds for native machine. Been a while since i did any chroots, so usual disclaimers apply (don't flame me for ignorance, just correct me:)
--

If anyone else is interested in cross-compiles, please do chime in; the more the merrier, if we want to fix things; though HDEPEND is already implemented (just wrongly-named atm, the code is done) there's plenty more to fix if #-embedded is anything to go by.

Chewi · Posted: Tue Mar 18, 2014 10:34 am Post subject:

Hi Steve.

I hadn't even considered ROOT=/ with PORTAGE_CONFIGROOT!=/. That would indeed be very odd. I was referring to the opposite, a chroot as you put it. All I was saying was that it would probably be safe to use headers from / rather than ROOT under such a setup since the configuration would be the same in both places. If neither ROOT or PORTAGE_CONFIGROOT point to / then you should definitely avoid using headers from / as much as possible.

This is true for libraries as well as headers, of course, but libraries are slightly less problematic for two reasons. Firstly, they are required at runtime too so they will definitely be installed to ROOT regardless of whether you use the --root-deps option. Secondly, if you're cross-compiling then ld will never successfully link against a library for a different architecture. Sure, the build will fail but at least you won't get unintuitive errors at build time or hard-to-diagnose errors at runtime, which is what can happen with headers.

It's been an embarrassingly long time coming but I am on the verge of releasing some rather exciting cross-compiling scripts that work around a lot of issues, admittedly through some fairly ugly hacks, but carefully applied nonetheless. I just need to get the FreeSWITCH developers off my back first.

HDEPEND is implemented but it is practically unusable because the eclasses don't support it (they complain and die, usually for no good reason) and any bug reports with fixes that involve it are automatically closed. I really really want it to be accepted because working around the eclass problem in my scripts isn't very pretty.

steveL · Posted: Tue Mar 18, 2014 2:13 pm Post subject:

Hey Chewi,

Glad we've got a discussion going.

steveL · Posted: Mon Mar 24, 2014 8:08 am Post subject:

Chewi · Posted: Mon Mar 24, 2014 8:55 am Post subject:

Sorry for not replying sooner but I felt the best way to answer your question would be to show you. I almost released my scripts on Saturday but found a couple of lingering problems. I've now fixed them and will release later today if this current test run completes successfully. It's nearly there!

Chewi · Posted: Mon Mar 24, 2014 10:42 am Post subject:

Aaaand it's up. Finally! I'd appreciate some early feedback before I start spreading the word.

https://github.com/chewi/cross-boss

steveL · Posted: Mon Mar 24, 2014 3:43 pm Post subject:

OK, cloned it; first impressions are the scripting is quite reasonable, apart from the awful Gentoo "${house}" style that no self-respecting #bash scripter uses. The refresh of overlay every time in common.sh seems a bit dubious; manifesting the ebuilds from latest, which nowadays should be done with repoman manifest in the directory, means the user is going to download the sources for every version to build the manifest, even if they don't need the ebuild, or the other versions. And you're running that process every time any of the cb commands is used. Would it not be better to use the normal layman overlay setup?

I'll take a closer look at other scripts later on; please don't take that the above as any sort of overarching criticism, just feedback to help improve things. And well done. :-)

Chewi · Posted: Mon Mar 24, 2014 3:53 pm Post subject:

Heh, most of my Bash experience comes from Gentoo but I've never been told that before! I'm also a Ruby coder by trade so the Bash "${foo}" syntax is similar to Ruby's "#{foo}" syntax.

I originally intended for the overlay to have fewer packages but I found several that just couldn't be fixed up any other way. I'll check out repoman manifest but it should not be downloading all the sources because I copy the original Manifest from the Portage tree first. If it is downloading the sources then that's a bug. The weird stuff I'm doing here doesn't really fit with layman. I didn't find the overlay step takes all that long in the grand scheme of things (certainly a lot quicker than trying to emerge via QEMU) but I'll see if I can speed it up a bit.

steveL · Posted: Tue Mar 25, 2014 5:44 am Post subject: