Re: [gentoo-user] Re: Emerge does want to tell me...what?
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.
Re: [gentoo-user] Re: Emerge does want to tell me...what?
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?
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.
[gentoo-user] Re: Emerge does want to tell me...what?
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 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
Re: [gentoo-user] Re: Emerge does want to tell me...what?
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?
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?
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?
On Monday, 4 December 2017 19:19:33 GMT Walter Dnes wrote: > On Mon, Dec 04, 2017 at 10:34:48AM +, 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?
On Mon, Dec 04, 2017 at 02:19:33PM -0500, Walter Dnes wrote > On Mon, Dec 04, 2017 at 10:34:48AM +, 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 I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Emerge does want to tell me...what?
On Mon, Dec 04, 2017 at 10:34:48AM +, 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 I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Emerge does want to tell me...what?
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?
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] Re: Emerge does want to tell me...what?
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?
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?
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.
