build of dev-libs/boost needs instruction-set=i486 parameter

mwhitehe · n00b Joined: 17 Jul 2017 Posts: 3

I am trying to build dev-libs/boost for i486. I set my CFLAGS="-march=i486 -mtune=i486", but the b2 config is hard-coded to default to i686 (see the later "-march=i686")

Tony0945 · Posted: Mon Jul 17, 2017 3:56 pm Post subject:

The cleanest way I can think of is to create a new ebuild in overlay that is a modified form of the original ebuild.

Why would a build specify "i696"? It needs some instruction missing from earlier chips?

More power to you keeping the i486 alive!

EDIT:

Or a user patch to the portage ebuild.

mwhitehe · n00b Joined: 17 Jul 2017 Posts: 3

Can you post a link on how to create a new ebuild? I am new to Gentoo and am still learning.

Jaglover · Posted: Mon Jul 17, 2017 4:32 pm Post subject:

Here you go.

Tip: you can search the net by yourself, too.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

NeddySeagoon · Posted: Mon Jul 17, 2017 5:17 pm Post subject:

mwhitehe,

If you really mean pass in the environment, portage can do that on a per package basis.

Make a directory /etc/portage/env inside, create a file that does what you want. I have MAKEOPTS-j1, MAKEOPTS-j2 and a few others.
My MAKEOPTS-j1 contains

mwhitehe · n00b Joined: 17 Jul 2017 Posts: 3

This worked for me.

The /usr/portage directory tree is populated when you first install the system, typically with "emerge --sync".

Edit /usr/portage/dev-libs/boost/boost-1.62.0-r1.ebuild. The version will vary over time, so you have to decide which version you want to edit.

I added "instruction-set=i486" to the OPTIONS variable in the src_configure() function. Here is a diff of my change:

NeddySeagoon · Posted: Mon Jul 17, 2017 9:03 pm Post subject:

mwhitehe,

What you have done is fine but you really need to do it in your own overlay as your next --sync will wipe out your change
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

There are three ways to get the result you want:

Modify the ebuild (preferably in an overlay). This is what you did.
Use a Portage environment override to change the options passed to the upstream build. This only works in some cases, but by my reading of the dev-libs/boost ebuild, should work for what you need.
Patch the upstream build to produce an equivalent effect, such as by adding the desired option as a new leftmost "hardcoded" argument.

Personally, I dislike modifying the ebuild (even in an overlay) if I can avoid it, since it means that I become responsible for applying an equivalent modification to every subsequent version bump for as long as I use that package. This constraint only matters for changes I expect no one else will accept. When it applies, I prefer to use one of the other methods, so that new versions automatically pick up my modification (unless the Gentoo ebuild or upstream build system has changed too much, but that is always a peril of maintaining private changes). Due to the way that the current ebuild is implemented, a Portage environment override should (disclaimer: not fully tested) do what you need and should automatically persist across Boost updates (unless the Gentoo ebuild changes in a particular way that I do not expect the maintainer would do).

To do this, create a file /etc/portage/env/dev-libs/boost and give it this content: