Re: [gentoo-user] CFLAGS for both AMD64 and Intel?

[Mike Gilbert]

On Sun, Dec 3, 2017 at 2:23 AM, Manuel McLure  wrote:
> Here's the situation. I have a system that's been running for many years
> with an Athlon 5050e processor. The system is built with
>
> CFLAGS="-march=k8-sse3 -O2 -pipe -msse3"
> CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3"
>
> I have the possibility of upgrading the system to a first-generation Intel
> Core i5 which should give a nice speed boost, but of course the Intel chip
> doesn't understand 3dnow or 3dnowext, so I'll have to do a system rebuild
> before I switch out the motherboard/processor. It seems pretty obvious that
> I have to take "3dnow 3dnowext" out of CPU_FLAGS_X86, but what CFLAGS would
> be recommended for a system that will still run with the AMD processor but
> won't fall over when I switch to the Intel processor? Once I have the Intel
> in place I can rebuild with options more suited for that chip, but I want to
> make sure I don't end up in a catch-22 situation.

I would go with just "-O2 -pipe" for maximum compatibility. Remove the
-march option altogether, and add it back once the system is running
on the Intel chip.

[gentoo-user] CFLAGS for both AMD64 and Intel?

[Manuel McLure]

Here's the situation. I have a system that's been running for many years
with an Athlon 5050e processor. The system is built with

CFLAGS="-march=k8-sse3 -O2 -pipe -msse3"
CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3"

I have the possibility of upgrading the system to a first-generation Intel
Core i5 which should give a nice speed boost, but of course the Intel chip
doesn't understand 3dnow or 3dnowext, so I'll have to do a system rebuild
before I switch out the motherboard/processor. It seems pretty obvious that
I have to take "3dnow 3dnowext" out of CPU_FLAGS_X86, but what CFLAGS would
be recommended for a system that will still run with the AMD processor but
won't fall over when I switch to the Intel processor? Once I have the Intel
in place I can rebuild with options more suited for that chip, but I want
to make sure I don't end up in a catch-22 situation.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft

Re: [gentoo-user] Emerge does want to tell me...what?

[Dale]

Heiko Baums wrote:
> Am Sun, 3 Dec 2017 06:29:29 +0100
> schrieb tu...@posteo.de:
>
>> I already did this...
> There are two things which emerge can tell you with this message.
>
> 1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions.
>
> 2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3
> or sys-devel/gcc-4.9.4.
>
> I already explained what you can do in the first case. In the second
> case I would try to fix (uninstall, rebuild, upgrade or whatever) those
> packages which depend on an outdated gcc. I guess equery is your friend.
>
> Heiko
>
>


One may can add the -t option and see what is pulling it in.  That may,
or may not, lead to a clue. 

Dale

:-)  :-) 

Re: [gentoo-user] Emerge does want to tell me...what?

[Heiko Baums]

Am Sun, 3 Dec 2017 06:29:29 +0100
schrieb tu...@posteo.de:

> I already did this...

There are two things which emerge can tell you with this message.

1. It can't find >=sys-devel/gcc-6.4.0 but only older gcc versions.

2. You have installed a package that depend on sys-devel/gcc-5.4.0-r3
or sys-devel/gcc-4.9.4.

I already explained what you can do in the first case. In the second
case I would try to fix (uninstall, rebuild, upgrade or whatever) those
packages which depend on an outdated gcc. I guess equery is your friend.

Heiko

Re: [gentoo-user] Emerge does want to tell me...what?

[tuxic]

On 12/03 06:16, Heiko Baums wrote:
> Am Sun, 3 Dec 2017 05:43:39 +0100
> schrieb tu...@posteo.de:
> 
> > Hi,
> > 
> > I started emerge -e @world
> > 
> > and it stops with this message:
> > 
> > The following mask changes are necessary to proceed:
> >  (see "package.unmask" in the portage(5) man page for more details)
> > # required by @selected
> > # required by @world (argument)
> > # /usr/portage/profiles/releases/17.0/package.mask:
> > # Andreas K. Huettel  (27 May 2017)
> > # In the 17.0 profiles we assume that our system compiler uses C++14
> > # or later as default language setting. This means it has to be at
> > # least GCC 6. If you need an older compiler for specific purposes,
> > # feel free to unmask it, however, using it for normal emerging of
> > # packages is neither recommended nor supported in any way.
> > =sys-devel/gcc-5.4.0-r3
> > # required by @selected
> > # required by @world (argument)
> > # /usr/portage/profiles/releases/17.0/package.mask:
> > # Andreas K. Huettel  (27 May 2017)
> > # In the 17.0 profiles we assume that our system compiler uses C++14
> > # or later as default language setting. This means it has to be at
> > # least GCC 6. If you need an older compiler for specific purposes,
> > # feel free to unmask it, however, using it for normal emerging of
> > # packages is neither recommended nor supported in any way.
> > =sys-devel/gcc-4.9.4
> 
> I'd suggest you first do a clean gcc upgrade to gcc-6.4.0 or gcc-7.2.0
> depending on whether you run a stable or a testing system.
> 
> https://wiki.gentoo.org/wiki/Upgrading_GCC
> 
> And then follow exactly the steps in the news item after the step of
> rebuilding gcc.
> 
> Or in detail:
> 
> Run these commands:
> # gcc-config -l
> # gcc-config set 
> # emerge -1 sys-devel/gcc
> # gcc-config -l
> # gcc-config set 
> # source /etc/profile
> # emerge -1 sys-devel/libtool
> # gcc --version
> # emerge --depclean =sys-devel/gcc- [for all installed
> gcc versions except for the latest (6.4.0 or 7.2.0)]
> # emerge -1 sys-devel/binutils
> # emerge -1 sys-libs/glibc
> # emerge -e @world
> 
> Heiko
> 

I already did this...

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Adam Carter]

> How can I check, whether a binary is "PIE"-conform ("pie-conform" is
> a freaky funny language hack :) ;) )  ?
>

emerge hardening-check

# hardening-check /usr/bin/cpuid2cpuflags
/usr/bin/cpuid2cpuflags:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes
 Read-only relocations: yes
 Immediate binding: no, not found!

Re: [gentoo-user] Emerge does want to tell me...what?

[Heiko Baums]

Am Sun, 3 Dec 2017 05:43:39 +0100
schrieb tu...@posteo.de:

> Hi,
> 
> I started emerge -e @world
> 
> and it stops with this message:
> 
> The following mask changes are necessary to proceed:
>  (see "package.unmask" in the portage(5) man page for more details)
> # required by @selected
> # required by @world (argument)
> # /usr/portage/profiles/releases/17.0/package.mask:
> # Andreas K. Huettel  (27 May 2017)
> # In the 17.0 profiles we assume that our system compiler uses C++14
> # or later as default language setting. This means it has to be at
> # least GCC 6. If you need an older compiler for specific purposes,
> # feel free to unmask it, however, using it for normal emerging of
> # packages is neither recommended nor supported in any way.
> =sys-devel/gcc-5.4.0-r3
> # required by @selected
> # required by @world (argument)
> # /usr/portage/profiles/releases/17.0/package.mask:
> # Andreas K. Huettel  (27 May 2017)
> # In the 17.0 profiles we assume that our system compiler uses C++14
> # or later as default language setting. This means it has to be at
> # least GCC 6. If you need an older compiler for specific purposes,
> # feel free to unmask it, however, using it for normal emerging of
> # packages is neither recommended nor supported in any way.
> =sys-devel/gcc-4.9.4

I'd suggest you first do a clean gcc upgrade to gcc-6.4.0 or gcc-7.2.0
depending on whether you run a stable or a testing system.

https://wiki.gentoo.org/wiki/Upgrading_GCC

And then follow exactly the steps in the news item after the step of
rebuilding gcc.

Or in detail:

Run these commands:
# gcc-config -l
# gcc-config set 
# emerge -1 sys-devel/gcc
# gcc-config -l
# gcc-config set 
# source /etc/profile
# emerge -1 sys-devel/libtool
# gcc --version
# emerge --depclean =sys-devel/gcc- [for all installed
gcc versions except for the latest (6.4.0 or 7.2.0)]
# emerge -1 sys-devel/binutils
# emerge -1 sys-libs/glibc
# emerge -e @world

Heiko

[gentoo-user] Emerge does want to tell me...what?

[tuxic]

Hi,

I started emerge -e @world

and it stops with this message:

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by @selected
# required by @world (argument)
# /usr/portage/profiles/releases/17.0/package.mask:
# Andreas K. Huettel  (27 May 2017)
# In the 17.0 profiles we assume that our system compiler uses C++14
# or later as default language setting. This means it has to be at
# least GCC 6. If you need an older compiler for specific purposes,
# feel free to unmask it, however, using it for normal emerging of
# packages is neither recommended nor supported in any way.
=sys-devel/gcc-5.4.0-r3
# required by @selected
# required by @world (argument)
# /usr/portage/profiles/releases/17.0/package.mask:
# Andreas K. Huettel  (27 May 2017)
# In the 17.0 profiles we assume that our system compiler uses C++14
# or later as default language setting. This means it has to be at
# least GCC 6. If you need an older compiler for specific purposes,
# feel free to unmask it, however, using it for normal emerging of
# packages is neither recommended nor supported in any way.
=sys-devel/gcc-4.9.4


For me it is unclear, whether I should unmask or mask these compilers.
So I added them to /etc/portage/package.mask/.  ,restarted the whole
thing only to get the same message.

So...from the logical point of view unmasking would be the correct
waybut we are all urged to >gcc-6.4.0 ... so unmasking would be
wrong...also from a logical point of view.

Cheers
Meino

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Heiko Baums]

Am Sun, 3 Dec 2017 04:45:59 +0100
schrieb tu...@posteo.de:

> Suppose one would do an emerge @world...and then BOOOM! a powerfailyre
> would stop the whole thing.

In such a case you should consider buying a UPS.

Can't you do this over night or a weekend? And how often do you have a
power failure?

> Further suppose the filesystem, the
> hardware and anything has survived luckily -- only emerge @world needs
> to be restarted.
> And one does NOT an emerge --resume but an emerge @world.

If I'm not mistaken in this case an `emerge --resume` should be
the right thing. It usually resumes the last interrupted emerge command.

That is if you run `emerge -e @world` press Ctrl-C `emerge --resume`
should resume this previous started `emerge -e @world` including the
package which was built when it was interrupted. Ctrl-C is principally
the same as a power failure.

If this fails for some reason then you'd have to rerun the whole
`emerge -e @world` I guess.

> In this particular case...how does emerge knows from the previous
> emerge @world what packages has been recompiled already and are "PIE"?

Like I said before. emerge always calculates the dependency tree, which
is a lot faster in case of `emerge -e @world` than in case of `emerge
-uDN @world`. And then it knows which packages have already been
installed and which are not.

That said I haven't run an `emerge -e @world` before. So I'm actually
not sure if this works the same way as with an `emerge -uDN @world`.

Heiko

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Heiko Baums]

Am Sun, 3 Dec 2017 04:26:55 +0100
schrieb tu...@posteo.de:

> Delaying would not solve the problem as it is...

Btw., if you're using the testing tree (e.g. ~amd64) you should do a gcc
upgrade instead of rebuilding gcc as the news item says.

Unfortunately the news item explicitly mentions gcc-6.4.0. After
rebuilding it as the news item says I found out that gcc-7.2.0 is
already in the portage tree.

So more than an hour wasted.

Heiko

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[tuxic]

On 12/03 04:35, Heiko Baums wrote:
> Am Sun, 3 Dec 2017 04:26:55 +0100
> schrieb tu...@posteo.de:
> 
> > If the compilation will fail at a certain point (and it will fail,
> > since this is a complete new thing) -- would it be possible to resume
> > even some tweaks, hacks and patches (even certain recompilations)
> > would be needed in between?
> 
> Just run `emerge -e --keep-going y @world`.
> 
> > Can I stop a running emerge @world and resume later?
> 
> Maybe with `emerge --resume`. But I don't know if interrupting this
> would cause some problems in this particular case.
> 
> > How does a restarted emerge @world recognizes packages, which are
> > already compiled according to the new standard?
> 
> It simply creates a list of the packages to be installed as usual and
> knows which of them are already installed and which are not. Then it
> recalculates the dependency tree as usual.
> 
> Heiko
> 

Hi Heiko,

...sorry my question was unclear.

Suppose one would do an emerge @world...and then BOOOM! a powerfailyre
would stop the whole thing. Further suppose the filesystem, the
hardware and anything has survived luckily -- only emerge @world needs
to be restarted.
And one does NOT an emerge --resume but an emerge @world.
In this particular case...how does emerge knows from the previous
emerge @world what packages has been recompiled already and are "PIE"?

How can I check, whether a binary is "PIE"-conform ("pie-conform" is
a freaky funny language hack :) ;) )  ?

Cheers
Meino

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Heiko Baums]

Am Sun, 3 Dec 2017 04:26:55 +0100
schrieb tu...@posteo.de:

> If the compilation will fail at a certain point (and it will fail,
> since this is a complete new thing) -- would it be possible to resume
> even some tweaks, hacks and patches (even certain recompilations)
> would be needed in between?

Just run `emerge -e --keep-going y @world`.

> Can I stop a running emerge @world and resume later?

Maybe with `emerge --resume`. But I don't know if interrupting this
would cause some problems in this particular case.

> How does a restarted emerge @world recognizes packages, which are
> already compiled according to the new standard?

It simply creates a list of the packages to be installed as usual and
knows which of them are already installed and which are not. Then it
recalculates the dependency tree as usual.

Heiko

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[tuxic]

On 12/02 09:30, Michael Orlitzky wrote:
> On 12/02/2017 09:15 PM, tu...@posteo.de wrote:
> > Hi,
> > 
> > the instruction of the news item about the swicth to profile 17 says
> > that one needs to rebuild @world.
> > 
> > Is this technically needed?
> 
> Yes, unless you were already using a hardened toolchain.
> 
> 
> > Would it be possible to do this on base of the daily updates intead
> > all in one go?
> 
> No, you'll get build failures trying to link new packages against old
> libraries.
> 
> However, you can delay switching to the new profile for a while.
> 

Delaying would not solve the problem as it is...

If the compilation will fail at a certain point (and it will fail,
since this is a complete new thing) -- would it be possible to resume
even some tweaks, hacks and patches (even certain recompilations)
would be needed in between?

Can I stop a running emerge @world and resume later?

How does a restarted emerge @world recognizes packages, which are
already compiled according to the new standard?

Cheers
Meino

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Michael Orlitzky]

On 12/02/2017 09:32 PM, Adam Carter wrote:
> 
> Does having the hardened USE flag enabled = having a hardened toolchain?

If only it were that simple... what you really need to know is, did you
build everything on your system with PIE enabled?

  * Some packages have "pie" USE flags, and it's only forced-on in the
hardened profiles. I think that flag may actually have been masked
in the default profiles?

  * Even if you /built/ a hardened compiler, you can switch it off
with gcc-config.

  * Your local flags in make.conf can disable some of that stuff, too.

If you were using a hardened *profile*, then chances are that you won't
need to rebuild (unless you switched to a non-hardened compiler on
purpose). Otherwise, I would play it safe and rebuild everything. The
newer GCC probably produces more efficient code anyway, and you will
preempt all of the inevitable problems that no one thought of and that
weren't mentioned in the news item.

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Adam Carter]

On Sun, Dec 3, 2017 at 1:30 PM, Michael Orlitzky  wrote:

> On 12/02/2017 09:15 PM, tu...@posteo.de wrote:
> > Hi,
> >
> > the instruction of the news item about the swicth to profile 17 says
> > that one needs to rebuild @world.
> >
> > Is this technically needed?
>
> Yes, unless you were already using a hardened toolchain.
>

Does having the hardened USE flag enabled = having a hardened toolchain?

Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[Michael Orlitzky]

On 12/02/2017 09:15 PM, tu...@posteo.de wrote:
> Hi,
> 
> the instruction of the news item about the swicth to profile 17 says
> that one needs to rebuild @world.
> 
> Is this technically needed?

Yes, unless you were already using a hardened toolchain.


> Would it be possible to do this on base of the daily updates intead
> all in one go?

No, you'll get build failures trying to link new packages against old
libraries.

However, you can delay switching to the new profile for a while.

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Michael Orlitzky]

On 12/02/2017 09:18 PM, Ian Zimmerman wrote:
>>
>> You do need to run "emerge -e @world", unless you happened to be using
>> a hardened toolchain already.
> 
> But only if you in fact switch the new profile on, right?

Right.


> There seems to be another thing afoot, though.  All (or nearly so)
> python libraries are due for rebuild because of
> 
> PYTHON_TARGETS="python3_5 -python3_4"
> 
> Where does that come from?  I have never fully understood this and
> similar variables.  It seems to be kind of like USE but also separate
> from USE.  Is it something I can control, as a user?  Where is it
> configured?  Is this change tied to the above profile transition?

Totally unrelated. PYTHON_TARGETS is a so-called USE_EXPAND variable:

  https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS

It is precisely a bunch of plain-old USE flags under the hood, with a
little bit of syntactic sugar on top so that you can set e.g.

  PYTHON_TARGETS=python3_5

instead of

  USE=python_targets_python3_5

In other words, it automatically namespaces a set of related USE flags.

All of the python stuff is rebuilding because (I guess) the python team
stabilized python-3.5. As a result, you're going to install python-3.5,
and therefore need to rebuild all of your python packages with support
for python-3.5.

[gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Ian Zimmerman]

On 2017-12-02 20:14, Michael Orlitzky wrote:

> >> You're seeing a lot of reports because there is a news item telling
> >> people to switch to the new profile and run "emerge -e @world".
> > 
> > Does this mean that "emerge -e @world" should be run or that the
> > news item is wrong in this point?
> 
> You do need to run "emerge -e @world", unless you happened to be using
> a hardened toolchain already.

But only if you in fact switch the new profile on, right?

There seems to be another thing afoot, though.  All (or nearly so)
python libraries are due for rebuild because of

PYTHON_TARGETS="python3_5 -python3_4"

Where does that come from?  I have never fully understood this and
similar variables.  It seems to be kind of like USE but also separate
from USE.  Is it something I can control, as a user?  Where is it
configured?  Is this change tied to the above profile transition?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[gentoo-user] New profile 17: How urgent is the rebuild of world technically?

[tuxic]

Hi,

the instruction of the news item about the swicth to profile 17 says
that one needs to rebuild @world.

Is this technically needed?
Would it be possible to do this on base of the daily updates intead
all in one go?

Background: I simply need my PC more often as it would allow me
to wait (and fix...see previous mails in this mailing list) a
rebuild of world in one go.

Thanks a lot for any help in advance!

Cheers
Meino

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Adam Carter]

> * Select the new profile with eselect
> * Re-emerge, in this sequence, gcc, binutils, and glibc
> emerge -1 sys-devel/gcc:6.4.0
> emerge -1 sys-devel/binutils
> emerge -1 sys-libs/glibc
> * Rebuild your entire system
> emerge -e @world
>

Would emerge -e --exclude gcc --exclude bintuils --exclude glibc @world be
a little more sensible?

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Michael Orlitzky]

On 12/02/2017 08:07 PM, Heiko Baums wrote:
> Am Sat, 2 Dec 2017 18:33:09 -0500
> schrieb Michael Orlitzky :
> 
>> You're seeing a lot of reports because there is a news item telling
>> people to switch to the new profile and run "emerge -e @world".
> 
> Does this mean that "emerge -e @world" should be run or that the news
> item is wrong in this point?

You do need to run "emerge -e @world", unless you happened to be using a
hardened toolchain already.

So the news item is correct, but having everyone build test the whole
tree at once is unearthing some latent build system bugs.

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Heiko Baums]

Am Sat, 2 Dec 2017 18:33:09 -0500
schrieb Michael Orlitzky :

> You're seeing a lot of reports because there is a news item telling
> people to switch to the new profile and run "emerge -e @world".

Does this mean that "emerge -e @world" should be run or that the news
item is wrong in this point?

Heiko

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Michael Orlitzky]

On 12/02/2017 04:28 PM, Ian Zimmerman wrote:
> This profile change seems to have hit a few people in sensitive
> locations.
> 
> What is the upshot of this change?  Can I eyeball the diff _before_ I
> sync ?
> 

The new 17.0 profile switches the default C++ version to C++14, and
enables PIE/SSP by default with real upstream support for those
features. As a result, it requires gcc-6.x. Most build failures are due
to that -- basically ancient stable versions that never got tested with
a modern compiler/features until now.

Syncing is safe, nothing bad will happen unless you `eselect profile`
one of the new 17.0 profiles.

You're seeing a lot of reports because there is a news item telling
people to switch to the new profile and run "emerge -e @world".

Re: [gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Mick]

On 02-12-2017 ,13:28:37, Ian Zimmerman wrote:
> This profile change seems to have hit a few people in sensitive
> locations.
> 
> What is the upshot of this change?  Can I eyeball the diff _before_ I
> sync ?

This is what the news item states:
=
~ $ eselect news read new
2017-11-30-new-17-profiles
  Title New 17.0 profiles in the Gentoo repository
  AuthorAndreas K. Hüttel 
  Posted2017-11-30
  Revision  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked
   and not supported for use as a system compiler anymore. Feel
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
   profile tree. Now they are moving into the 17.0 profile
   as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
. /etc/profile
* Re-emerge libtool
emerge -1 sys-devel/libtool
Then,
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
emerge -1 sys-devel/gcc:6.4.0
emerge -1 sys-devel/binutils
emerge -1 sys-libs/glibc
* Rebuild your entire system
emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of
GCC 6 to generate PIE executables by default; thus, you need to do
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.

[gentoo-user] Re: grub-0.97-r16 and profile 17.0 change

[Ian Zimmerman]

This profile change seems to have hit a few people in sensitive
locations.

What is the upshot of this change?  Can I eyeball the diff _before_ I
sync ?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] Profile 17.0 change and app-cdr/cdrdao-1.2.3-r4

[Mike Gilbert]

On Sat, Dec 2, 2017 at 8:15 AM, Mick  wrote:
> app-cdr/cdrdao-1.2.3-r4 also fails to install:
>
> [snip ...]
> Making all in utils
> make[2]: Entering directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3/utils'
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -std=c++11 -pthread -c -o toc2cue.o toc2cue.cc
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -pthread -c -o main.o main.c
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -pthread -c -o cue2toc.o cue2toc.c
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -pthread -c -o timecode.o timecode.c
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -std=c++11 -pthread -c -o toc2cddb.o toc2cddb.cc
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native
> -O2 -pipe -std=c++11 -pthread -c -o toc2mp3-toc2mp3.o `test -f 'toc2mp3.cc' ||
> echo './'`toc2mp3.cc
> x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -pthread  -Wl,-O1 -Wl,--as-
> needed -o cue2toc main.o cue2toc.o timecode.o  -pthread
> x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1
> -Wl,--as-needed -o toc2cddb toc2cddb.o ../trackdb/libtrackdb.a -lmad -lm -
> lvorbisfile -lao -pthread
> x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1
> -Wl,--as-needed -o toc2mp3 toc2mp3-toc2mp3.o ../trackdb/libtrackdb.a  -
> lmp3lame -lmad -lm -lvorbisfile -lao -pthread
> [19/1535]
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> toc2mp3-toc2mp3.o: warning: relocation against `bitrate_table' in readonly
> section `.text.startup'
> toc2mp3-toc2mp3.o: In function `init_encoder(int)':
> toc2mp3.cc:(.text+0x2c2): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2d0): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2db): undefined reference to `bitrate_table'
> toc2mp3-toc2mp3.o: In function `main':
> toc2mp3.cc:(.text.startup+0x29a): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text.startup+0x2a1): undefined reference to `bitrate_table'
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> warning: creating a DT_TEXTREL in a shared object.
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:487: toc2mp3] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3/utils'
> make[1]: *** [Makefile:436: all-recursive] Error 1
> make[1]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3'
> make: *** [Makefile:375: all] Error 2
>  * ERROR: app-cdr/cdrdao-1.2.3-r4::gentoo failed (compile phase):
>  *   emake failed
>
> Is there a solution for this?

There is a patch attached to this bug report.

https://bugs.gentoo.org/635014

Re: [gentoo-user] Profile 17.0 change and app-cdr/cdrdao-1.2.3-r4

[Peter Humphrey]

On Saturday, 2 December 2017 13:15:58 GMT Mick wrote:

> app-cdr/cdrdao-1.2.3-r4 also fails to install:

[snip ...]

> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin
> /ld: toc2mp3-toc2mp3.o: warning: relocation against `bitrate_table' in
> readonly section `.text.startup'
> toc2mp3-toc2mp3.o: In function `init_encoder(int)':
> toc2mp3.cc:(.text+0x2c2): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2d0): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2db): undefined reference to `bitrate_table'

[snip ...]

[aol]
Me too.
[/aol]

-- 
Regards,
Peter.

Re: [gentoo-user] Profile 17.0 change and app-cdr/cdrdao-1.2.3-r4

[Mick]

On Saturday, 2 December 2017 15:12:51 GMT Corbin wrote:

> Just for the sake of curiosity ...
> 
> Have you tried to compile with this
> 
> CPPFLAGS="-D_GLIBCXX_USE_CXX11_ABI=1"
> 
> added to make.conf ?

I've added this to the command line and it failed at the same point - see 
below.

> The reason for this question ... I have noticed that some"packages" try
> to either use or be compatible with both c++11 specs ( old way / new way ).
> 
> 
> Corbin

This is the output:

~ # CPPFLAGS="-D_GLIBCXX_USE_CXX11_ABI=1" emerge -1av cdrdao

 


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

  


  
Calculating dependencies... done!   

  
[ebuild   R] app-cdr/cdrdao-1.2.3-r4::gentoo  USE="encode mad vorbis" 0 
KiB
[snip ...]

Making all in utils 

  
make[2]: Entering directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
cdrdao-1.2.3/utils' 
   
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb  -
D_GLIBCXX_USE_CXX11_ABI=1  -march=native -O2 -pipe -std=c++11 -pthread -c -o 
toc2cue.o toc2cue.cc 
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb  -
D_GLIBCXX_USE_CXX11_ABI=1  -march=native -O2 -pipe -pthread -c -o main.o 
main.c   
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb  -
D_GLIBCXX_USE_CXX11_ABI=1  -march=native -O2 -pipe -pthread -c -o cue2toc.o 
cue2toc.c 
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb  -
D_GLIBCXX_USE_CXX11_ABI=1  -march=native -O2 -pipe -pthread -c -o timecode.o 
timecode.c   
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb  -
D_GLIBCXX_USE_CXX11_ABI=1  -march=native -O2 -pipe -std=c++11 -pthread -c -o 
toc2cddb.o toc2cddb.cc   
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb  -
D_GLIBCXX_USE_CXX11_ABI=1  -march=native -O2 -pipe -std=c++11 -pthread -c -o 
toc2mp3-toc2mp3.o `test -f 'toc2mp3.cc' || echo '
./'`toc2mp3.cc  

  
x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -pthread  -Wl,-O1 -Wl,--as-
needed -o cue2toc main.o cue2toc.o timecode.o  -pthread 
  
x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
-Wl,--as-needed -o toc2cue toc2cue.o ../trackdb/libtrackdb.a -lmad -lm -
lvorbisfile -lao -pthread   
x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
-Wl,--as-needed -o toc2cddb toc2cddb.o ../trackdb/libtrackdb.a -lmad -lm -
lvorbisfile-lao -pthread  
x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
-Wl,--as-needed -o toc2mp3 toc2mp3-toc2mp3.o ../trackdb/libtrackdb.a  -
lmp3lame -lmad-lm -lvorbisfile -lao -pthr
ead 

  
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
toc2mp3-toc2mp3.o: warning: relocation against `bitrate_table' in readonly 
section `.text.startup' 
toc2mp3-toc2mp3.o: In function `init_encoder(int)': 

  
toc2mp3.cc:(.text+0x2c2): undefined reference to `bitrate_table'

  
toc2mp3.cc:(.text+0x2d0): undefined reference to `bitrate_table'

  

Re: [gentoo-user] Profile 17.0 change and app-cdr/cdrdao-1.2.3-r4

[Corbin]

On 12/02/2017 07:15 AM, Mick wrote:
> app-cdr/cdrdao-1.2.3-r4 also fails to install:
>
> [snip ...]
> Making all in utils   
>
> make[2]: Entering directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3/utils'
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb
> -march=native 
> -O2 -pipe -std=c++11 -pthread -c -o toc2cue.o toc2cue.cc
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb
> -march=native 
> -O2 -pipe -pthread -c -o main.o main.c
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb
> -march=native 
> -O2 -pipe -pthread -c -o cue2toc.o cue2toc.c
> x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb
> -march=native 
> -O2 -pipe -pthread -c -o timecode.o timecode.c
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb
> -march=native 
> -O2 -pipe -std=c++11 -pthread -c -o toc2cddb.o toc2cddb.cc
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb
> -march=native 
> -O2 -pipe -std=c++11 -pthread -c -o toc2mp3-toc2mp3.o `test -f 'toc2mp3.cc' 
> || 
> echo './'`toc2mp3.cc
> x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -pthread  -Wl,-O1 -Wl,--as-
> needed -o cue2toc main.o cue2toc.o timecode.o  -pthread
> x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
> -Wl,--as-needed -o toc2cddb toc2cddb.o ../trackdb/libtrackdb.a -lmad -lm -
> lvorbisfile -lao -pthread
> x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
> -Wl,--as-needed -o toc2mp3 toc2mp3-toc2mp3.o ../trackdb/libtrackdb.a  -
> lmp3lame -lmad -lm -lvorbisfile -lao -pthread 
>   
>   
> [19/1535]
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>  
> toc2mp3-toc2mp3.o: warning: relocation against `bitrate_table' in readonly 
> section `.text.startup'
> toc2mp3-toc2mp3.o: In function `init_encoder(int)':
> toc2mp3.cc:(.text+0x2c2): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2d0): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text+0x2db): undefined reference to `bitrate_table'
> toc2mp3-toc2mp3.o: In function `main':
> toc2mp3.cc:(.text.startup+0x29a): undefined reference to `bitrate_table'
> toc2mp3.cc:(.text.startup+0x2a1): undefined reference to `bitrate_table'
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
>  
> warning: creating a DT_TEXTREL in a shared object.
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:487: toc2mp3] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3/utils'
> make[1]: *** [Makefile:436: all-recursive] Error 1
> make[1]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
> cdrdao-1.2.3'
> make: *** [Makefile:375: all] Error 2
>  * ERROR: app-cdr/cdrdao-1.2.3-r4::gentoo failed (compile phase):
>  *   emake failed
>
> Is there a solution for this?

Just for the sake of curiosity ...

Have you tried to compile with this

CPPFLAGS="-D_GLIBCXX_USE_CXX11_ABI=1"

added to make.conf ?

The reason for this question ... I have noticed that some"packages" try
to either use or be compatible with both c++11 specs ( old way / new way ).


Corbin

[gentoo-user] Profile 17.0 change and app-cdr/cdrdao-1.2.3-r4

[Mick]

app-cdr/cdrdao-1.2.3-r4 also fails to install:

[snip ...]
Making all in utils 
 
make[2]: Entering directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
cdrdao-1.2.3/utils'
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native 
-O2 -pipe -std=c++11 -pthread -c -o toc2cue.o toc2cue.cc
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native 
-O2 -pipe -pthread -c -o main.o main.c
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native 
-O2 -pipe -pthread -c -o cue2toc.o cue2toc.c
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native 
-O2 -pipe -pthread -c -o timecode.o timecode.c
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native 
-O2 -pipe -std=c++11 -pthread -c -o toc2cddb.o toc2cddb.cc
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../trackdb-march=native 
-O2 -pipe -std=c++11 -pthread -c -o toc2mp3-toc2mp3.o `test -f 'toc2mp3.cc' || 
echo './'`toc2mp3.cc
x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -pthread  -Wl,-O1 -Wl,--as-
needed -o cue2toc main.o cue2toc.o timecode.o  -pthread
x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
-Wl,--as-needed -o toc2cddb toc2cddb.o ../trackdb/libtrackdb.a -lmad -lm -
lvorbisfile -lao -pthread
x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++11 -pthread  -Wl,-O1 
-Wl,--as-needed -o toc2mp3 toc2mp3-toc2mp3.o ../trackdb/libtrackdb.a  -
lmp3lame -lmad -lm -lvorbisfile -lao -pthread   

  
[19/1535]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
toc2mp3-toc2mp3.o: warning: relocation against `bitrate_table' in readonly 
section `.text.startup'
toc2mp3-toc2mp3.o: In function `init_encoder(int)':
toc2mp3.cc:(.text+0x2c2): undefined reference to `bitrate_table'
toc2mp3.cc:(.text+0x2d0): undefined reference to `bitrate_table'
toc2mp3.cc:(.text+0x2db): undefined reference to `bitrate_table'
toc2mp3-toc2mp3.o: In function `main':
toc2mp3.cc:(.text.startup+0x29a): undefined reference to `bitrate_table'
toc2mp3.cc:(.text.startup+0x2a1): undefined reference to `bitrate_table'
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: 
warning: creating a DT_TEXTREL in a shared object.
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:487: toc2mp3] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
cdrdao-1.2.3/utils'
make[1]: *** [Makefile:436: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/app-cdr/cdrdao-1.2.3-r4/work/
cdrdao-1.2.3'
make: *** [Makefile:375: all] Error 2
 * ERROR: app-cdr/cdrdao-1.2.3-r4::gentoo failed (compile phase):
 *   emake failed

Is there a solution for this?
-- 
Regards,
Mick

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

[gentoo-user] profile 17.0 change and net-libs/webkit-gtk

[Corbin]

FYI :

Since the profile change, 2 versions of net-libs/webkit-gtk began
failing to compile.

net-libs/webkit-gtk-2.18.3:4

net-libs/webkit-gtk-2.4.11-r200:2

Both had the same failures. JavaScript support related.

-

net-libs/webkit-gtk-2.4.11-r1:3 did compile.


Corbin

[gentoo-user] grub-0.97-r16 and profile 17.0 change

[Mick]

I'm getting this error after I changed my profile as per '2017-11-30-new-17-
profiles' news item:

>>> Compiling source in /data/tmp_var/portage/sys-boot/grub-0.97-r16/work/
grub-0.97 ...
make -j5 -l12.8
make  all-recursive
make[1]: Entering directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/
work/grub-0.97'
Making all in netboot
make[2]: Entering directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/
work/grub-0.97/netboot'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/work/
grub-0.97/netboot'
Making all in stage2
make[2]: Entering directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/
work/grub-0.97/stage2'
x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1  -Wall -
Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-
loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-
strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc  -
DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -
DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -
DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -
DUSE_MD5_PASSWORDS=1 -DHAVE_CONFIG_H -I. -I.. -I../stage1 -Wall -Wmissing-
prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-loops=1 -
falign-functions=1 -Wundef -g -c -o pre_stage2_exec-asm.o `test -f 'asm.S' || 
echo './'`asm.S
x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1  -Wall -
Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-
loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-
strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc  -
DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -
DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -
DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -
DUSE_MD5_PASSWORDS=1 -g -c -o pre_stage2_exec-bios.o `test -f 'bios.c' || echo 
'./'`bios.c
x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1  -Wall -
Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-
loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-
strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc  -
DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -
DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -
DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -
DUSE_MD5_PASSWORDS=1 -g -c -o pre_stage2_exec-boot.o `test -f 'boot.c' || echo 
'./'`boot.c
x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1  -Wall -
Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-
loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-
strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc  -
DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -
DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -
DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -
DUSE_MD5_PASSWORDS=1 -g -c -o pre_stage2_exec-builtins.o `test -f 'builtins.c' 
|| echo './'`builtins.c
x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../stage1  -Wall -
Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -falign-jumps=1 -falign-
loops=1 -falign-functions=1 -Wundef -Os -fno-stack-protector -nopie -fno-
strict-aliasing -march=i686 -fno-reorder-functions -fno-builtin -nostdinc  -
DSUPPORT_SERIAL=1 -DSUPPORT_HERCULES=1 -DSUPPORT_GRAPHICS=1 -DFSYS_EXT2FS=1 -
DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_UFS2=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -
DFSYS_VSTAFS=1 -DFSYS_JFS=1 -DFSYS_XFS=1 -DFSYS_ISO9660=1 -
DUSE_MD5_PASSWORDS=1 -g -c -o pre_stage2_exec-char_io.o `test -f 'char_io.c' 
|| echo './'`char_io.c
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did 
you mean ‘-no-pie’?
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did 
you mean ‘-no-pie’?
make[2]: *** [Makefile:2878: pre_stage2_exec-bios.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [Makefile:2892: pre_stage2_exec-boot.o] Error 1
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did 
you mean ‘-no-pie’?
make[2]: *** [Makefile:2920: pre_stage2_exec-char_io.o] Error 1
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did 
you mean ‘-no-pie’?
make[2]: *** [Makefile:1492: pre_stage2_exec-asm.o] Error 1
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-nopie’; did 
you mean ‘-no-pie’?
make[2]: *** [Makefile:2906: pre_stage2_exec-builtins.o] Error 1
make[2]: Leaving directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/work/
grub-0.97/stage2'
make[1]: *** [Makefile:382: all-recursive] Error 1
make[1]: Leaving directory '/data/tmp_var/portage/sys-boot/grub-0.97-r16/work/