Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The cross-compile thing..
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2717
Location: The Peanut Gallery

PostPosted: Tue Mar 18, 2014 3:10 am    Post subject: The cross-compile thing.. Reply with quote

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.
Back to top
View user's profile Send private message
Chewi
l33t
l33t


Joined: 01 Sep 2003
Posts: 788
Location: Edinburgh, Scotland

PostPosted: Tue Mar 18, 2014 10:34 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2717
Location: The Peanut Gallery

PostPosted: Tue Mar 18, 2014 2:13 pm    Post subject: Reply with quote

Hey Chewi,

Glad we've got a discussion going.
Chewi wrote:
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. :)

It seems a shame not to do that in crossdev: mind me asking why not?
Quote:
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.

The trouble is as-implemented it is wrong: it makes HDEPEND what DEPEND is now (CBUILD), and DEPEND into CHOST dependencies. So that needs to be changed first, or we lose all consistency. Obviously it's a trivial change, and in fact means less diff to current. However many people don't understand that distinction, and think CHOST is the CBUILD in the toolchain setup.

As you know, CTARGET is only ever used for toolchain setups, and is only ever different to CHOST when building a cross-compile toolchain. No other package apart from toolchain should even look at CTARGET. "we build to run on a host"..(and compile for a target.)

The confusion is understandable; there's the whole "hosted implementation" thing in the C standards, and people are used to thinking of embedded targets. And the host -> target thing is there in toolchain, it just doesn't apply when people think it does.
For normal package builds, ie 97% of what people build, it's going to run on the CHOST, and nowhere else.

It drives toolchain people spare, having to explain it again and again.. so they don't, ime; they just ignore people who don't get it yet. ;)

Setting CHOST to CBUILD will of course result in broken packages, as you describe with libs, but it's not going to show up til you run it on the board, as your root will all be the same arch so "consistent".. which is why autoconf doesn't accept CHOST without CBUILD: in case the user is unaware of that situation, and is in fact trying to tell it what the build arch is.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2717
Location: The Peanut Gallery

PostPosted: Mon Mar 24, 2014 8:08 am    Post subject: Reply with quote

steveL wrote:
It seems a shame not to do that in crossdev: mind me asking why not?

Hmm it's painfully apparent "why not" from a recent thread on the mailing list.

crossdev installs its wrappers (such as x86-pc-linux-gnu-gcc) into the native bindirs, which sucks big-time afaic. However it doesn't seem like that big a change to make it a bit less dumb, and simply rely on cross-emerge to set the right PATH.

The only question is, if such an obviously incorrect design decision was taken at the base, what's the rest of it like? So I'll bow to the weight of your greater experience, Chewi, at least until I take a proper look at crossdev code to see whether it's worth fixing, or better off rewriting. Meantime, please do unleash your scripts for others to try out.
Back to top
View user's profile Send private message
Chewi
l33t
l33t


Joined: 01 Sep 2003
Posts: 788
Location: Edinburgh, Scotland

PostPosted: Mon Mar 24, 2014 8:55 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Chewi
l33t
l33t


Joined: 01 Sep 2003
Posts: 788
Location: Edinburgh, Scotland

PostPosted: Mon Mar 24, 2014 10:42 am    Post subject: Reply with quote

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

https://github.com/chewi/cross-boss
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2717
Location: The Peanut Gallery

PostPosted: Mon Mar 24, 2014 3:43 pm    Post subject: Reply with quote

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. :-)
Back to top
View user's profile Send private message
Chewi
l33t
l33t


Joined: 01 Sep 2003
Posts: 788
Location: Edinburgh, Scotland

PostPosted: Mon Mar 24, 2014 3:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2717
Location: The Peanut Gallery

PostPosted: Tue Mar 25, 2014 5:44 am    Post subject: Reply with quote

Chewi wrote:
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.

Code:
<greycat> if people are writing ${foo} without any following letters/numbers/underscores, they're either pretentious or ignorant.
# occasionally both

Quote:
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.

OK, I haven't actually run it, so might well be wrong then. Didn't realise it would use existing manifest entries for files it does not have to hand; I'd expect it to verify the data.
Quote:
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.

Oh it's definitely better than using QEMU; I don't see the relevance of that though, to the efficiency of how it's written. I'd expect those steps to happen when I cb-emerge --sync, not every time I run a cb-* command (although triggering it on git changes is a wise check.)

Perhaps via a "$PORTAGE_CONFIGROOT/etc/portage/postsync.d/" hook, but I'd just wrap it in update personally (since I use that for building chroots, and indeed installs.) update --help talks about the onSync() hook.

What about the overlay, means layman can't sync it via git?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum