View previous topic :: View next topic |
Author |
Message |
sylvain.bonnemaison Apprentice
Joined: 13 Jan 2008 Posts: 152
|
Posted: Thu Mar 08, 2012 10:48 pm Post subject: [gcc] amdfam10 |
|
|
Hi,
I need to build a system for amdfam10 procesor. I have installed gentoo anx86_64 in a vbox system. Then I have create a chroot system inside this vbox. In order to build the system for the target platform, I have updated cflags with "-marh=amdfam10". But now I cannot rebuild gcc with the new cflags.
Is it possible to do such thing? If no, what is the right way to do it?
Thanks |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54097 Location: 56N 3W
|
Posted: Thu Mar 08, 2012 11:27 pm Post subject: |
|
|
sylvain.bonnemaison,
Yes, its possible.
What did you change -march from?
To do this in VBox, your underlying CPU should be an amdfam10 as everthing inside Vbox runs natively on your CPU.
If your real host is and intel system, you must not allow the gcc you build like this to be installed - it won't run.
There is a FEATURES setting you need something like buildpkgonly ... check that.
If your host is a 32 bit system, you can't do this in Vbox. You will need a cross compiler and supporting toolchain. You don't need VBox for that, but it will be harmless.
Tell us about the host hardware and the VBox install. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
sylvain.bonnemaison Apprentice
Joined: 13 Jan 2008 Posts: 152
|
Posted: Tue Mar 13, 2012 7:51 am Post subject: |
|
|
My system is an intel 64 bits processor -Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz .
I'm using virtualbox 4.1.8. The vbox is installed with an hardened-amd64 based system. I have create a chroot for the target system (maybe this step is not necessary). In the chroot, I have setup make.conf like this :
Code: | CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=amdfam10 -O2 -pipe -mno-3dnow -mcx16 -mpopcnt -mssse3 -msse4a -mmmx" |
As I understand, I have to build gcc using "-march=native", and the rest of binaries with the configuration above.
Is there a tutorial about building a full system with prebuild packages ? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54097 Location: 56N 3W
|
Posted: Tue Mar 13, 2012 9:30 pm Post subject: |
|
|
sylvain.bonnemaison,
Provided you use the buildpkgonly FEATURE - check the name, what you propose will work.
You will end up with all of your binary packages saved in /usr/portage/packages but none of them installed in your chroot where they would stop your intel processor dead.
You can then set up your intel system as a BINHOST to serve the binaries to the AMD target or move them over as you like.
Its important that your also move a copy of the portage tree and not do and emerge --sync on your target. You can then run emerg -K <package> on the target and it will install from the binaries.
If you copy over the world file, will do the install for you, from your pre built binaries. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mimosinnet l33t
Joined: 10 Aug 2006 Posts: 713 Location: Barcelona, Spain
|
Posted: Tue Apr 05, 2016 5:28 pm Post subject: |
|
|
Wow!
Does it mean that it is possible to emerge amdfam10 binaries in an intel box with:
Code: | CFLAGS="-march=amdfam10 -O2 -pipe" |
Or Intel binaries in an amd box with:
Code: | CFLAGS="-march=core2 -O2 -pipe" |
Or build binaries for a FX-8350 machine in a AMD Opteron?
I thought that the CPU should have the flags for the binaries that it was building for. I have ended with two binhosts: one for Intel and another for AMD systems. My life would be much more easy if I could build all the binaries for the different cpu-types in the same machine.
Cheers! _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54097 Location: 56N 3W
|
Posted: Tue Apr 05, 2016 7:13 pm Post subject: |
|
|
mimosinnet,
Yes, because the box doing the building never actually runs the code it has just built.
However, its up to you to keep the BINHOSTS separate.
It would be safer to run the not native one in a chroot, something like this. The native ARCH is say Intel.
You do a normal Intel install and set FEATURES=buildpkg and you move /usr/portage/packages to say /var/portage/BINHOST_Intel
Next you create a directory for a chroot. This will be AMD. You can share /usr/portage/, that gets you the tree and distfiles for free.
You install here from your /var/portage/BINHOST_Intel with emerge -K
In the chroot, set FEATURES=buildpkgonly, so noting is ever installed.
Set its packages to /var/portage/BINHOST_AMD
You now have /var/portage/BINHOST_Intel and /path/to/chroot/var/portage/BINHOST_AMD as your two BINHOSTS.
I've skipped a few details ... post back if you need more. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mimosinnet l33t
Joined: 10 Aug 2006 Posts: 713 Location: Barcelona, Spain
|
Posted: Wed Apr 06, 2016 11:51 am Post subject: |
|
|
NeddySeagoon wrote: | You install here from your /var/portage/BINHOST_Intel with emerge -K
In the chroot, set FEATURES=buildpkgonly, so noting is ever installed.
Set its packages to /var/portage/BINHOST_AMD
You now have /var/portage/BINHOST_Intel and /path/to/chroot/var/portage/BINHOST_AMD as your two BINHOSTS. |
This sounds great! I am going to implement it. I assume this can be also be achieved with a hardened host building code for a non-hardened guest
Could this be an alternative to Cross-Compiling? I tried first to cross-complie with distcc, and found much easier to compile in a binhost (and solve all the issues with dependencies in the binhost) and deploy the packages afterwards. This avoids that the working box falls in the middle of an upgrade.
Thanks! _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
Back to top |
|
|
mimosinnet l33t
Joined: 10 Aug 2006 Posts: 713 Location: Barcelona, Spain
|
Posted: Fri May 13, 2016 11:58 pm Post subject: |
|
|
mimosinnet wrote: | This sounds great! I am going to implement it. |
I have not been very successful. I have been trying to build a chroot guest system with:
Code: | CFLAGS="-O2 -march=bdver1 -mprefer-avx128 -mvzeroupper -pipe" |
And a host system with: AMD Opteron(tm) Processor 4180
I have been able to emerge some binaries with the --buildpkgonly option, but I am unable to build other packages. I get messages with "Illegal instruction" in grsec.log, and the emerge fails with, for example,
Code: | dev-lang/orc-0.4.24
make[3]: Entering directory '/var/tmp/portage/dev-lang/orc-0.4.24/work/orc-0.4.24-abi_x86_64.amd64/testsuite/orcc'
../../tools/orcc --include stdint.h --header -o testorc.h /var/tmp/portage/dev-lang/orc-0.4.24/work/orc-0.4.24/testsuite/orcc/../test.orc
Makefile:1053: recipe for target 'testorc.h' failed
make[3]: *** [testorc.h] Illegal instruction
make[3]: Leaving directory '/var/tmp/portage/dev-lang/orc-0.4.24/work/orc-0.4.24-abi_x86_64.amd64/testsuite/orcc'
Makefile:894: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/var/tmp/portage/dev-lang/orc-0.4.24/work/orc-0.4.24-abi_x86_64.amd64/testsuite'
Makefile:503: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/dev-lang/orc-0.4.24/work/orc-0.4.24-abi_x86_64.amd64'
Makefile:388: recipe for target 'all' failed
make: *** [all] Error 2
* ERROR: dev-lang/orc-0.4.24::gentoo failed (compile phase):
* emake failed |
I guess that although the code is compiled correctly, the emerge fails when trying to execute the "test" in the host machine.
This has been a good learning experience! _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54097 Location: 56N 3W
|
Posted: Sat May 14, 2016 9:23 am Post subject: |
|
|
mimosinnet,
Testing a package often means building some code then running it on the build host against the package to be tested.
In a cross compile environment, this always fails, so its normally disabled.
You are trying to use a chroot to provide cross compile isolation. It can't do that. It works most of the time because your target CPU and your build host CPU are similar.
You should never set the FEATURES or USE test options in the chroot.
Cross compiling is still a bit of a black art, you won't find one solution that will build everything. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mimosinnet l33t
Joined: 10 Aug 2006 Posts: 713 Location: Barcelona, Spain
|
Posted: Sun May 15, 2016 11:53 am Post subject: |
|
|
NeddySeagoon wrote: | You are trying to use a chroot to provide cross compile isolation. It can't do that. It works most of the time because your target CPU and your build host CPU are similar.
You should never set the FEATURES or USE test options in the chroot.
Cross compiling is still a bit of a black art, you won't find one solution that will build everything. |
Thanks for the hints! I now have two binhosts that build binary packages for AMD and Intel boxes (I have gentoo in all my laptops!). This is working as the binaries are being build for the minimum requirements of AMD/intel boxes.
In my ideal world I would have a single binhost building for all boxes without having to use distcc. Do you thing this is feasible?
Thanks! _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54097 Location: 56N 3W
|
Posted: Sun May 15, 2016 6:18 pm Post subject: |
|
|
mimosinnet,
The short answer is no. A slightly longer answer is 'maybe, it all depends ...'. The longer still answer is 'yes ... but'.
If you want a single solution and don't care about the speed' there is QEMU chroot.
The chroot runs the native code for the CPU of your choice. It need not be related to the host CPU at all.
QEMU emulates the guest CPU in software, so its slow. One 3.4GHz AMD Phenom II core at 3.4GHz, got me a 200MHz SPARC.
I have a real 400MHz SPARC, so I stopped there but people do build for embedded systems this way.
Pure crossdev uses a cross compiler to build binaries for a random target. Its good when it works ... much faster than a QEMU chroot but there are all sorts of broken cross compile build systems, so things that could work don't work. Then there are things that will never cross compile, so this is less than ideal.
Then there in cross distcc. That doesn't work for everything but its better that a pure cross build.
You can get most things to build with a mix of crossdev and cross distcc. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mimosinnet l33t
Joined: 10 Aug 2006 Posts: 713 Location: Barcelona, Spain
|
Posted: Sun May 15, 2016 6:44 pm Post subject: |
|
|
Wow! That's a great answer and gives me a clear map. Thanks very much! _________________ Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
Back to top |
|
|
|