I have set up a cross compiler but if I use ~arm in the ACCEPT_KEYWORDS in /usr/armv4tl-softfloat-linux-gnueabi/etc/make.conf,
it wants to pull in packages for the host system (baselayout, openrc
and e2fsprogs-lib) which are masked by ~amd64. Is there any reason for
this? It seems that the host package version has to match the cross
compiled package version. I thought the crossdev environment would be
independent? Is there something that I am missing (or have done wrong)?


Regards,

Tim

2009/3/9 Tim Erwin <taerwin@gmail.com>:
> I have set up a cross compiler but if I use ~arm in the ACCEPT_KEYWORDS in
> /usr/armv4tl-softfloat-linux-gnueabi/etc/make.conf, it wants to pull in
> packages for the host system (baselayout, openrc and e2fsprogs-lib) which
> are masked by ~amd64. Is there any reason for this?

If you use the openmoko-overlay it shouldn't. The reason why this
happens is the gentoo dependency oddness. Namely the line
DEPEND="${RDEPEND}", as this tries to emerge everything you want on
the target also to host. However, removing this line is basically not
suggested. We need to add cross-compile dependencies to portage, but
until this happens you can test with removing ${RDEPEND} from the
DEPEND line.

Furthermore, I would suggest to use a chroot to cross-compile your stuff!

Best regards,

Sven

That is really odd ... did you use crossdev-wrapper (e.g.
arm-softfloat-linux-gnueabi-emerge) ?

I think I've experienced something like that before, and it was the
result of an environment variable incorrectly set.

You should run 'arm-softfloat-linux-gnueabi-emerge --info' and check
for any oddities in the portage environment variables. Most of the
important ones should start with /usr/arm-softfloat-linux-gnueabi .

C

On Mon, Mar 9, 2009 at 5:14 AM, Sven Rebhan <odinshorse@googlemail.com> wrote:
> 2009/3/9 Tim Erwin <taerwin@gmail.com>:
>> I have set up a cross compiler but if I use ~arm in the ACCEPT_KEYWORDS in
>> /usr/armv4tl-softfloat-linux-gnueabi/etc/make.conf, it wants to pull in
>> packages for the host system (baselayout, openrc and e2fsprogs-lib) which
>> are masked by ~amd64. Is there any reason for this?
>
> If you use the openmoko-overlay it shouldn't. The reason why this
> happens is the gentoo dependency oddness. Namely the line
> DEPEND="${RDEPEND}", as this tries to emerge everything you want on
> the target also to host. However, removing this line is basically not
> suggested. We need to add cross-compile dependencies to portage, but
> until this happens you can test with removing ${RDEPEND} from the
> DEPEND line.
>
> Furthermore, I would suggest to use a chroot to cross-compile your stuff!
>
> Best regards,
>
> * Sven
>
>

2009/3/9 Christopher Friedt <chrisfriedt@gmail.com>:
> That is really odd ... did you use crossdev-wrapper (e.g.
> arm-softfloat-linux-gnueabi-emerge) ?

This happens also with crossdev-wrappers. Look at the openrc ebuild,
it contains DEPEND=RDEPEND. DEPEND is the interpreted by portage as
"this package is required on HOST as it is required for building that
stuff". Basically we would need more dependency types. I'm currently
thinking about it and will post to the portage-dev list later.

Sven

> > That is really odd ... did you use crossdev-wrapper (e.g.
> > arm-softfloat-linux-gnueabi-emerge) ?

Yes (but note this is only a issue using ~arm)

> This happens also with crossdev-wrappers. Look at the openrc ebuild,
> it contains DEPEND=RDEPEND. DEPEND is the interpreted by portage as
> "this package is required on HOST as it is required for building that
> stuff". *Basically we would need more dependency types. I'm currently
> thinking about it and will post to the portage-dev list later.

Yes openrc and e2fsprogs are the culprits and removing the line
DEPEND=RDEPEND fixes this. But as pointed out by Sven this is not the
best option.

Regards,

Tim