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

[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 <dilfridge@gentoo.org> (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 <dilfridge@gentoo.org> (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
way....but 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] Emerge does want to tell me...what?

[Heiko Baums]

Am Sun, 3 Dec 2017 05:43:39 +0100
schrieb tuxic@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 <dilfridge@gentoo.org> (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 <dilfridge@gentoo.org> (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 <number of the latest gcc profile>
# emerge -1 sys-devel/gcc
# gcc-config -l
# gcc-config set <number of the latest gcc profile>
# source /etc/profile
# emerge -1 sys-devel/libtool
# gcc --version
# emerge --depclean =sys-devel/gcc-<versionnumber> [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

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 tuxic@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 <dilfridge@gentoo.org> (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 <dilfridge@gentoo.org> (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 <number of the latest gcc profile>
> # emerge -1 sys-devel/gcc
> # gcc-config -l
> # gcc-config set <number of the latest gcc profile>
> # source /etc/profile
> # emerge -1 sys-devel/libtool
> # gcc --version
> # emerge --depclean =sys-devel/gcc-<versionnumber> [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] Emerge does want to tell me...what?

[Heiko Baums]

Am Sun, 3 Dec 2017 06:29:29 +0100
schrieb tuxic@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?

[Dale]

Heiko Baums wrote:
> Am Sun, 3 Dec 2017 06:29:29 +0100
> schrieb tuxic@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?

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On Sun, Dec 3, 2017 at 3:43 PM, <tuxic@posteo.de> wrote:

> 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 <dilfridge@gentoo.org> (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 <dilfridge@gentoo.org> (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
>

If they are installed, make sure they are not active, then uninstall them.

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

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

[Ian Zimmerman]

On 2017-12-03 06:46, Heiko Baums wrote:

> 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.

Those include palemoon.  GL with fixing that.

I'm keeping the old profile for now, but when I switch I'll have to
unmask one of the old compilers.

-- 
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] Re: Emerge does want to tell me...what?

[Simon Thelen]

On 17-12-03 at 09:52, Ian Zimmerman wrote:
> On 2017-12-03 06:46, Heiko Baums wrote:
> 
> > 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.
> Those include palemoon.  GL with fixing that.
Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
ebuild you're using requires an older gcc it's either wrong or doing
something weird.

-- 
Simon Thelen

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

[Ian Zimmerman]

On 2017-12-03 18:58, Simon Thelen wrote:

> Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
> ebuild you're using requires an older gcc it's either wrong or doing
> something weird.

It builds, but the result binary crashes every 10 minutes.  Have you
tried it?

The ebuild from the palemoon overlay explicitly checks for the gcc
version and refuses to proceed if it's newer then 4.9.4.  I have
wondered why, but now I know.

-- 
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] Re: Emerge does want to tell me...what?

[Simon Thelen]

On 17-12-03 at 12:06, Ian Zimmerman wrote:
> On 2017-12-03 18:58, Simon Thelen wrote:
> 
> > Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
> > ebuild you're using requires an older gcc it's either wrong or doing
> > something weird.
> It builds, but the result binary crashes every 10 minutes.  Have you
> tried it?
I have had similar issues, but gcc 6.4.0 isn't the (sole) reproducer.

I have 2 systems, a haswell laptop and a Ryzen desktop.
Palemoon works fine built using gcc 6.4.0 on the laptop.
On the desktop, however, I had regularly occurring segfaults that
occurred whenever I ran palemoon and had the ulimit for core dumps set
to 0 (ulimit -c to any other value and the segfaults would not occur). I
managed to "fix" the segfaulting by compiling palemoon with CFLAGS="-O1"
instead of "-O2".
I never tried reproducing with an older gcc or clang as the issue only
popped up when I rebuilt my desktop for the Ryzen CPU (switched from
Nehalem where everything worked fine).

Another person I know who uses palemoon on Gentoo has also had no issues
with palemoon built against gcc 6.4.0 on an Xeon with Haswell
architecture.

I assumed this was an issue just with my machine since I could not
reproduce it anywhere else. It might be that palemoon has issues with
certain optimizations/instruction sets that are aggravated by using
newer gcc versions (which could turn on optimizations by default etc).

I tried checking when/why the GCC_SUPPORTED_VERSIONS was added to the
palemoon overlay ebuilds, but can't find an issue or commit introducing
it (didn't spend that long checking), but if I'm not the only one
affected by this it might be worth it to open an issue with upstream.

> The ebuild from the palemoon overlay explicitly checks for the gcc
> version and refuses to proceed if it's newer then 4.9.4.  I have
> wondered why, but now I know.
If you are on Ryzen (or potentially any architecture that isn't
Nehalem-Haswell) you could try seeing if it's the same issue I
experienced (testing with `ulimit -c unlimited', recompiling with -O1),
otherwise you could try out the ebuild I maintain at [1] which may have
some differences from the one in the palemoon overlay.

[1]: https://git.c-14.de/landsraad.git/tree/www-client/palemoon/palemoon-27.6.2.ebuild

-- 
Simon Thelen

[gentoo-user] palemoon and gcc [Was: Emerge does want to tell me...what?]

[Ian Zimmerman]

On 2017-12-03 22:45, Simon Thelen wrote:

> It might be that palemoon has issues with certain
> optimizations/instruction sets that are aggravated by using newer gcc
> versions (which could turn on optimizations by default etc).

Yes, this is my provisional explanation too.

> I tried checking when/why the GCC_SUPPORTED_VERSIONS was added to the
> palemoon overlay ebuilds, but can't find an issue or commit introducing
> it (didn't spend that long checking), but if I'm not the only one
> affected by this it might be worth it to open an issue with upstream.

Unfortunately I'm a really shy person and I'm easily turned off by any
shade of hostility.  And this is what I meant by my "good luck" remark.
Upstream isn't quite overtly hostile but still I sense the message that
the Linux port is a stepchild, just as it is with Firefox.

All of which is a way of saying: if it's worth raising an issue, I'd
rather not be the one to do it.

> If you are on Ryzen (or potentially any architecture that isn't
> Nehalem-Haswell) you could try seeing if it's the same issue I
> experienced (testing with `ulimit -c unlimited', recompiling with -O1),

> otherwise you could try out the ebuild I maintain at [1] which may have
> some differences from the one in the palemoon overlay.

My cpu is AMD Phenom.  I'll do both of these things at some point when
things are quiet here.

-- 
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] Re: Emerge does want to tell me...what?

[Peter Humphrey]

On Sunday, 3 December 2017 17:58:53 GMT Simon Thelen wrote:
> On 17-12-03 at 09:52, Ian Zimmerman wrote:
> > On 2017-12-03 06:46, Heiko Baums wrote:
> > > 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.
> > 
> > Those include palemoon.  GL with fixing that.
> 
> Palemoon builds fine with gcc 6.4.0 (just not with gcc 7.2.0), if the
> ebuild you're using requires an older gcc it's either wrong or doing
> something weird.

It doesn't build here; I get a few errors, thus:

 9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
runtime; recompile with -fPIC
 9:41.58 ../../build/unix/gold/ld: error: read-only segment has dynamic 
relocations
 9:41.58 /var/tmp/portage/www-client/palemoon-27.6.2/work/palemoon-27.6.2/
media/libstagefright/binding/MoofParser.cpp:767: error: undefined reference 
to 'GetDemuxerLog()'
...
ERROR: www-client/palemoon-27.6.2::palemoon failed (compile phase)

This is after upgrading to the 17.0 plasma profile, as instructed in the 
news item. Does it warrant a bug report?

-- 
Regards,
Peter.

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

[Walter Dnes]

On Mon, Dec 04, 2017 at 10:34:48AM +0000, Peter Humphrey wrote

> It doesn't build here; I get a few errors, thus:
> 
>  9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
> R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
> runtime; recompile with -fPIC
           ********************
           ********************

  GCC is giving you a hint.  Actually, I've run into other stuff in
Gentoo that breaks with PIE and PIC.  Google is full of complaints for
other distros.  I'm seriously considering sticking "-fno-pic -fno-pie"
into CFLAGS/CXXFLAGS before migrating to 17.0.  And it'll also save me
from rebuilding everything on every machine.  My ancient netbook with 2
gigs of ram will thank me.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Walter Dnes]

On Mon, Dec 04, 2017 at 02:19:33PM -0500, Walter Dnes wrote
> On Mon, Dec 04, 2017 at 10:34:48AM +0000, Peter Humphrey wrote
> 
> > It doesn't build here; I get a few errors, thus:
> > 
> >  9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> > palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> > libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
> > R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
> > runtime; recompile with -fPIC
>            ********************
>            ********************
> 
>   GCC is giving you a hint.  Actually, I've run into other stuff in
> Gentoo that breaks with PIE and PIC.  Google is full of complaints for
> other distros.  I'm seriously considering sticking "-fno-pic -fno-pie"
> into CFLAGS/CXXFLAGS before migrating to 17.0.  And it'll also save me
> from rebuilding everything on every machine.  My ancient netbook with 2
> gigs of ram will thank me.

  While we're at it, throw "-pic" into USE, to speed up the
non-pic/non-pie system...

[d531][waltdnes][~] grep -i ":pic - disable" /usr/portage/profiles/use.local.desc
app-arch/gzip:pic - disable optimized assembly code that is not PIC friendly
dev-util/electron:pic - Disable optimized assembly code that is not PIC friendly
games-emulation/yabause:pic - disable optimized assembly code that is not PIC friendly
games-fps/duke3d:pic - disable optimized assembly code that is not PIC friendly
media-libs/mesa:pic - disable optimized assembly code that is not PIC friendly
media-libs/x264:pic - disable optimized assembly code that is not PIC friendly
media-libs/x265:pic - Disable optimized assembly code that is not PIC friendly
media-libs/xvid:pic - disable optimized assembly code that is not PIC friendly
media-video/transcode:pic - disable optimized assembly code that is not PIC friendly
www-client/chromium:pic - Disable optimized assembly code that is not PIC friendly

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Peter Humphrey]

On Monday, 4 December 2017 19:19:33 GMT Walter Dnes wrote:
> On Mon, Dec 04, 2017 at 10:34:48AM +0000, Peter Humphrey wrote
> 
> > It doesn't build here; I get a few errors, thus:
> >  9:41.58 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> > 
> > palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> > libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic
> > R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at
> > runtime; recompile with -fPIC
> 
>            ********************
>            ********************
> 
>   GCC is giving you a hint.  Actually, I've run into other stuff in
> Gentoo that breaks with PIE and PIC.  Google is full of complaints for
> other distros.  I'm seriously considering sticking "-fno-pic -fno-pie"
> into CFLAGS/CXXFLAGS before migrating to 17.0.

I've been waiting for shouts of horror at that suggestion, but all's quiet 
so I'll see if I can remember how to set -fpic in the environment of 
palemoon. I'd have expected the ebuild do that though.

> And it'll also save me from rebuilding everything on every machine.  My
> ancient netbook with 2 gigs of ram will thank me.

-- 
Regards,
Peter.

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

[Michael Orlitzky]

On 12/05/2017 05:23 AM, Peter Humphrey wrote:
> 
> I've been waiting for shouts of horror at that suggestion, but all's quiet 
> so I'll see if I can remember how to set -fpic in the environment of 
> palemoon. I'd have expected the ebuild do that though.

The upstream build system should already be using -fpic for any of its
shared objects[0]:

  The most important recommendation is to always use
  -fpic or -fPIC when generating code which ends up in
  DSOs. This applies to data as well as code... When gcc
  is used... It is therefore mandatory to compile all
  code which can potentially end up in a DSO with
  -fpic/-fPIC since otherwise the DSO might not work
  correctly.

If -fpic is missing, it's probably a bug in some Makefile. The ebuild
*can* fix that in the meantime, but it belongs upstream.


[0] http://people.redhat.com/drepper/dsohowto.pdf

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

[Peter Humphrey]

On Tuesday, 5 December 2017 13:18:59 GMT Michael Orlitzky wrote:
> On 12/05/2017 05:23 AM, Peter Humphrey wrote:
> > I've been waiting for shouts of horror at that suggestion, but all's
> > quiet so I'll see if I can remember how to set -fpic in the environment
> > of palemoon. I'd have expected the ebuild do that though.
> 
> The upstream build system should already be using -fpic for any of its
> shared objects[0]:
> 
>   The most important recommendation is to always use
>   -fpic or -fPIC when generating code which ends up in
>   DSOs. This applies to data as well as code... When gcc
>   is used... It is therefore mandatory to compile all
>   code which can potentially end up in a DSO with
>   -fpic/-fPIC since otherwise the DSO might not work
>   correctly.
> 
> If -fpic is missing, it's probably a bug in some Makefile. The ebuild
> *can* fix that in the meantime, but it belongs upstream.
> 
> 
> [0] http://people.redhat.com/drepper/dsohowto.pdf

Ah. Right. I see now.

-- 
Regards,
Peter.

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

[Peter Humphrey]

On Tuesday, 5 December 2017 10:23:30 GMT Peter Humphrey wrote:

> I've been waiting for shouts of horror at that suggestion, but all's quiet
> so I'll see if I can remember how to set -fpic in the environment of
> palemoon. I'd have expected the ebuild do that though.

OK, I've done that and now I get these errors:

[...]
10:08.72 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
runtime; recompile with -fPIC
10:08.72 ../../build/unix/gold/ld: error: read-only segment has dynamic 
relocations
10:08.72 /var/tmp/portage/www-client/palemoon-27.6.2/work/palemoon-27.6.2/
media/libstagefright/binding/MoofParser.cpp:767: error: undefined reference 
to 'GetDemuxerLog()'
[...]

I can't see how an undefined reference can be due to my environment, or can 
it?

-- 
Regards,
Peter.

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

[Raffaele Belardi]

Peter Humphrey wrote:
> On Tuesday, 5 December 2017 10:23:30 GMT Peter Humphrey wrote:
> 
>> I've been waiting for shouts of horror at that suggestion, but all's quiet
>> so I'll see if I can remember how to set -fpic in the environment of
>> palemoon. I'd have expected the ebuild do that though.
> 
> OK, I've done that and now I get these errors:
> 
> [...]
> 10:08.72 ../../build/unix/gold/ld: error: /var/tmp/portage/www-client/
> palemoon-27.6.2/work/palemoon-27.6.2/o/toolkit/library/../../media/
> libstagefright/Unified_cpp_media_libstagefright0.o: requires dynamic 
> R_X86_64_PC32 reloc against '_Z13GetDemuxerLogv' which may overflow at 
> runtime; recompile with -fPIC
> 10:08.72 ../../build/unix/gold/ld: error: read-only segment has dynamic 
> relocations
> 10:08.72 /var/tmp/portage/www-client/palemoon-27.6.2/work/palemoon-27.6.2/
> media/libstagefright/binding/MoofParser.cpp:767: error: undefined reference 
> to 'GetDemuxerLog()'
> [...]
> 
> I can't see how an undefined reference can be due to my environment, or can 
> it?
> 

The real error is few lines above and the solution suggested: 'recompile with -fPIC'. ld
does not find a suitable GetDemuxerLog due to that error. Looks like your -fpic
modification did not make it through.

raffaele

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

[Ian Zimmerman]

On 2017-12-05 14:02, Peter Humphrey wrote:

> > [0] http://people.redhat.com/drepper/dsohowto.pdf
> 
> Ah. Right. I see now.

The error message you're showing probably means that -fpic is in effect
when in fact -fPIC is needed.  Quoting the gcc manual:

 If the GOT size for the linked executable exceeds a machine-specific
 maximum size, you get an error message from the linker indicating that
 `-fpic' does not work; in that case, recompile with `-fPIC' instead.

-- 
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] Re: Emerge does want to tell me...what?

[Peter Humphrey]

On Tuesday, 5 December 2017 16:49:28 GMT Raffaele Belardi wrote:

> Looks like your -fpic modification did not make it through.

Do I have my syntax wrong, then?

# cat /etc/portage/package.env
www-client/palemoon     nopic
peak ~ # cat /etc/portage/env/nopic
CFLAGS="${CFLAGS} -fPIC"

I've tried -fPIC and -fpic, but I still get the error:
	undefined reference to 'GetDemuxerLog()'

I used this as guide:
	https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package

-- 
Regards,
Peter.

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

[Raffaele Belardi]

Peter Humphrey wrote:
> On Tuesday, 5 December 2017 16:49:28 GMT Raffaele Belardi wrote:
> 
>> Looks like your -fpic modification did not make it through.
> 
> Do I have my syntax wrong, then?
> 
> # cat /etc/portage/package.env
> www-client/palemoon     nopic
> peak ~ # cat /etc/portage/env/nopic
> CFLAGS="${CFLAGS} -fPIC"
> 
> I've tried -fPIC and -fpic, but I still get the error:
> 	undefined reference to 'GetDemuxerLog()'
> 
> I used this as guide:
> 	https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package
> 

Two suggestions, neither of which I believe will solve your problem:
- did you rebuild completely palemoon after changing the -fpic into -fPIC? If you issued
'emerge' as usual and not 'make' directly in the palemoon build dir then the answer is yes.
- could it be that CXXFLAGS is not affected by the CFLAGS change in the package.env? Try
specifying both in the nopic file

Sorry, I'm out of ideas.

raffaele

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

[Peter Humphrey]

On Wednesday, 6 December 2017 10:33:54 GMT Raffaele Belardi wrote:
> Peter Humphrey wrote:
> > On Tuesday, 5 December 2017 16:49:28 GMT Raffaele Belardi wrote:
> >> Looks like your -fpic modification did not make it through.
> > 
> > Do I have my syntax wrong, then?
> > 
> > # cat /etc/portage/package.env
> > www-client/palemoon     nopic
> > peak ~ # cat /etc/portage/env/nopic
> > CFLAGS="${CFLAGS} -fPIC"
> > 
> > I've tried -fPIC and -fpic, but I still get the error:
> > 	undefined reference to 'GetDemuxerLog()'
> > 
> > I used this as guide:
> > 	https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_vari
> > 	ables_per_package
> Two suggestions, neither of which I believe will solve your problem:
> - did you rebuild completely palemoon after changing the -fpic into -fPIC?
> If you issued 'emerge' as usual and not 'make' directly in the palemoon
> build dir then the answer is yes.

It is, yes.

> - could it be that CXXFLAGS is not affected by the CFLAGS change in the
> package.env? Try specifying both in the nopic file

Indeed I had missed CXXFLAGS (duh), but after adding CXXFLAGS="${CFLAGS}" to
env/nopic the result was the same.

> Sorry, I'm out of ideas.

Don't worry - I can always revert to palemoon-bin. Thanks anyway, Raffaele.

-- 
Regards,
Peter.