Re: [gentoo-user] cross-compiling environment for Rapberry
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
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
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
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
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
Re: [gentoo-user] cross compiling arm with 17 profiles.
Hello, On Sun, Dec 17, 2017 at 8:14 AM, Mart Raudseppwrote: > 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.
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).
Re: [gentoo-user] Cross-compiling for an unstable architecture.
> On 23 Feb 2017, at 22:21, R0b0t1wrote: > > 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.
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
Re: [gentoo-user] cross-compiling mosh
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
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
Re: [gentoo-user] cross-compiling mosh
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
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
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
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
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
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
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
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
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
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
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
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
Re: [gentoo-user] Cross-compiling
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
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
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
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
Re: [gentoo-user] Cross-compiling
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.