Profile 17.0

Message

Spargeltarzan · Post by **Spargeltarzan** » Sat Dec 02, 2017 9:27 am

I also successfully recompiled 1143 packages

Post by **fedeliallalinea** » Sat Dec 02, 2017 9:37 am

teefax wrote:Yes, I've read that. I meant, is it possible to disable PIE?

Ok sorry I don't undestand.

teefax wrote:It seems the PIE use flag is forced for the 17.0 profile. Is it sufficient to add -fno-pie to my CFLAGS in make.conf ?

I'm not sure, then wait another answer, but I think that correct way is to mask use flag pie

Post by **asturm** » Sat Dec 02, 2017 9:42 am

If you don't want to rebuild, then just don't. You can always do it later if you encounter strange build issues...

slackline · Post by **slackline** » Sat Dec 02, 2017 10:20 am

Quick question, I've only got gcc-7.2.0 installed and wanted to check that I don't need to know install a slotted gcc-6.4.0 as the instructions explicitly state emerging it...

Code: Select all

* 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

Am I safe to use

Code: Select all

    emerge -1 sys-devel/gcc-7.2.0

when re-emerging gcc?

Post by **asturm** » Sat Dec 02, 2017 10:22 am

No need to if you're already on 7.2.

mv · Post by mv » Sat Dec 02, 2017 10:34 am

For the change no-pie-> pie (or vice versa), it is usually not necessary to rebuild all of @world:

The only thing which needs to be rebuilt (after you rebuilt gcc) are the static libraries. The following command should be sufficient for that:

Code: Select all

emerge -1 /lib*/*.a /usr/lib*/*.a

Non-static libraries should have been built with PIC, anyway (which is the PIE replacement for libraries).

For all other packages (which compile some non-library code) the effect of changing no-pie->pie (or vice versa) will of course only be active for that package when the package is recompiled, but there should not be any functional problems if you do not recompile.

yzg · Post by **yzg** » Sat Dec 02, 2017 10:41 am

The packages failed by the emerge world update 7 days ago are still not fixed. There are bug reports for the 4 packages. The last thing I want now is emerge -e.

Code: Select all

# emerge @preserved-rebuild -av 

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

Calculating dependencies... done!
[ebuild   R    ] dev-db/sqlitebrowser-3.9.1-r1::gentoo  USE="{-test}" 0 KiB
[ebuild   R    ] media-video/vcdimager-0.7.24::gentoo  USE="xml -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] gnome-base/gvfs-1.32.1::gentoo  USE="bluray cdda gtk http (policykit) samba udev udisks -afp -archive -fuse -gnome-keyring -gnome-online-accounts -google -gphoto2 -ios -mtp -nfs -systemd {-test} -zeroconf" 0 KiB
[ebuild   R    ] media-libs/xine-lib-1.2.8:1::gentoo  USE="X a52 aac aalib alsa bluray css directfb dts dvb fbcon flac gtk imagemagick jpeg libcaca mad mmap mng modplug nls opengl samba sdl speex theora truetype v4l vcd vorbis xinerama xv xvmc (-altivec) -dxr3 -fusionsound -ipv6 -jack -libav -musepack -oss -pulseaudio -vaapi -vdpau -vdr (-vidix) (-vis) -vpx -wavpack -xcb" 0 KiB

Total: 4 packages (4 reinstalls), Size of downloads: 0 KiB

Post by **NeddySeagoon** » Sat Dec 02, 2017 10:44 am

mv,

What about /usr/local/lib*?
Portage can't help with that though.

I suppose if you have /usr/local/lib*/*.a, you also have responsibility for it too.

slackline · Post by **slackline** » Sat Dec 02, 2017 10:48 am

asturm wrote:No need to if you're already on 7.2.

Thanks for the reply, do you mean I can just select the new profile and then emerge -e @world or do I still need to compile sys-devel/binutils and sys-libs/glibc (already done up to emergeing sys-devel/libtool).

Sorry for the dumb quesiton, just not clear to me what it is I've no need to do.

mv · Post by mv » Sat Dec 02, 2017 11:36 am

NeddySeagoon wrote:I suppose if you have /usr/local/lib*/*.a, you also have responsibility for it too.

If you installed something outside of portage, you are always on your own with that

Post by **dilfridge** » Sat Dec 02, 2017 11:40 am

slackline wrote:
asturm wrote:No need to if you're already on 7.2.
Thanks for the reply, do you mean I can just select the new profile and then emerge -e @world or do I still need to compile sys-devel/binutils and sys-libs/glibc (already done up to emergeing sys-devel/libtool).

Sorry for the dumb quesiton, just not clear to me what it is I've no need to do.

Sorry, the news item was originally written when gcc-7.2 was still without keywords.

If you're already on 7.2, just replace 6.4.0 with 7.2.0 everywhere in the instructions. You still need to follow the whole procedure though to be 100% sure that everything works.

That said... On a typical system, the fallout from not rebuilding world may be rather small. Many of the developers who tested the 17.0 profiles did no rebuilds at all, and ended up only with a few random build failures at some point later. Then again, the devs recognize the errors that result (I hope), can fix them (I hope) and do not file invalid bugs about it (I hope)...

slackline · Post by **slackline** » Sat Dec 02, 2017 2:02 pm

dilfridge wrote:
If you're already on 7.2, just replace 6.4.0 with 7.2.0 everywhere in the instructions. You still need to follow the whole procedure though to be 100% sure that everything works.

Thats great, thanks for the clarification dilfridge, not adverse to rebuilding world so will forge ahead.

manugutito · Post by **manugutito** » Sat Dec 02, 2017 4:23 pm

In my case the building of Firefox failed after switching to the profile default/linux/amd64/17.0/desktop/plasma, with the following message:

Code: Select all

ERROR: compile
ERROR: www-client/firefox-52.4.0::gentoo failed (compile phase):
  Failed to run 'emake -f client.mk profiledbuild'

Call stack:
    ebuild.sh, line  124:  Called src_compile
  environment, line 5146:  Called virtx 'emake' '-f' 'client.mk' 'profiledbuild'
  environment, line 6226:  Called die
The specific snippet of code:
      [[ ${retval} -ne 0 ]] && die "Failed to run '$@'";

I was building with pgo. Did this happen to anyone else? I've been looking around but so far I've got nothing.

Spargeltarzan · Post by **Spargeltarzan** » Sat Dec 02, 2017 5:18 pm

I started to have troubles to build firefox with pgo enabled due to gcc 6 (also on profile 13). I compiled without pgo and additionally I use now also firefox 57-bin

manugutito · Post by **manugutito** » Sat Dec 02, 2017 6:22 pm

Spargeltarzan wrote:I started to have troubles to build firefox with pgo enabled due to gcc 6 (also on profile 13). I compiled without pgo and additionally I use now also firefox 57-bin

You're right, if I dont use pgo it works. So it's probably unrelated to the profile change.

unheatedgarage · Post by **unheatedgarage** » Sat Dec 02, 2017 8:06 pm

Soul Reaver wrote:So how does this relate to clang? I use clang as my main compiler, falling back to gcc for some incompatible packages. Is it sufficient to recompile those packages built with gcc? Are clang built binaries even compatible with gcc (+pie) built binaries?

I, too, have the same question. What information I did find was vague and waaaaay over my head. For instance, according to this doc for Clang 6: https://clang.llvm.org/docs/ThreadSanitizer.html

Non-position-independent executables are not supported. Therefore, the fsanitize=thread flag will cause Clang to act as though the -fPIE flag had been supplied if compiling without -fPIC, and as though the -pie flag had been supplied if linking an executable.

So, we should put fsanitize=thread in our make.conf?

Elsewhere I read on an old Android forum that -fpie was enable by default for Clang, but I can't even find that now and it's probably not relevant.

I decided to follow the announcement procedure regarding GCC and the toolchain, but just continue building what I can with clang and see what happens. Will be interested to know what you decide to do/how it works out for you.

patrix_neo · Post by **patrix_neo** » Sat Dec 02, 2017 8:20 pm

I am on gcc 6.4.0

A strange thing happen as I try to shortcut when a rebuild went down to georgia..

I captured the package loss and made a textfile of the rest of the package, refined it to suit an execution involving cat.
To my dismay, I found out emerge could not comprehend commands as

Code: Select all

emerge 'media-libs/sdl-net-1.2.8-r1'

So...I tried to make

Code: Select all

emerge -DNUa sdl-net

Got the answer: holy-crap ~ # emerge -DNua sdl-net

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

Calculating dependencies... done!
[ebuild R ] app-text/xmlto-0.0.26-r1 USE="text*"

Would you like to merge these packages? [Yes/No]

Made me laugh.
I will probably win some time rebuild and then take some consequences to rebuild again.
...oh well. Life still sucks.

klynastor · Post by **klynastor** » Sat Dec 02, 2017 8:26 pm

I'm really upset that Gentoo forced PIE on everybody this way. The whole reason I run Gentoo on all of my PCs, compared to any other OS, is for optimal system performance. For my use case, security comes second. I think people should still be given a choice in the matter.

So... (not to incur the wrath of the Gentoo gods...) here's what I did to disable PIE on 17.0:

Create a new file called /etc/portage/profile/package.use.force and append the line "sys-devel/gcc -pie" to it. This releases "pie" from being forced on in the GCC package.

Then edit /etc/make.conf (or /etc/portage/make.conf, whichever exists) and add "-pie" to the end of the USE= line.

That should take care of it. (Until GCC mysteriously breaks years in the future because we don't have the option to compile without PIE anymore. . .)

Spargeltarzan · Post by **Spargeltarzan** » Sat Dec 02, 2017 8:32 pm

@klynastor: Do you think you will be even able to measure this performance difference?

EDIT: If yes, I will be grateful when you can share results...

mv · Post by mv » Sat Dec 02, 2017 8:40 pm

Spargeltarzan wrote:@klynastor: Do you think you will be even able to measure this performance difference?

On an x86 system, one should be able to measure it. On an amd64 system, it should be rather hard to construct an example where one can measure any difference.

That being said, I also do not understand why pie is force-enabled on some profiles and force-disabled on others. Why can't one just trust the user to let him decide? (One of the first things I did when gcc-7 was released was to remove that nonsense USE-mask)

Post by **asturm** » Sat Dec 02, 2017 8:48 pm

If it's just a CFLAG default, why the drama?

patrix_neo · Post by **patrix_neo** » Sat Dec 02, 2017 8:55 pm

I kind of found a way with this:

Code: Select all

for ix in `cat ~user/17.0.lost.txt`; do emerge -1 "=$ix:0"; done;

It caught attension to the rebuild process.

EDIT: Because of some build errors, you might need to redo it again...
The order for packages to be emerged might be mismatched with how it should be done(?).
...and is redundant. It will happen again if the order is the same (text file).

EDIT2: I did a second try and it did work(?!) I think some magic is involved. The scripts, filters and configs just made it happen...
For me.

mv · Post by mv » Sat Dec 02, 2017 9:00 pm

asturm wrote:If it's just a CFLAG default, why the drama?

Where is a drama?

Note that compiler-provided CFLAGS defaults are much more effective than those set by the user in the environment: A lot of ebuilds and build systems filter/ignore user-specified CFLAGS; in particular many packages of the toolchain do this. This is one of the reasons why the hardened project had patched gcc instead of just recommending to add some USE-flags. What we see now is one of this hardened ideas becoming "mainstream".

Post by **asturm** » Sat Dec 02, 2017 9:34 pm

mv wrote:
asturm wrote:If it's just a CFLAG default, why the drama?
Where is a drama?

It wasn't so much directed at you but two posts above yours.

patrix_neo · Post by **patrix_neo** » Sat Dec 02, 2017 9:42 pm

My last 260 packages or so went OK.
I will probably do another emerge -e @world to test things. Still, most of my system has to be OK for blueberry PIE