View previous topic :: View next topic |
Author |
Message |
meow32 n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 08 Aug 2024 Posts: 2
|
Posted: Thu Aug 08, 2024 12:18 pm Post subject: Can't install own binpkg: ISA level is lower than required |
|
|
I have two x86_64 machines with Gentoo, and I'm trying to build a package (net-im/fractal) on one of them and then install it on the other.
The build machine has x86_64_v3, the machine that I want to install the binpkg on has an Intel Core 2 Duo CPU, which obviously supports only x86_64 (no v2 or v3).
On the build machine, I have the following env for the package:
Code: | COMMON_FLAGS="-O2 -pipe -march=core2"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
RUSTFLAGS="-C target-cpu=core2 -C opt-level=3"
FEATURES="buildpkg"
CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
|
On the other machine, "emerge -g net-im/fractal" works fine. But when I try to actually run Fractal, I get the error message:
Code: | fractal: CPU ISA level is lower than required
|
And indeed, Code: | readelf -n `which fractal` | confirms that the binary seems to require x86_64_v3:
Code: | Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.2.0
|
What am I doing wrong? I thought that specifying -march=core2 and (for Rust, since Fractal is a Rust package) -C target-cpu=core2 would have been enough. Do I need to specify some other flags, too? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
logrusx Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
![](images/avatars/176594205966916859b5145.jpg)
Joined: 22 Feb 2018 Posts: 2164
|
Posted: Thu Aug 08, 2024 12:30 pm Post subject: |
|
|
I still keep the config for my olde Core 2 Duo Q6600 in my make.conf which I used for distcc:
Code: |
###################################################
# distcc config for my old desktop PC #
#COMMON_FLAGS="-march=core2 -O2 -pipe" # #
#CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3" #
###################################################
|
I see no difference with yours and it worked for distcc. Do you have other files which resemble the name make.conf somehow?
Best Regards,
Georgi |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
meow32 n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 08 Aug 2024 Posts: 2
|
Posted: Thu Aug 08, 2024 4:02 pm Post subject: |
|
|
logrusx wrote: | Do you have other files which resemble the name make.conf somehow?
Best Regards,
Georgi |
The config I showed was in /etc/portage/env/, not in make.conf. Creating binpkgs is not the primary purpose of the modern machine, so most of the packages are built with "-march=native" in make.conf. Since net-im/fractal requires too much memory during compilation and therefore can't be compiled on the old Core 2 Duo machine, I was hoping I could just override the configuration for this particular package with a file inside /etc/portage/env/ on the x86_64_v3 machine and then install the resulting binpkg on the Core 2.
But when I watch the compilation, I can clearly see that my flags are being applied. So it can't be that it's just not seeing the file.
As a workaround, the program seems to run on the Core 2 if I just strip off the note that claims it requires x86_64_v3: Code: | strip -R .note.gnu.property `which fractal` |
Some further reading tells me that .note.gnu.property gets added by ld. I probably could also get rid of the note by passing "-z x86-64-baseline" to the linker.
But that doesn't address: why does this note get added at all, despite me specifying "-march=core2" (and its Rust equivalent)? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
logrusx Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
![](images/avatars/176594205966916859b5145.jpg)
Joined: 22 Feb 2018 Posts: 2164
|
Posted: Thu Aug 08, 2024 4:38 pm Post subject: |
|
|
meow32 wrote: |
The config I showed was in /etc/portage/env/ |
Those are processed by python, you can't expand variables bash style there. However I think you can in /etc/portage/env/category/package. Try that. It was explained by one of the developers in a bug which unfortunately I lost track of...
Best Regards,
Georgi |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
flexibeast Guru
![Guru Guru](/images/ranks/rank_rect_3.gif)
Joined: 04 Apr 2022 Posts: 376 Location: Naarm/Melbourne, Australia
|
Posted: Thu Aug 08, 2024 11:50 pm Post subject: |
|
|
Quoting the '/etc/portage/package.env' page on the wiki:
Quote: | To have a file called when emerging a specific package, it should be named following the pattern "/etc/portage/env/<category>/<package_name>" (versions can be included, see portage man page), the contents being as in /etc/portage/bashrc; the contents will be parsed as a bash script. These files can hook into specific phases of the emerge process.
If all that is needed is to set environment variables, use a free-form file name directly in /etc/portage/env, then add a line in /etc/portage/package.env with a package atom followed by the chosen file name, like in the following examples. This allows the same environment settings to be used for multiple packages, if needed, or settings to be "mix and matched". Variables can be set in same manner as in make.conf(5):
> It supports simple shell-like expansion of the form var="${var}", the source keyword and variable substitution, but not some of the more advanced BASH features like arrays and special parameter expansions. For more details, see the Simple lexical analysis documentation: https://docs.python.org/3/library/shlex.html. Note that if you source files, they need to be in the same shlex syntax for portage to read them. |
The related '/etc/portage/bashrc' page on the wiki says:
Quote: | The /etc/portage/bashrc file is a global bashrc file referenced by Portage. It is similar to the bashrc files under /etc/portage/env/, except always sourced for every package. It can either be used to setup a global environment common to all ebuilds, or as an alternative to the /etc/portage/env files allowing Portage administrators to handle all the necessary conditional code manually.
bashrc may be used to set up ebuild phase hooks, to perform specific actions at various stages of package installation, updates, or removal. |
|
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
logrusx Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
![](images/avatars/176594205966916859b5145.jpg)
Joined: 22 Feb 2018 Posts: 2164
|
Posted: Fri Aug 09, 2024 4:37 am Post subject: |
|
|
meow32 wrote: |
But when I watch the compilation, I can clearly see that my flags are being applied. So it can't be that it's just not seeing the file.
|
I haven't used /etc/portage/env since long time, maybe things changes or maybe I forgot the details. What I remember is one of the cases I used to use it is to add keepwork to FEATURES and if I remember correctly, it didn't override FEATURES but simply added to the original variable what I had assigned in the config file. Are you sure if it adds only the flags in the config file or it combines them with the ones from make.conf?
Best Regards,
Georgi |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|