FS#57731 - [rogue] compilation of package fails
Attached to Project:
Community Packages
Opened by Erich Eckner (deepthought) - Tuesday, 06 March 2018, 13:36 GMT
Last edited by Kyle Keen (keenerd) - Thursday, 08 March 2018, 05:24 GMT
Opened by Erich Eckner (deepthought) - Tuesday, 06 March 2018, 13:36 GMT
Last edited by Kyle Keen (keenerd) - Thursday, 08 March 2018, 05:24 GMT
|
Details
Description:
extra-x86_64-build fails with: gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c mach_dep.c mach_dep.c: In function ‘lock_sc’: mach_dep.c:406:2: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] (void) fgets(prbuf, MAXSTR, stdin); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c main.c gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -c mdport.c mdport.c: In function ‘md_hasclreol’: mdport.c:264:17: error: dereferencing pointer to incomplete type ‘TERMINAL {aka struct term}’ if (cur_term->type.Strings == NULL) ^~ make: *** [Makefile:130: mdport.o] Error 1 Additional info: * package version(s) rogue 5.4.4-5 (git revision e1eee4fc78a9a9570f7baeb07de71db13d0da014) * config and/or log files etc. full log is attached Steps to reproduce: > git checkout e1eee4fc78a9a9570f7baeb07de71db13d0da014 > cd rogue/repos/community-x86_64 > extra-x86_64-build |
This task depends upon
Closed by Kyle Keen (keenerd)
Thursday, 08 March 2018, 05:24 GMT
Reason for closing: Fixed
Additional comments about closing: see svn
Thursday, 08 March 2018, 05:24 GMT
Reason for closing: Fixed
Additional comments about closing: see svn
Comment by Kyle Keen (keenerd) -
Thursday, 08 March 2018, 05:23 GMT
This particular bug has been fixed (in SVN) but it is worth noting
that Rogue is presently unplayable. Dark rooms have rendering
glitches were it appears blank spaces are not drawn? Hard to say.
But it is also present in the old binary, so it is unrelated to
this exact bug.
log.x86_64