checking for NCURSES... yes checking for UDEV... yes checking whether GCRYCTL_SET_THREAD_CBS is declared... yes checking for gcry_control in -lgcrypt... yes checking whether byte ordering is bigendian... no ./configure: eval: line 51626: unexpected EOF while looking for matching `'' ./configure: eval: line 51627: syntax error: unexpected end of file checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile gawk: ./confoWJdGr/subs.awk:21: S["COPYRIGHT_MESSAGE"]=© 1996-2014 the VideoLAN team%!_!# "Copyright © 1996-2014 the VideoLAN team" gawk: ./confoWJdGr/subs.awk:21: ^ invalid char '\C2' in expression gawk: ./confoWJdGr/subs.awk:21: S["COPYRIGHT_MESSAGE"]=© 1996-2014 the VideoLAN team%!_!# "Copyright © 1996-2014 the VideoLAN team" gawk: ./confoWJdGr/subs.awk:21: ^ syntax error config.status: error: could not create Makefile ./configure: eval: line 13: unexpected EOF while looking for matching `'' ./configure: eval: line 14: syntax error: unexpected end of file !!! Please attach the following file when seeking support: !!! /var/tmp/portage/media-video/vlc-2.1.5-r1/work/vlc-2.1.5/config.log
Created attachment 412128 [details] build log of =vlc-2.1.5-r1
Created attachment 412130 [details] config.log from vlc-2.1.5-r1
Created attachment 412132 [details] emerge.info
please test LANG=C emerge vlc.
I must admit that prior to this bug, I was unaware of musl. Looking at the config.log, it looks like configure is failing around _FORTIFY_SOURCE. I've been doing some casual research on musl and it seems _FORTIFY_SOURCE is not supported. My work blocks openwall where the mailing lists are hosted and the musl wiki is throwing me a 404. Can someone more familiar with musl confirm?
LANG=C emerge vlc is not working, the build fails with exactly the same errors. Actually it seems to be a amd64 exclusive bug as I switched over from x86, where vlc used to build just fine without any patching. I may try to sort this out and test with a recent x86 stage 3. I know that Alpine is using a seperate fortify headers package, but that is all I know about it. See http://git.2f30.org/fortify-headers/ for further informations.
vlc used to compile on x86 a few months ago. right now, it gives the same build failure as on amd64. so, is this a regression? can anyone else confirm?
Have you tried downgrading to musl-1.1.10-r1?
I may try if it's possible without breaking the system?
well, it seems possible to downgrade. and by doing so I found out that with =< musl-1.1.11 vlc is NOT failing to compile. but WITH musl 1.1.11-r1 it is failing - the only difference is the musl-1.1.11-fix-codeset.patch with musl-9999 it is neither working.
More minimal example for the eval errors: printf '%s\n' "a='a © a'" | LC_ALL=C sed --posix 's/^\([a-z]*\)=.*/\1/' The output is "a© a'" instead of "a" with the bad versions of musl. It is important that GNU sed is used.
overall this is a non issue re media-video/vlc. vlc-2.1.5-r1 is still in portage because it is the stabled version and vlc-2.2.1.ebuild has not yet been made stable. If this pertains to the 2.2.n set of vlc it then has some legitimacy. sys-libs/musl is not even a build dep of vlc.
fixed with musl 1.1.12
(In reply to tt_1 from comment #13) > fixed with musl 1.1.12 thanks. i've confirmed that felix's reduced case works.
