Bug 233040

Summary: multimedia/x264: Fails to configure: uses gcc 4.2 from base (doesn't support -fstack-protector-strong) with PGO=ON
Product: Ports & Packages Reporter: Laurence 'GreenReaper' Parry <greenreaper>
Component: Individual Port(s)Assignee: Kubilay Kocak <koobs>
Status: Closed Unable to Reproduce    
Severity: Affects Some People CC: w.schwarzenfeld
Priority: --- Keywords: needs-qa
Version: LatestFlags: koobs: maintainer-feedback+
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Log of failed build via portupgrade
none
/etc/make.conf
none
config.log from libx264 (same happened with x264)
none
Output of 'pkg version -v' none

Description Laurence 'GreenReaper' Parry 2018-11-06 19:24:49 UTC
Created attachment 199024 [details]
Log of failed build via portupgrade

I attempted to use portupgrade to upgrade x264-0.155.2917_3 to x264-0.155.2917_4 on 11.2-RELEASE-p4. Linking failed with '/usr/bin/ld: cannot find -lgcov' which appears to refer to a GNU test coverage library

There is "Unknown option --disable-debug, ignored" in the configuration (as well as enable-gpag, enable-lavf and enable-swscale). The full log is attached.

Options selected: LAVF, PGO SWSCALE and GPAC
Not selected: DEBUG, FFMS, GCC and LSMASH

I thought enabling modern GCC might resolve the situation, however it did not. Indeed it did not seem to use it, still showing 'gcc' as the command line.

Built-in gcc is gcc version 4.2.1 20070719  [FreeBSD]

I had gcc6 and gcc7 (gcc version 7.3.0) ports installed and up to date. Installing the port of gcc8 did not resolve the situation.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-04-20 08:45:25 UTC
Apologies for the delay Laurence.

Is this still an issue with the latest version of the ports tree?

If so, can you please provide more information regarding the system, in particular:

- pkg version -v output (as an attachment) so i can see what gcc/toolchain versions are being used
- /etc/make.conf contents (as an attachment, sanitized if necessary)
- Information re how the build is set to use gcc

I can't find references to lgcov or gcov in the {lib}x264 sources
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-04-20 08:51:09 UTC
(In reply to Kubilay Kocak from comment #1)

This could be coming in due to the PGO option (due to -fprofile* flag use). 

Could you disable the PGO option and confirm whether or not the issue is still reproducible
Comment 3 Laurence 'GreenReaper' Parry 2019-05-03 11:53:20 UTC
Sorry for my own delay, I had a bunch of other things to poke at recently.

The PGO option seems to 'override' the GCC option, making it configure with 'gcc' rather than 'gcc8' which was installed as a port. gcc 4.2.1 20070719 doesn't understand the option "-fstack-protector-strong" -> "no working C compiler".

Disabling PGO made libx264 compile with the installed gcc8, and allowed x264 to compile as well (I had to do libx264 first manually)

I tried forcing 'gcc8' by altering CC/CXX/CPP in make.conf but they did not seem to have any impact on whether it used gcc in configure. Previously I have also had to avoid using the gold linker with x264 but that was not an issue at this time.
Comment 4 Laurence 'GreenReaper' Parry 2019-05-03 11:53:38 UTC
Created attachment 204184 [details]
/etc/make.conf
Comment 5 Laurence 'GreenReaper' Parry 2019-05-03 11:54:28 UTC
Created attachment 204185 [details]
config.log from libx264 (same happened with x264)
Comment 6 Laurence 'GreenReaper' Parry 2019-05-03 11:57:07 UTC
And now I re-look at the title, this actually turned into a *different* issue. >_<
But it still prevented me from building the port!
Comment 7 Laurence 'GreenReaper' Parry 2019-05-03 11:59:03 UTC
Created attachment 204186 [details]
Output of 'pkg version -v'
Comment 8 Walter Schwarzenfeld freebsd_triage 2020-01-31 17:27:39 UTC
We have version X264_BUILD=159 X264_REV=2991. Is this still relevant?
Comment 9 Laurence 'GreenReaper' Parry 2020-02-01 00:36:07 UTC
Yes, inasmuch as the PGO config option in x264 and libx264 still does not seem to recognize any other installed GCC (I have the gcc9 port installed), but instead uses 'gcc' which is the GCC 4.2.1 installed with FreeBSD 11.3.

This version does not understand -fstack-protector-strong and so is not considered a working compiler in the configure stage.

Disabling PGO results in successful compilation of both ports with the installed clang90.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2020-02-01 01:02:51 UTC
Need steps to reproduce, including any environment specific conditions
Comment 11 Laurence 'GreenReaper' Parry 2020-02-01 04:25:18 UTC
I've fixed the title since the symptom was different. I've also closed this as upon digging into it the problem is that a copy of GCC 4.2.1 from 2010 (FreeBSSD 8.1) was present, so it would not be reproducible in a correctly-configured system.

The system is running in a jail and I do not manage upgrades for the base software, just the ports. At a guess, the base was no longer built WITH_GCC so there was no new version to overwrite the existing one - but it was also not removed.

It was known in r289465 that the check for -fstack-protector-strong in bsd.sys.mk was not valid for all versions of GCC 4.2.1, but the developer made the reasonable assumption it would work for versions of GCC built for distribution along with the script.
https://svnweb.freebsd.org/base/head/share/mk/bsd.sys.mk?revision=289465&view=markup

Initially when trying to debug this I saw that the x264 Makefile has:
PGO_VARS=      USE_GCC=any \
...

Per /usr/ports/Mk/bsd.gcc.mk this means it can use gcc 4.2 from base. So it does, as I saw by running `make gcc-test` in the port directory. Even if gcc9 is installed from ports.

But I read that -fstack-protector-strong was only introduced in GCC 4.9: 
https://lwn.net/Articles/584225/
...so it breaks.

[I then ran down a path of "maybe you want USE_GCC=7+/yes rather than any" until I discovered that it *shouldn't* break since r286074 backported the feature:
https://svnweb.freebsd.org/base?view=revision&revision=286074 - then looked at the date and output from `file` and found the actual problem.]

So, a learning experience for me, but a distraction for you; my apologies. Ironically this might have been fixed in a future release, since as I understand it that won't support base GCC at all, so presumably won't check for /usr/bin/gcc.
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2020-02-01 04:29:57 UTC
(In reply to Laurence 'GreenReaper' Parry from comment #11)

Thank you very much for the detail and explanation Laurence, much appreciated