Duke4.net Forums: Build failure without Polymer - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Build failure without Polymer  "make POLYMER=0 SDL_TARGET=1"

User is offline   Zagro 

#1

Spoiler


Ubuntu 12.04 on a PowerPC.

This post has been edited by Hendricks266: 28 November 2014 - 07:54 PM
Reason for edit: spoiler'd

1

User is offline   Helixhorned 

  • EDuke32 Developer

#2

View PostZagro, on 08 September 2014 - 10:47 AM, said:

PowerPC

Holy crap, these things still exist? It builds fine on Ubuntu 14.04 x86_64 here, so I'm assuming it's a problem with that platform. I used to add hacks to make EDuke32 (hopefully) compile properly on PowerPC, but I've given up on it because I (and I assume everyone else on the team) don't even have to means to make sure that no bugs due to e.g. the different endianness are left. Sorry.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#3

Dependency problem? Search for "glinfo" as both filename and text contained in file in your /usr directory. And search the available Ubuntu packages for the same. Maybe that gives a hint.
Another guess: "make veryclean" isn't reliable any more. Check that there are no libraries or object files left from a previous make run with different command line parameters than "POLYMER=0 SDL_TARGET=1".
0

User is offline   Zagro 

#4

Hi, it's not a PowerPC only issue. I tried compiling in the same way on a Ubuntu 14.04 intel 32bit after doing a clean checkout. The issue is still reproducible, and "make POLYMER=0" is enough for it.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#5

It seems you've been away for a while. Therefore one more issue seems possible:
The EDuke32 repository has been moved some time ago. Maybe your local repo points to the old address. The current version is r4593 at http://svn.eduke32.com/eduke32/
0

User is offline   Zagro 

#6

I am indeed on r4593, and I get the svn code as documented here:
http://wiki.eduke32....e32_Source_Code
0

User is offline   LeoD 

  • Duke4.net topic/3513

#7

Bump.

Had some shits'n giggles time today:

"POLYMER=0" build failure confirmed on Debian64/Jessie, Raspbian/Jessie, and Win7/mingw64.

Under Linux the issue starts at r4498: Attached File  r4498-POLYMER=0-rpi+debian64vm.log (600bytes)
Number of downloads: 189

MinGW64 gives up since r3758 already: Attached File  r3758-POLYMER=0-mingw64.log (2.18K)
Number of downloads: 192

Failure log of latest sources: Attached File  r4762-POLYMER=0-mingw64.log (427bytes)
Number of downloads: 220
0

User is offline   Hendricks266 

  • Weaponized Autism

  #8

View PostLeoD, on 25 November 2014 - 10:59 AM, said:

"POLYMER=0" build failure confirmed on Debian64/Jessie, Raspbian/Jessie, and Win7/mingw64.

Helix addressed one/some/all of those with r4764. Could you verify all are fixed?
0

User is offline   LeoD 

  • Duke4.net topic/3513

#9

View PostHendricks266, on 25 November 2014 - 04:23 PM, said:

Helix addressed one/some/all of those with r4764. Could you verify all are fixed?

MinGW64 : "POLYMER=0" is OK now, "POLYMER=0 RENDERTYPE=WIN" is not (probably introduced somewhere between r4317 and r4488):
Attached File  r4764-POLYMER=0-RENDERTYPE=WIN-mingw64.log (568bytes)
Number of downloads: 200

Debian: I assume it's fixed since game.c gets compiled now, but building stops at animvpx.c due to an unrelated(?) issue, regardless of the make parameters:
Attached File  r4764-rpi+debian64vm.log (2.92K)
Number of downloads: 193
1

User is offline   LeoD 

  • Duke4.net topic/3513

#10

View PostLeoD, on 25 November 2014 - 06:48 PM, said:

MinGW64 : "POLYMER=0" is OK now, "POLYMER=0 RENDERTYPE=WIN" is not
Well, even I could figure out this one in almost no time:
Attached File  winlayer.c.patch.zip (23.61K)
Number of downloads: 160
1

User is offline   Hendricks266 

  • Weaponized Autism

  #11

Everything but the GTK banner error should be fixed. That one is fairly simple in concept but is the result of messy gtk headers and would require something ugly for a quick fix. For now, make CPLUSPLUS=0.
0

User is offline   TerminX 

  • el fundador

  #12

View PostHendricks266, on 28 November 2014 - 02:06 AM, said:

Everything but the GTK banner error should be fixed. That one is fairly simple in concept but is the result of messy gtk headers and would require something ugly for a quick fix. For now, make CPLUSPLUS=0.

Since that banner already gets piped through sed once to fix something else, we might as well double down on the ugliness and do the same thing to fix this. It's probably one of the least ugly ways to do it, actually...
0

User is offline   Hendricks266 

  • Weaponized Autism

  #13

OK, GTK C++ builds should be error-free now.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#14

View PostHendricks266, on 28 November 2014 - 04:35 PM, said:

OK, GTK C++ builds should be error-free now.
Nope :) :
{eduke32_debian}> make POLYMER=0 CPLUSPLUS=1
[...]
Built object source/obj/game_banner.o 
source/startgtk.game.c: In function ‘GtkWidget* create_window()’:
source/startgtk.game.c:548:139: error: invalid conversion from ‘int’ to ‘GtkAttachOptions’ [-fpermissive]
    gtk_table_attach(GTK_TABLE(stwidgets.configtlayout), stwidgets.vmode3dcombo, 1,2, 0,1, GTK_EXPAND | GTK_FILL, (GtkAttachOptions)0, 4, 7);
                                                                                                                                           ^
Failed building source/obj/startgtk.game.o from source/startgtk.game.c!
Makefile:562: recipe for target 'source/obj/startgtk.game.o' failed
make: *** [source/obj/startgtk.game.o] Error 1

make POLYMER=0 CPLUSPLUS=0 is OK.

I have additional issues building USE_OPENGL=1 on Raspbian as of r4605, btw, may come up with a useful report later.

Maybe you guys should create a set of make option test cases which are compiled regularly...
1

User is offline   Hendricks266 

  • Weaponized Autism

  #15

Try now.
1

User is offline   LeoD 

  • Duke4.net topic/3513

#16

View PostHendricks266, on 28 November 2014 - 06:30 PM, said:

Try now.
Works. :)

Since you're dealing with ARM anyway: USE_OPENGL=1 is broken on Raspbian Jessie as of r4605 (r4764 fix applied). Which is exactly the improvement I'm eager to check out...

Attached File  r4605-POLYMER=0-rpi.log (622bytes)
Number of downloads: 187
Attached File  r4605-POLYMER=1-rpi.log (622bytes)
Number of downloads: 179
Attached File  r4773-CPLUSPLUS=0-POLYMER=0-rpi.log (612bytes)
Number of downloads: 198
Attached File  r4774-CPLUSPLUS=1-POLYMER=1-rpi.log (571bytes)
Number of downloads: 198
0

User is offline   Hendricks266 

  • Weaponized Autism

  #17

Could you add "-k" to the make invocation and repost if the logs have any additional errors? I'm working blind here and I'm guessing there are more errors in other objects and I don't want a several-commit runaround.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#18

View PostHendricks266, on 28 November 2014 - 07:50 PM, said:

Could you add "-k" to the make invocation and repost if the logs have any additional errors? I'm working blind here and I'm guessing there are more errors in other objects and I don't want a several-commit runaround.
Here you go:
Attached File  r4777-USE_OPENGL=1-rpi.log (5.9K)
Number of downloads: 206

Btw., while it may have been technically interesting to implement those sliding menus, they actually suck. :)

This post has been edited by LeoD: 29 November 2014 - 05:09 AM

1

User is offline   LeoD 

  • Duke4.net topic/3513

#19

make POLYMER=0 fails as of r5408:
Spoiler


This post has been edited by LeoD: 04 November 2015 - 04:06 AM

0

#20

View PostLeoD, on 29 November 2014 - 05:08 AM, said:

Here you go:
Attachment r4777-USE_OPENGL=1-rpi.log

Btw., while it may have been technically interesting to implement those sliding menus, they actually suck. :)


I'd have to agree, but this is a good project to implement technically fun features :).
0

User is offline   TerminX 

  • el fundador

  #21

View PostLeoD, on 04 November 2015 - 04:05 AM, said:

make POLYMER=0 fails as of r5408:
Spoiler


OK, I'll fix that later today. My bad.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options