Re: [gentoo-user] cross-compiling environment for Rapberry

[Alexandru N. Barloiu]

On 4/30/2024 12:26 AM, ralfconn wrote:
The crossdev environment on the desktop knows nothing about the packages 
installed on the Pi, so I copied /var/db/pkg from Pi to 
/usr/aarch64-unknown-linux-gnu/var/db/pkg on the desktop. I ran emerge 
--sync on the Pi and on the desktop approximatively at the same time.



this is wrong. so ima gonna assume we talking about crossdev. and 
cross-emerge. which should be the go to tool for this.


but here is the problem. you cant just "mimic" fake packages. which is 
wht you did is.


3 different systems. host system, prolly x86/64. then virtual system. 
then the actual pi. do not confuse them.


profiles are less important. dependencies are important however.

lets say you do USE="xz" ROOT="/someplace" SYSROOT=$ROOT ARCH=$whatever 
cross-emerge gcc. you would need headers and libs not just in the target 
system, but in the building systems as well. not just in the main 
building system, the host system, but based on how and what you are 
doing, you might need to build, dependencies, including in that 
intermediary /usr/$arch.

Re: [gentoo-user] cross-compiling environment for Rapberry

[ralfconn]

Il 01/05/24 19:54, ralfconn ha scritto:

Il 01/05/24 19:05, Michael ha scritto:

I've built the cross toolchain with 'crossdev --taget

aarch64-unknown-linux-gnu' per wiki [2]. I've selected a 23.0-split-usr
profile on the Pi since this is the one supported by the crossdev 
(or so

I understood from the error message when I tried with the non-split-usr
profile on the desktop).
Did you download the correct stage3?  There are split-usr and 
merged-usr tar
archives.  Since split-usr is or will be soon deprecated you better 
start with

merged-usr.
I wasn't clear: when I tried to select the merged-usr profile on the 
host and on the target I got an error invoking 
emerge-aarch64-unknown-linux-gnu on the _host_  telling me that the 
profile was 'merged-usr' but the directory layout wasn't. So the 
problem is in the directory layout created by crossdev on the host.The 
host has a merged-usr profile, I believe the problem is in crossdev 
itself. I tried to manually copy files in the crossdev environment to 
recreate the merged-usr layout but then the error on the host was even 
worse (I forgot what it was) so I went back to split.


Update: stage3 on the pi is merge-usr so the above is bound to fail 
sooner or later (as I discovered trying to emerge 
app-misc/resolve-march-native on the pi). But, the sys-apps/merge-usr 
script accepts a --root parameter, so it is possible to issue, on the host:


# merge-usr --root /usr/aarch64-unknown-linux-gnu

# PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile set 
default/linux/arm64/23.0


and have on the host the same directory layout and profile of the ARM 
stage3 installed on the pi.


raffaele

Re: [gentoo-user] cross-compiling environment for Rapberry

[ralfconn]

Il 01/05/24 19:05, Michael ha scritto:

I've built the cross toolchain with 'crossdev --taget

aarch64-unknown-linux-gnu' per wiki [2]. I've selected a 23.0-split-usr
profile on the Pi since this is the one supported by the crossdev (or so
I understood from the error message when I tried with the non-split-usr
profile on the desktop).

Did you download the correct stage3?  There are split-usr and merged-usr tar
archives.  Since split-usr is or will be soon deprecated you better start with
merged-usr.
I wasn't clear: when I tried to select the merged-usr profile on the 
host and on the target I got an error invoking 
emerge-aarch64-unknown-linux-gnu on the _host_  telling me that the 
profile was 'merged-usr' but the directory layout wasn't. So the problem 
is in the directory layout created by crossdev on the host.The host has 
a merged-usr profile, I believe the problem is in crossdev itself. I 
tried to manually copy files in the crossdev environment to recreate the 
merged-usr layout but then the error on the host was even worse (I 
forgot what it was) so I went back to split.

The crossdev environment on the desktop knows nothing about the packages
installed on the Pi, so I copied /var/db/pkg from Pi to
/usr/aarch64-unknown-linux-gnu/var/db/pkg on the desktop. I ran emerge
--sync on the Pi and on the desktop approximatively at the same time.

 Now If I try a @system update on the Pi I get: 

pihole ~ # emerge -uDvN --ask @system

Why didn't you try '--usepkg y', or '--usepkgonly y' to emerge the precompiled
binaries on the pi?
That is the intention, after I'll manage to set up a workflow to 
crossbuild binary packages on the host :-)

 What am I missing to make the desktop use the same list of packages
to be upgraded as the Pi? 

thanks,

raffaele

[1] https://pi-hole.net/
[2] https://wiki.gentoo.org/wiki/Crossdev

Check the selected make.profile and the stage3 fs are the same on both
buildhost and guest.  Also diff the two /var/lib/portage/world and don't
forget to compare/grep for different USE flags between the two systems.
/etc/portage/make.conf on the pi and in 
/usr/aarch64-unknown-linux-gnu/etc/portage/make.conf on the host are 
almost identical except for host-only feature (e.g. buildpkg is only 
specified on the host side) and number of emerge jobs.

Finally, if nothing works as intended consider compiling in QEMU:

https://wiki.gentoo.org/wiki/Embedded_Handbook/General/
Compiling_with_QEMU_user_chroot


For the moment I am trying a different approach: create a list of 
packages to be updated on the pi and use it as input to 
the emerge-aarch64-unknown-linux-gnu command on the host.


Wow, even an emerge --sync takes forever on the pi, I was no longer used 
to such long delays!


raffaele

Re: [gentoo-user] cross-compiling environment for Rapberry

[Michael]

On Monday, 29 April 2024 22:26:49 BST ralfconn wrote:
> Hello,
> 
> I recently got me a Raspberry Pi4b to use as a PiHole [1]. As a first
> step I put user-space Gentoo (i.e. aarch64 stage3) on it and now I am
> trying to set up my desktop to cross-compile binary packages for the PI,
> to keep the Pi up-to-date in reasonable computing time.

TBH I've had limited success with cross-compiling and this was for an x86 
guest on amd64 buildhost, but I have not tried aarch64 (yet).


> I've built the cross toolchain with 'crossdev --taget
> aarch64-unknown-linux-gnu' per wiki [2]. I've selected a 23.0-split-usr
> profile on the Pi since this is the one supported by the crossdev (or so
> I understood from the error message when I tried with the non-split-usr
> profile on the desktop).

Did you download the correct stage3?  There are split-usr and merged-usr tar 
archives.  Since split-usr is or will be soon deprecated you better start with 
merged-usr.


> The crossdev environment on the desktop knows nothing about the packages
> installed on the Pi, so I copied /var/db/pkg from Pi to
> /usr/aarch64-unknown-linux-gnu/var/db/pkg on the desktop. I ran emerge
> --sync on the Pi and on the desktop approximatively at the same time.
> 
>  Now If I try a @system update on the Pi I get: 
> 
> pihole ~ # emerge -uDvN --ask @system

Why didn't you try '--usepkg y', or '--usepkgonly y' to emerge the precompiled 
binaries on the pi?


> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> Dependency resolution took 31.91 s (backtrack: 0/20).
> 
> [ebuild U  ] sys-libs/ncurses-6.4_p20240414:0/6::gentoo
> [6.4_p20230401:0/6::gentoo] USE="cxx (split-usr*) (tinfo) -ada -debug
> -doc -gpm -minimal -profile (-stack-realign) -static-libs -test -trace
> -verify-sig" 7647 KiB
> [ebuild U  ] sys-apps/baselayout-2.15::gentoo [2.14-r2::gentoo]
> USE="(split-usr*) -build" 30 KiB
> [ebuild U  ] dev-util/re2c-3.1::gentoo [2.2::gentoo] USE="-debug
> -test" 1415 KiB
> [ebuild U  ] dev-util/pkgconf-2.2.0:0/5::gentoo [2.1.1:0/4::gentoo]
> USE="(native-symlinks) -test" 305 KiB
> [ebuild U  ] app-portage/elt-patches-20240415::gentoo
> [20240315::gentoo] 46 KiB
> [ebuild   R] app-alternatives/awk-4::gentoo  USE="gawk (split-usr*)
> -busybox -mawk -nawk" 0 KiB
> [ebuild   R] app-alternatives/bzip2-1::gentoo USE="reference
> (split-usr*) -lbzip2 -pbzip2" 0 KiB
> [ebuild   R] app-alternatives/tar-0::gentoo  USE="gnu (split-usr*)
> -libarchive" 0 KiB
> [ebuild   R] app-alternatives/gzip-1::gentoo  USE="reference
> (split-usr*) -pigz" 0 KiB
> [ebuild U  ] dev-libs/libxml2-2.12.6:2::gentoo [2.12.5:2::gentoo]
> USE="ftp python readline -debug -examples -icu -lzma -static-libs -test"
> PYTHON_TARGETS="python3_11 -python3_10 -python3_12" 2582 KiB
> [ebuild U  ] sys-devel/gettext-0.22.5::gentoo [0.22.4::gentoo]
> USE="acl cxx ncurses nls openmp* (xattr) -doc -emacs -git -java
> -static-libs -verify-sig" 10031 KiB
> [ebuild  N ] app-arch/libarchive-3.7.4:0/13::gentoo USE="acl bzip2
> e2fsprogs iconv lzma xattr zstd -blake2 -expat -lz4 -lzo -nettle
> -static-libs -test -verify-sig" 5291 KiB
> [ebuild U  ] sys-apps/shadow-4.14.6:0/4::gentoo [4.14.2:0/4::gentoo]
> USE="acl nls pam (split-usr*) xattr -audit -cracklib (-selinux) -skey
> -su -systemd -verify-sig" 1764 KiB
> [ebuild  N ] app-crypt/rhash-1.4.4-r1:0/1::gentoo  USE="nls ssl
> -debug -static-libs" 426 KiB
> [ebuild U  ] dev-python/platformdirs-4.2.1::gentoo [4.2.0::gentoo]
> USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_10 -python3_12"
> 20 KiB
> [ebuild  N ] dev-python/backports-tarfile-1.1.1::gentoo USE="-test"
> PYTHON_TARGETS="python3_11 -pypy3 -python3_10" 83 KiB
> [ebuild U  ] dev-python/trove-classifiers-2024.4.10::gentoo
> [2024.3.25::gentoo] USE="-test" PYTHON_TARGETS="python3_11 -pypy3
> -python3_10 -python3_12" 16 KiB
> [ebuild U  ] dev-python/jaraco-context-5.3.0::gentoo [5.1.0::gentoo]
> USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_10 -python3_12"
> 14 KiB
> [ebuild U  ] dev-python/jaraco-functools-4.0.1::gentoo
> [4.0.0::gentoo] USE="-test" PYTHON_TARGETS="python3_11 -pypy3
> -python3_10 -python3_12" 18 KiB
> [ebuild U  ] sys-apps/coreutils-9.5::gentoo [9.4-r1::gentoo]
> USE="acl nls openssl (split-usr*) xattr -caps -gmp -hostname -kill
> -multicall (-selinux) -static -test -vanilla -verify-sig" 5873 KiB
> [ebuild  NS] dev-build/autoconf-2.72-r1:2.72::gentoo
> [2.71-r6:2.71::gentoo] USE="-emacs -verify-sig%" 1358 KiB
> [ebuild U  ] app-eselect/eselect-pinentry-0.7.4::gentoo
> [0.7.3::gentoo] 0 KiB
> [ebuild U  ] dev-perl/XS-Parse-Keyword-0.410.0::gentoo
> [0.380.0::gentoo] USE="-test" 87 KiB
> [ebuild U  ] sys-apps/kmod-32-r1::gentoo [31::gentoo] USE="lzma
> (split-usr%*) (tools) zlib zstd -debug -doc -pkcs7 -static-libs
> (-python%)" PYTHON_TARGETS="(-python3_10%) (-python3_11%*)" 500 KiB
> [ebuild U  ] 

Re: [gentoo-user] cross-compiling environment for Rapberry

[Frank Steinmetzger]

Am Mon, Apr 29, 2024 at 11:26:49PM +0200 schrieb ralfconn:
> Hello,
> 
> I recently got me a Raspberry Pi4b to use as a PiHole [1]. As a first step I
> put user-space Gentoo (i.e. aarch64 stage3) on it and now I am trying to set
> up my desktop to cross-compile binary packages for the PI, to keep the Pi
> up-to-date in reasonable computing time.
> [...]
> /usr/aarch64-unknown-linux-gnu/var/db/pkg on the desktop. I ran emerge
> --sync on the Pi and on the desktop approximatively at the same time.

You could simply rsync the portage tree from one host to the other to get an 
identical state on both.

> [different emerge -u on both hosts]
>
>  What am I missing to make the desktop use the same list of packages to
> be upgraded as the Pi? 

Do you have the same use flags? I’ve never really dealt with crosscompiling. 
Maybe somewhere deep in the system the use flags are changed. Try comparing 
the output of emerge --info from both hosts.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Development aid is to give money from the poor of rich countries
to the rich of poor countries.


signature.asc
Description: PGP signature

[gentoo-user] cross-compiling environment for Rapberry

[ralfconn]

Hello,

I recently got me a Raspberry Pi4b to use as a PiHole [1]. As a first 
step I put user-space Gentoo (i.e. aarch64 stage3) on it and now I am 
trying to set up my desktop to cross-compile binary packages for the PI, 
to keep the Pi up-to-date in reasonable computing time.


I've built the cross toolchain with 'crossdev --taget 
aarch64-unknown-linux-gnu' per wiki [2]. I've selected a 23.0-split-usr 
profile on the Pi since this is the one supported by the crossdev (or so 
I understood from the error message when I tried with the non-split-usr 
profile on the desktop).


The crossdev environment on the desktop knows nothing about the packages 
installed on the Pi, so I copied /var/db/pkg from Pi to 
/usr/aarch64-unknown-linux-gnu/var/db/pkg on the desktop. I ran emerge 
--sync on the Pi and on the desktop approximatively at the same time.


 Now If I try a @system update on the Pi I get: 

pihole ~ # emerge -uDvN --ask @system

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 31.91 s (backtrack: 0/20).

[ebuild U  ] sys-libs/ncurses-6.4_p20240414:0/6::gentoo 
[6.4_p20230401:0/6::gentoo] USE="cxx (split-usr*) (tinfo) -ada -debug 
-doc -gpm -minimal -profile (-stack-realign) -static-libs -test -trace 
-verify-sig" 7647 KiB
[ebuild U  ] sys-apps/baselayout-2.15::gentoo [2.14-r2::gentoo] 
USE="(split-usr*) -build" 30 KiB
[ebuild U  ] dev-util/re2c-3.1::gentoo [2.2::gentoo] USE="-debug 
-test" 1415 KiB
[ebuild U  ] dev-util/pkgconf-2.2.0:0/5::gentoo [2.1.1:0/4::gentoo] 
USE="(native-symlinks) -test" 305 KiB
[ebuild U  ] app-portage/elt-patches-20240415::gentoo 
[20240315::gentoo] 46 KiB
[ebuild   R    ] app-alternatives/awk-4::gentoo  USE="gawk (split-usr*) 
-busybox -mawk -nawk" 0 KiB
[ebuild   R    ] app-alternatives/bzip2-1::gentoo USE="reference 
(split-usr*) -lbzip2 -pbzip2" 0 KiB
[ebuild   R    ] app-alternatives/tar-0::gentoo  USE="gnu (split-usr*) 
-libarchive" 0 KiB
[ebuild   R    ] app-alternatives/gzip-1::gentoo  USE="reference 
(split-usr*) -pigz" 0 KiB
[ebuild U  ] dev-libs/libxml2-2.12.6:2::gentoo [2.12.5:2::gentoo] 
USE="ftp python readline -debug -examples -icu -lzma -static-libs -test" 
PYTHON_TARGETS="python3_11 -python3_10 -python3_12" 2582 KiB
[ebuild U  ] sys-devel/gettext-0.22.5::gentoo [0.22.4::gentoo] 
USE="acl cxx ncurses nls openmp* (xattr) -doc -emacs -git -java 
-static-libs -verify-sig" 10031 KiB
[ebuild  N ] app-arch/libarchive-3.7.4:0/13::gentoo USE="acl bzip2 
e2fsprogs iconv lzma xattr zstd -blake2 -expat -lz4 -lzo -nettle 
-static-libs -test -verify-sig" 5291 KiB
[ebuild U  ] sys-apps/shadow-4.14.6:0/4::gentoo [4.14.2:0/4::gentoo] 
USE="acl nls pam (split-usr*) xattr -audit -cracklib (-selinux) -skey 
-su -systemd -verify-sig" 1764 KiB
[ebuild  N ] app-crypt/rhash-1.4.4-r1:0/1::gentoo  USE="nls ssl 
-debug -static-libs" 426 KiB
[ebuild U  ] dev-python/platformdirs-4.2.1::gentoo [4.2.0::gentoo] 
USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_10 -python3_12" 
20 KiB
[ebuild  N ] dev-python/backports-tarfile-1.1.1::gentoo USE="-test" 
PYTHON_TARGETS="python3_11 -pypy3 -python3_10" 83 KiB
[ebuild U  ] dev-python/trove-classifiers-2024.4.10::gentoo 
[2024.3.25::gentoo] USE="-test" PYTHON_TARGETS="python3_11 -pypy3 
-python3_10 -python3_12" 16 KiB
[ebuild U  ] dev-python/jaraco-context-5.3.0::gentoo [5.1.0::gentoo] 
USE="-test" PYTHON_TARGETS="python3_11 -pypy3 -python3_10 -python3_12" 
14 KiB
[ebuild U  ] dev-python/jaraco-functools-4.0.1::gentoo 
[4.0.0::gentoo] USE="-test" PYTHON_TARGETS="python3_11 -pypy3 
-python3_10 -python3_12" 18 KiB
[ebuild U  ] sys-apps/coreutils-9.5::gentoo [9.4-r1::gentoo] 
USE="acl nls openssl (split-usr*) xattr -caps -gmp -hostname -kill 
-multicall (-selinux) -static -test -vanilla -verify-sig" 5873 KiB
[ebuild  NS    ] dev-build/autoconf-2.72-r1:2.72::gentoo 
[2.71-r6:2.71::gentoo] USE="-emacs -verify-sig%" 1358 KiB
[ebuild U  ] app-eselect/eselect-pinentry-0.7.4::gentoo 
[0.7.3::gentoo] 0 KiB
[ebuild U  ] dev-perl/XS-Parse-Keyword-0.410.0::gentoo 
[0.380.0::gentoo] USE="-test" 87 KiB
[ebuild U  ] sys-apps/kmod-32-r1::gentoo [31::gentoo] USE="lzma 
(split-usr%*) (tools) zlib zstd -debug -doc -pkcs7 -static-libs 
(-python%)" PYTHON_TARGETS="(-python3_10%) (-python3_11%*)" 500 KiB
[ebuild U  ] app-crypt/pinentry-1.3.0-r2::gentoo [1.2.1-r4::gentoo] 
USE="ncurses -X -caps -efl -emacs -gtk -keyring -qt5 (-qt6) -verify-sig 
-wayland" 597 KiB
[ebuild U  ] dev-lang/tcl-8.6.14:0/8.6::gentoo 
[8.6.13-r1:0/8.6::gentoo] USE="threads -debug" 6916 KiB
[ebuild  N ] dev-libs/libuv-1.48.0:0/1::gentoo USE="-verify-sig" 
1285 KiB
[ebuild U  ] dev-perl/Syntax-Keyword-Try-0.290.0::gentoo 
[0.280.0::gentoo] USE="-test" 45 KiB
[ebuild U  ] app-text/po4a-0.71::gentoo [0.69::gentoo] USE="-test" 
4747 KiB
[ebuild U  ] app-portage/portage-utils-0.97::gentoo [0.96.1::gentoo] 
USE="openmp* 

Re: [gentoo-user] cross compiling arm with 17 profiles.

[R0b0t1]

Hello,

On Sun, Dec 17, 2017 at 8:14 AM, Mart Raudsepp  wrote:
> On P, 2017-12-17 at 16:50 +0800, Bill Kenworthy wrote:
>> Something I cant figure out:
>>
>> ARM is still on the 13 profiles - should an amd64 system used to
>> cross
>> compile for arm (Raspberry Pi's) be left on the 13 profiles or 17
>> will
>> work fine?
>
> ARM profiles are delayed to potentially fix CHOSTs together with the
> profile update. Though no-one is actively doing the work to my
> knowledge right now.
>
> I guess it could cause trouble from default PIE vs no PIE from native
> compiler, but I don't know enough about that field to know for sure.
>

If you know anything at all that is more than myself, so can you link
to past discussions that you are aware of?

> If you pay attention to any future CHOST changes and handle them
> yourself at the right time, you could manually choose the appropriate
> 17.0 arm profile as your symlink (it doesn't show up in eselect profile
> due to no profiles.desc entry, but should be there in profiles/). If
> changes are done, you might be caught a bit off-guard though at the
> time they are done though and I'm not sure what the effects of that
> would be either (probably not too bad).
>

My experience with ARM(64) is that it is mature enough that you can
expect @system to work unless proven otherwise. Lots of other packages
have failures.

Cheers,
 R0b0t1

Re: [gentoo-user] cross compiling arm with 17 profiles.

[Mart Raudsepp]

On P, 2017-12-17 at 16:50 +0800, Bill Kenworthy wrote:
> Something I cant figure out:
> 
> ARM is still on the 13 profiles - should an amd64 system used to
> cross
> compile for arm (Raspberry Pi's) be left on the 13 profiles or 17
> will
> work fine?

ARM profiles are delayed to potentially fix CHOSTs together with the
profile update. Though no-one is actively doing the work to my
knowledge right now.

I guess it could cause trouble from default PIE vs no PIE from native
compiler, but I don't know enough about that field to know for sure.

If you pay attention to any future CHOST changes and handle them
yourself at the right time, you could manually choose the appropriate
17.0 arm profile as your symlink (it doesn't show up in eselect profile
due to no profiles.desc entry, but should be there in profiles/). If
changes are done, you might be caught a bit off-guard though at the
time they are done though and I'm not sure what the effects of that
would be either (probably not too bad).

[gentoo-user] cross compiling arm with 17 profiles.

[Bill Kenworthy]

Something I cant figure out:

ARM is still on the 13 profiles - should an amd64 system used to cross
compile for arm (Raspberry Pi's) be left on the 13 profiles or 17 will
work fine?

BillK

Re: [gentoo-user] Cross-compiling for an unstable architecture.

[Stroller]

> On 23 Feb 2017, at 22:21, R0b0t1  wrote:
> 
> However it's gotten to the point where not even building on-device
> works. I'm experiencing breakage in a lot of core packages that may or
> may not be related to portage. What is the best way to ask for help?
> The users on the forums and IRC do not seem to really know how to go
> about solving some of the problems or do not have the time, and I'm
> not sure it's polite to open up a bunch of bug reports on
> https://bugs.gentoo.org. What seems to complicate this is solving some
> of the issues looks like it will take knowledge only the developers of
> the corresponding software have.

I've taken bugs upstream in the past, including with gcc and glibc. 

I've also filed bugs with bugs.gentoo.org, but response times can be variable 
in my experience. If you file a bug about something minor for a package that a 
dev happens to be interested in it'll probably get picked up quickly, but the 
Gentoo devs don't have the manpower to fix everything quickly.

One of my bugs was for how gcc handled --march-native on the AMD K6-2 CPU (in 
the Cobalt Qube 3) - it was misdetected as an Athlon or Duron, gcc created 
binaries with an instruction unrecognised by the CPU and hence packages 
compiled fine but crashed as soon as you ran the program (I noticed this with 
vim, soon after I installed the box). I found a couple of ways to document what 
was happening, posted for help on the gcc mailing list and someone posted a 
patch within a few weeks.

Once I confirmed the patch worked, it was added to the gcc tree and was in a 
new release within another few weeks. It wasn't the quickest experience I've 
had getting help from an open source developer - when I had a problem with 
dovecot its developer had a patch (which worked) for me to test the next day - 
but no-one was rude to me or made me feel unwelcome. I'm no-one of importance, 
but the gcc list helped me, fixed my bug and treated me as good as anyone else.

Of course the Gentoo devs are just as helpful, but they don't normally spend 
their days fixing compiler bugs. Better IMO for you to take the problem 
upstream yourself, and then when it's fixed open a ticket on bugs.gentoo.org 
saying "this is the problem, it's fixed in release 1.2.3.4 of gcc, please add 
this to the tree ASAP as it's needed for arm64". IMO this is a good was for 
people like us to contribute to the distro.

I'd expect everything you need, at least for an initial report, is in the 
emerge logs - surely all they do is dump the compiler output to a textfile? So 
you're taking the compiler output to the authors of the compiler - that's what 
they need to see in order to help you and fix problems with their program. It's 
helpful that you Gentoo is a fairly vanilla-upstream distro.

Stroller.

Re: [gentoo-user] Cross-compiling for an unstable architecture.

[Andrew Savchenko]

On Thu, 23 Feb 2017 16:21:04 -0600 R0b0t1 wrote:
> Hello,
> 
> So apparently I am single-handedly attempting to stabilize arm64 (at
> least, it feels that way). Per the "Gentoo on Alternative
> Architectures" subforum
> (https://forums.gentoo.org/viewforum-f-32.html) two users have gotten
> almost everything working, in some cases having to resort to building
> packages not in @system on-device. Ideally I want to be able to build
> every package I make use of from my desktop but in some cases this
> will involve bug reports to the projects to see if they will change
> their build process.
> 
> However it's gotten to the point where not even building on-device
> works. I'm experiencing breakage in a lot of core packages that may or
> may not be related to portage. What is the best way to ask for help?
> The users on the forums and IRC do not seem to really know how to go
> about solving some of the problems or do not have the time, and I'm
> not sure it's polite to open up a bunch of bug reports on
> https://bugs.gentoo.org. What seems to complicate this is solving some
> of the issues looks like it will take knowledge only the developers of
> the corresponding software have.

Get in touch with the arm Gentoo team. If you sure your fix is
correct, open bugs on bugzilla. There is nothing wrong in opening
tons of good bug reports with patches :)

Best regards,
Andrew Savchenko


pgpfTa_N6QIrm.pgp
Description: PGP signature

[gentoo-user] Cross-compiling for an unstable architecture.

[R0b0t1]

Hello,

So apparently I am single-handedly attempting to stabilize arm64 (at
least, it feels that way). Per the "Gentoo on Alternative
Architectures" subforum
(https://forums.gentoo.org/viewforum-f-32.html) two users have gotten
almost everything working, in some cases having to resort to building
packages not in @system on-device. Ideally I want to be able to build
every package I make use of from my desktop but in some cases this
will involve bug reports to the projects to see if they will change
their build process.

However it's gotten to the point where not even building on-device
works. I'm experiencing breakage in a lot of core packages that may or
may not be related to portage. What is the best way to ask for help?
The users on the forums and IRC do not seem to really know how to go
about solving some of the problems or do not have the time, and I'm
not sure it's polite to open up a bunch of bug reports on
https://bugs.gentoo.org. What seems to complicate this is solving some
of the issues looks like it will take knowledge only the developers of
the corresponding software have.

R0b0t1.

Re: [gentoo-user] cross-compiling mosh

[Stefan G. Weichinger]

Am 13.09.2013 19:54, schrieb Stefan G. Weichinger:
 Am 12.09.2013 16:55, schrieb Yohan Pereira:
 On 12/09/13 at 09:21am, Stefan G. Weichinger wrote:
 ps: anyone using mosh already? Experiences? opinions?


Could someone tell me just from a general point of view if I could just
*try* to copy my gentoo-binaries over and test them or if I should not
do that to not crash that server?

;-)

Thanks!

Re: [gentoo-user] cross-compiling mosh

[Stefan G. Weichinger]

Am 12.09.2013 16:55, schrieb Yohan Pereira:
 On 12/09/13 at 09:21am, Stefan G. Weichinger wrote:
 ps: anyone using mosh already? Experiences? opinions?
 
 I've been using mosh for almost a month now for my remote servers and
 when I'm away, for my workstation. I like the local echo and the
 persistent session over dodgy network connections. I can restart my
 router without worrying about re connecting via ssh. The responsiveness
 on high latency servers is also a big + for me.
 
 Set-up is also fairly straightforward just need to get the locale getup
 right. Mis-configured locale was the only issue I've ran into so far. 

I still have to get used to it ... some things are different ... for
example scrolling up the terminal history and colors.

S

[gentoo-user] cross-compiling mosh

[Stefan G. Weichinger]

I read about mosh http://mosh.mit.edu/ only yesterday and installed it
on some of my systems to get started with it.

I have a server at a customer which I access through an IPSEC tunnel ...
for some reason the openssh-connection somehow stalls and even playing
with the IPSEC-params didn't help much ...

Might have to do with changing my router (right now a pfsense, earlier
an ipfire-installation on an ALIX board) .. and the other side is
running Cisco ... so ... you know.

So I am rather curious if mosh could somehow help here.

Unfortunately there are now binaries for the old SLES 10 that server
runs. And the dependencies aren't there right now .. so I wonder if I
could pre-compile mosh on my gentoo box ...

I hesitate to just copy it over and execute it as I am definitely not
paid to crash their servers ;-)

The SLES says:

# uname -a
Linux juno 2.6.16.60-0.66.1-smp #1 SMP Fri May 28 12:10:21 UTC 2010
x86_64 x86_64 x86_64 GNU/Linux

Anything to consider here ... ? possible?

Thanks!

Stefan

ps: anyone using mosh already? Experiences? opinions?

Re: [gentoo-user] cross-compiling mosh

[Yohan Pereira]

On 12/09/13 at 09:21am, Stefan G. Weichinger wrote:
 ps: anyone using mosh already? Experiences? opinions?

I've been using mosh for almost a month now for my remote servers and
when I'm away, for my workstation. I like the local echo and the
persistent session over dodgy network connections. I can restart my
router without worrying about re connecting via ssh. The responsiveness
on high latency servers is also a big + for me.

Set-up is also fairly straightforward just need to get the locale getup
right. Mis-configured locale was the only issue I've ran into so far. 

-- 

- Yohan Pereira

The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
-- Mark Twain

Re: [gentoo-user] Cross Compiling in Gentoo

[Helmut Jarausch]

On 01/18/2012 01:18:03 AM, Mike Edenfield wrote:
 While I program a lot on my Linux machines, I haven't actually found
 an IDE that doesn't make me wish VS ran on Linux. 

Did you have a look at CodeLite  (www.codelite.org) ?

If you like, I can send you an ebuild for it (but you
can install it under /usr/local, as well).

Helmut.

Re: [gentoo-user] Cross Compiling in Gentoo

[Joerg Schilling]

Chris Walters cjw20...@comcast.net wrote:

 I have a question about cross compiling in Gentoo - specifically cross
 compiling for W32/W64.  I tried their preferred method and didn't like it, so 
 I
 downloaded the appropriate Mingw64 build files, set up a cross compile 
 account,
 with the appropriate paths, variables, etc.  Most packages compile correctly
 (though it sometimes takes some code hacking - and yes they do run in Win 7),
 but there are some I can't seem to get to build properly - usually the ones
 that have make files for MS Visual Studio.  I have no interest in purchasing
 Visual Studio.

 My question is, does anyone know of any good resources (mailing lists, sites,
 etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform?  The
 searches I've run have directed me to sites that talk about using MSYS and
 Mingw on a W32 platform (I don't have all year to build a single package).  I
 am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd
 accept W32, if that's the only way).

I am not sure what you really like. Cross compiling is a general problem and 
not related to a specific distro.

For your specific problem: it is most unlikely that you will get a MS cross 
compiler that runs on other platforms than WIN-DOS.

In general: The most annoying problem with cross compiling is that GNU autoconf 
does not support cross compiling and as a result, you need to manually create 
results if you like to cross compile. The reason for this problem is that many 
autoconf tests need to be run on the target platform in order to create useful 
results.

Since July 2011, the Schily autoconf system (available e.g. via: 
ftp://ftp.berlios.de/pub/schily) includes support for cross compiling by 
detecting cross compilation and by running those tests that need the target 
system either on a related target system or on an emulator. Note that the 
autoconf configuration in ftp://ftp.berlios.de/pub/schily includes aprox. 700
autoconf tests - 70 of these tests need to be run on the target, this can be 
seen as a hint that aprox. 10% of the tests need to be run on the target.

As you see, your question cannot be easily answered.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Cross Compiling in Gentoo

[Chris Walters]

On 1/17/2012 06:41 AM, Joerg Schilling wrote:
 I am not sure what you really like. Cross compiling is a general problem 
 and 
 not related to a specific distro.
 
 For your specific problem: it is most unlikely that you will get a MS cross 
 compiler that runs on other platforms than WIN-DOS.
 
 In general: The most annoying problem with cross compiling is that GNU 
 autoconf 
 does not support cross compiling and as a result, you need to manually create 
 results if you like to cross compile. The reason for this problem is that 
 many 
 autoconf tests need to be run on the target platform in order to create 
 useful 
 results.
 
 Since July 2011, the Schily autoconf system (available e.g. via: 
 ftp://ftp.berlios.de/pub/schily) includes support for cross compiling by 
 detecting cross compilation and by running those tests that need the target 
 system either on a related target system or on an emulator. Note that the 
 autoconf configuration in ftp://ftp.berlios.de/pub/schily includes aprox. 700
 autoconf tests - 70 of these tests need to be run on the target, this can be 
 seen as a hint that aprox. 10% of the tests need to be run on the target.
 
 As you see, your question cannot be easily answered.
 
 Jörg

I am using the equivalent of the Debian cross compiler - without Debian.  This
has been used to cross compile many 32 bit applications from Debian for W32,
from what I understand.  I have managed to cross compile bzip2, lame, libogg,
libvorbis, vorbis-tools, and a few others - they all work.  With most, I only
needed to set the correct path (to mingw), and specify the tools and target and
run the configure script.  I ran into problems with gzip and zlib, however.

Thanks for the link, I will look into it.  Though I hate the idea of running
msys and mingw or anything like that in a W64 environment.

The really annoying thing for me is that if you look at the Mingw64 site on
sourceforge, they indicate that you can cross compile from a GNU/Linux
distribution to W32 or W64 - and they give a list of apps that were
successfully cross compiled, but little in the way of documentation.

Chris



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Cross Compiling in Gentoo

[Mike Edenfield]

On 1/17/2012 1:55 AM, Chris Walters wrote:

Hi,

I have a question about cross compiling in Gentoo - specifically cross
compiling for W32/W64.  I tried their preferred method and didn't like it, so I
downloaded the appropriate Mingw64 build files, set up a cross compile account,
with the appropriate paths, variables, etc.  Most packages compile correctly
(though it sometimes takes some code hacking - and yes they do run in Win 7),
but there are some I can't seem to get to build properly - usually the ones
that have make files for MS Visual Studio.  I have no interest in purchasing
Visual Studio.


Just a point of interest: Visual Studio doesn't use 
Makefiles; Visual C++ can import Makefile projects if you 
ask it to, but it has its own project file format. If you're 
seeing actual make files (and not, say, a .sln file or 
.cproj file) then you don't need Studio, just an 
nmake-compatible version of make.


If you do have project and solution files from Visual 
Studio, they are just MSBuild projects (think ant for 
Windows). I'm pretty sure there are open-source variants of 
MSBuild, possibly in the Mono project?


And of course, Visual C++ Express is free, though you'd need 
to find somewhere to set it up.



My question is, does anyone know of any good resources (mailing lists, sites,
etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform?  The
searches I've run have directed me to sites that talk about using MSYS and
Mingw on a W32 platform (I don't have all year to build a single package).  I
am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd
accept W32, if that's the only way).

Chris

Re: [gentoo-user] Cross Compiling in Gentoo

[Mike Edenfield]

On 1/17/2012 6:41 AM, Joerg Schilling wrote:

Chris Walterscjw20...@comcast.net  wrote:


I have a question about cross compiling in Gentoo - specifically cross
compiling for W32/W64.  I tried their preferred method and didn't like it, so I
downloaded the appropriate Mingw64 build files, set up a cross compile account,
with the appropriate paths, variables, etc.  Most packages compile correctly
(though it sometimes takes some code hacking - and yes they do run in Win 7),
but there are some I can't seem to get to build properly - usually the ones
that have make files for MS Visual Studio.  I have no interest in purchasing
Visual Studio.

My question is, does anyone know of any good resources (mailing lists, sites,
etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform?  The
searches I've run have directed me to sites that talk about using MSYS and
Mingw on a W32 platform (I don't have all year to build a single package).  I
am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd
accept W32, if that's the only way).



For your specific problem: it is most unlikely that you will get a MS cross
compiler that runs on other platforms than WIN-DOS.


I've had very good luck with gcc's x86_64-w64-mingw32 
target, and gcc has supported Win32 builds for years, so I 
dunno why you think this is unlikely. My biggest problem 
with MingW has been their occasional lag behind gcc in 
versions, but I believe gcc 4.5 can cross-compile for 64-bit 
Windows.


The setup is rather a pain but then again, if you wanted 
easy, you probably wouldn't be using Gentoo :)


http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler

For the OP's specific problem, I'll have to try and build 
GraphicsMagick on Gentoo and see what kind of build 
structure is uses that is giving him problems but its 
possible he just needs xbuild (the Mono msbuild 
implementation.) Worst case it has an old VC++-style 
workspace but those are usually just auto-generated out of 
the makefiles anyway.


--Mike

Re: [gentoo-user] Cross Compiling in Gentoo

[YoYo Siska]

On Tue, Jan 17, 2012 at 01:55:25AM -0500, Chris Walters wrote:
 My question is, does anyone know of any good resources (mailing lists, sites,
 etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform?  The
 searches I've run have directed me to sites that talk about using MSYS and
 Mingw on a W32 platform (I don't have all year to build a single package).  I
 am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd
 accept W32, if that's the only way).

You should also ask on the gentoo-embedded mailling list. Mingw might not
be reallly 'embedded' but that list would still be the most relevant
place to ask gentoo-related crosscompile questions...
Gentoo also has a crossdev tool that should also support mingw, though I
only ever used it for i686 and arm crosscompiles.

yoyo

Re: [gentoo-user] Cross Compiling in Gentoo

[Chris Walters]

On 1/17/2012 08:39 AM, Mike Edenfield wrote:
 On 1/17/2012 1:55 AM, Chris Walters wrote:
 that have make files for MS Visual Studio.  I have no interest in purchasing
 Visual Studio.
 
 Just a point of interest: Visual Studio doesn't use Makefiles; Visual C++ 
 can
 import Makefile projects if you ask it to, but it has its own project file
 format. If you're seeing actual make files (and not, say, a .sln file or 
 .cproj
 file) then you don't need Studio, just an nmake-compatible version of make.
 
 If you do have project and solution files from Visual Studio, they are just
 MSBuild projects (think ant for Windows). I'm pretty sure there are
 open-source variants of MSBuild, possibly in the Mono project?
 
 And of course, Visual C++ Express is free, though you'd need to find somewhere
 to set it up.

Just a note:  I used to do all of my programming in Visual Studio.  I stopped
when I needed to do things that VS wouldn't let me do, and also because I
discovered GNU/Linux.

As for the types of files I've seen, I have seen both VS Solution/Project
files, and nmake files.  Most of the time, I just use the configure script with
x86_64-w64-mingw32 as my host, and it works fine.

Do you, by chance, know where I can find an nmake-compatible version of make?
Also, do you have a link for Visual C++ Express?  I like to do most programming
in C/C++ anyway (though this is OT).

Thanks for your reply, it was enlightening...  When I did most of my
programming, portability was not an issue - now it is virtually a must.

Chris


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120117-0, 01/17/2012
Tested on: 1/17/2012 9:26:56 AM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [gentoo-user] Cross Compiling in Gentoo

[Joerg Schilling]

Chris Walters cjw20...@comcast.net wrote:

 I am using the equivalent of the Debian cross compiler - without Debian.  This
 has been used to cross compile many 32 bit applications from Debian for W32,
 from what I understand.  I have managed to cross compile bzip2, lame, libogg,
 libvorbis, vorbis-tools, and a few others - they all work.  With most, I only
 needed to set the correct path (to mingw), and specify the tools and target 
 and
 run the configure script.  I ran into problems with gzip and zlib, however.

 Thanks for the link, I will look into it.  Though I hate the idea of running
 msys and mingw or anything like that in a W64 environment.

 The really annoying thing for me is that if you look at the Mingw64 site on
 sourceforge, they indicate that you can cross compile from a GNU/Linux
 distribution to W32 or W64 - and they give a list of apps that were
 successfully cross compiled, but little in the way of documentation.

GNU autoconf allows to set up default results for cross compiling when trying 
to test things that need to run on the target.

Some of the basic GNU text utils either return most pessimistic values in case 
of a cross compilation or someone did handcraft the related results for MinGW 
and publishes such a modified source that probably will no longer compile 
correctly on other systems.

BTW: I introduced the cross compilation extensions to schily autoconmf in order 
to permit to compile my software for android.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Cross Compiling in Gentoo

[Joerg Schilling]

Chris Walters cjw20...@comcast.net wrote:

 Do you, by chance, know where I can find an nmake-compatible version of make?

Be careful microsofts nmake is not compatible to nmake

nmake has been written by David Korn and Glenn Fowler in the mid 1980s.

Microsoft much later resused the name for something non-compatible.

It does not make sense to look at the MS nmake syntay as it is completely 
non-portable.


Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Cross Compiling in Gentoo

[Michael Mol]

Mike Edenfield wrote:
 On 1/17/2012 1:55 AM, Chris Walters wrote:
 Hi,

 I have a question about cross compiling in Gentoo - specifically cross
 compiling for W32/W64.  I tried their preferred method and didn't like
 it, so I
 downloaded the appropriate Mingw64 build files, set up a cross compile
 account,
 with the appropriate paths, variables, etc.  Most packages compile
 correctly
 (though it sometimes takes some code hacking - and yes they do run in
 Win 7),
 but there are some I can't seem to get to build properly - usually the
 ones
 that have make files for MS Visual Studio.  I have no interest in
 purchasing
 Visual Studio.
 
 Just a point of interest: Visual Studio doesn't use Makefiles; Visual
 C++ can import Makefile projects if you ask it to, but it has its own
 project file format. If you're seeing actual make files (and not, say, a
 .sln file or .cproj file) then you don't need Studio, just an
 nmake-compatible version of make.
 
 If you do have project and solution files from Visual Studio, they are
 just MSBuild projects (think ant for Windows). I'm pretty sure there
 are open-source variants of MSBuild, possibly in the Mono project?
 
 And of course, Visual C++ Express is free, though you'd need to find
 somewhere to set it up.

You don't even need that much; you can just use the Windows SDK to get
the compilers. (I don't know if it comes with MSBuild, though) The
Windows SDK might work via WINE, dunno.

http://www.microsoft.com/downloads/dlx/en-us/listdetailsview.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b

 
 My question is, does anyone know of any good resources (mailing lists,
 sites,
 etc.) on cross compiling on a GNU/Linux platform for a W32/W64
 platform?  The
 searches I've run have directed me to sites that talk about using MSYS
 and
 Mingw on a W32 platform (I don't have all year to build a single
 package).
 I
 am looking to build GraphicsMagick, and some helpful tools for W64
 (though I'd
 accept W32, if that's the only way).

info gcc tells me that the install of gcc on my Gentoo box supports
the mingw target. eix mingw shows me that there are ebuilds for the
import libraries, but they're hardmasked on my amd64 system for some reason.

RE: [gentoo-user] Cross Compiling in Gentoo

[Mike Edenfield]

 From: Chris Walters [mailto:cjw20...@comcast.net]
 Sent: Tuesday, January 17, 2012 9:27 AM
 
 On 1/17/2012 08:39 AM, Mike Edenfield wrote:
  On 1/17/2012 1:55 AM, Chris Walters wrote:
  that have make files for MS Visual Studio.  I have no interest in
  purchasing Visual Studio.
 
  Just a point of interest: Visual Studio doesn't use Makefiles;
  Visual C++ can import Makefile projects if you ask it to, but it has
  its own project file format. If you're seeing actual make files (and
  not, say, a .sln file or .cproj
  file) then you don't need Studio, just an nmake-compatible version of
 make.
 
  If you do have project and solution files from Visual Studio, they are
  just MSBuild projects (think ant for Windows). I'm pretty sure there
  are open-source variants of MSBuild, possibly in the Mono project?
 
  And of course, Visual C++ Express is free, though you'd need to find
  somewhere to set it up.
 
 Just a note:  I used to do all of my programming in Visual Studio.  I stopped
 when I needed to do things that VS wouldn't let me do, and also because I
 discovered GNU/Linux.

While I program a lot on my Linux machines, I haven't actually found an IDE 
that doesn't make me wish VS ran on Linux. MonoDevelop isn't horrible but if I 
wanted to write .NET code I'd just use Windows; Eclipse makes me want to drill 
my brain out with a corkscrew and the only other decent IDE's I've seen are 
KDE-specific. I've falling back to the default of Emacs at this point; it's 
powerful enough, especially when I'm doing Lisp or Scheme, but I have an 
internal mental limit of 150,110 hotkey combinations that I think is holding me 
back. If you have any suggestions I'm all ears :)
 
 As for the types of files I've seen, I have seen both VS Solution/Project 
 files,
 and nmake files.  Most of the time, I just use the configure script with
 x86_64-w64-mingw32 as my host, and it works fine.
 
 Do you, by chance, know where I can find an nmake-compatible version of
 make?

 Also, do you have a link for Visual C++ Express?  I like to do most
 programming in C/C++ anyway (though this is OT).

Well, if you're willing to go the install a Windows OS route, everything you 
need command-line wise is found in the Windows SDK: 
http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx.  
Visual C++ 2010 Express can be downloaded from: 

http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express
 
Mostly what you lose with Express are the TFS integrations, unit testing, and 
other application lifecycle management stuff they pack into the full 
editions. Express editions can't build  debug 64-bit applications, but the 
64-bit compilers come with the SDK. Depends on how much effort you're willing 
to put into it. 

If you don't want to install Windows you're options are going to be mostly 
limited to the GNU binutils and GCC, which support targeting Win32 and Win64.  
In theory you could run the command-line tools, for example, under Wine, but 
I've never tried it. I don't actually know of a make for Linux that is 
compatible with NMAKE. If you can't find one then you'll need to do a lot of 
work to build any applications that require it. However, I think the number of 
applications using Microsoft make files is vanishingly small: they're either 
going to produce a GNU makefile (since GNU make runs on Windows) or an MSBuild 
project.

And yes, ATT also released a tool called nmake that is not compatible with 
Microsoft NMAKE (or either of the other two incompatible makes), so don't get 
them confused.

--Mike

[gentoo-user] Cross Compiling in Gentoo

[Chris Walters]

Hi,

I have a question about cross compiling in Gentoo - specifically cross
compiling for W32/W64.  I tried their preferred method and didn't like it, so I
downloaded the appropriate Mingw64 build files, set up a cross compile account,
with the appropriate paths, variables, etc.  Most packages compile correctly
(though it sometimes takes some code hacking - and yes they do run in Win 7),
but there are some I can't seem to get to build properly - usually the ones
that have make files for MS Visual Studio.  I have no interest in purchasing
Visual Studio.

My question is, does anyone know of any good resources (mailing lists, sites,
etc.) on cross compiling on a GNU/Linux platform for a W32/W64 platform?  The
searches I've run have directed me to sites that talk about using MSYS and
Mingw on a W32 platform (I don't have all year to build a single package).  I
am looking to build GraphicsMagick, and some helpful tools for W64 (though I'd
accept W32, if that's the only way).

Chris





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Cross-compiling

[Dan Farrell]

On Thu, 25 Oct 2007 23:32:13 -0300
Davi [EMAIL PROTECTED] wrote:

 Em Qui 25 Out 2007, Iain Buchanan escreveu:
  On Sat, 2007-10-20 at 17:23 +0300, Stratos Psomadakis wrote:
   O/H Michael Sullivan έγραψε:
 [...]
   and of course start distccd in each partitipating pc...
 
  but after all that, some ebuilds don't let you use distcc because it
  seems to break them.  So don't expect it to work for everything.
 
 
 # FEATURES=-distcc emerge --ask --resume
 
   will be your friend... :-)
 

Another option is to nfs-mount the client's hard drive on the fast
box,  bind a portage tree into the filesystem, chroot  proceed to
emerge.  

Or you could build the whole filesystem on the server, and push changes
out to the client with rsync or some such thing.  I don't know how to
use rsync for this, but I believe it's what it's for.  

--
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Cross-compiling

[Iain Buchanan]

On Sat, 2007-10-20 at 17:23 +0300, Stratos Psomadakis wrote:
 O/H Michael Sullivan έγραψε:
  I've read over the guide at
  http://www.gentoo.org/doc/en/cross-compiling-distcc.xml about
  cross-compiling with distcc.  This may be a really stupid question, but
  how do I force my slow box to use cross-compiling via distcc?  Is there
  some special option I have to pass to emerge to invoke it?  The guide
  was not very clear on that point
 

 look here: http://www.gentoo.org/doc/en/distcc.xml
 you just have to put distcc in FEATURES in make.conf...
 and use distcc-config --set-hosts to specify the participating machines...

make sure you put the other faster machines first in the host list.

 and of course start distccd in each partitipating pc...

but after all that, some ebuilds don't let you use distcc because it
seems to break them.  So don't expect it to work for everything.

cya,
-- 
Iain Buchanan iaindb at netspace dot net dot au

The complexity of software is an essential property, not an accidental one.
Hence, descriptions of a software entity that abstract away its complexity
often abstract away its essence.
- Fred Brooks, Jr.

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Cross-compiling

[Davi]

Em Qui 25 Out 2007, Iain Buchanan escreveu:
 On Sat, 2007-10-20 at 17:23 +0300, Stratos Psomadakis wrote:
  O/H Michael Sullivan έγραψε:
[...]
  and of course start distccd in each partitipating pc...

 but after all that, some ebuilds don't let you use distcc because it
 seems to break them.  So don't expect it to work for everything.


# FEATURES=-distcc emerge --ask --resume

will be your friend... :-)

-- 
Davi Vidal
--
E-mail: [EMAIL PROTECTED]
MSN   : [EMAIL PROTECTED]
GTalk : [EMAIL PROTECTED]
Skype : davi vidal
ICQ   : 138815296


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Cross-compiling

[Stratos Psomadakis]

O/H Michael Sullivan έγραψε:
 I've read over the guide at
 http://www.gentoo.org/doc/en/cross-compiling-distcc.xml about
 cross-compiling with distcc.  This may be a really stupid question, but
 how do I force my slow box to use cross-compiling via distcc?  Is there
 some special option I have to pass to emerge to invoke it?  The guide
 was not very clear on that point

   
look here: http://www.gentoo.org/doc/en/distcc.xml
you just have to put distcc in FEATURES in make.conf...
and use distcc-config --set-hosts to specify the participating machines...
and of course start distccd in each partitipating pc...



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Cross-compiling

[Michael Sullivan]

I've read over the guide at
http://www.gentoo.org/doc/en/cross-compiling-distcc.xml about
cross-compiling with distcc.  This may be a really stupid question, but
how do I force my slow box to use cross-compiling via distcc?  Is there
some special option I have to pass to emerge to invoke it?  The guide
was not very clear on that point

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-user] Cross-compiling

[Davi]

Em Sex 19 Out 2007, Michael Sullivan escreveu:
 I've read over the guide at
 http://www.gentoo.org/doc/en/cross-compiling-distcc.xml about
 cross-compiling with distcc.  This may be a really stupid question, but
 how do I force my slow box to use cross-compiling via distcc?  Is there
 some special option I have to pass to emerge to invoke it?  The guide
 was not very clear on that point

Have a look at distcc-set-hosts and man distcc.

Good luck. :-)
-- 
Davi Vidal
--
E-mail: [EMAIL PROTECTED]
MSN   : [EMAIL PROTECTED]
GTalk : [EMAIL PROTECTED]
Skype : davi vidal
ICQ   : 138815296


signature.asc
Description: This is a digitally signed message part.