Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building how-to (requires old NDK) #43

Open
mkrupczak3 opened this issue Jan 24, 2020 · 1 comment
Open

Building how-to (requires old NDK) #43

mkrupczak3 opened this issue Jan 24, 2020 · 1 comment
Labels
good first issue Good for newcomers

Comments

@mkrupczak3
Copy link
Owner

On January 24, 2020 3:10:21 AM EST, vanta wrote:

Hello, I'm author of this issue: #40

I'm trying to compile the project right now, what version of build tools have you used? android-ndk, etc. Also, since there are no build instructions, are there some undocumented build steps that I should be aware of? (or it's simply ./build.sh and ./gradlew assembleRelease)

Hi Vanta,

#41

Thanks for your interest in this project

It's been a while since I have been able to "compile" a working version of this app due to Byzantine problems with the NDK during compilation

I think your best bet would be to look at my commit history, look at the time that I committed a "build" of the app, and then using whatever version of the NDK was latest during the time I built it.

So, you're right on the money for how to build it. Build.sh patches and compiles the C/C++ GZDOOM portions and other libraries, and gradle assemble builds the apk with the binaries you've built in build.sh

If you're on Linux/Mac or whatever, you'll need to remove the .bat from one of the last lines of build.sh. I had to add that since I was compiling on Windows.

I was dorking around recently and was able to find how to add armv8a as a build target, but I've since forgotten. I have the changes on one of my local environments, and could give them to you if you need (I was unable to get the app to compile though [using NDK 16b], hence why I've kind of rage quit this project for a minute. You probably won't have issues if you use the correct NDK version though)

This would be necessary before any new versions could be published on the play store

@mkrupczak3 mkrupczak3 added the good first issue Good for newcomers label Jan 24, 2020
@mkrupczak3 mkrupczak3 changed the title Building requires old NDK Building how-to (requires old NDK) Jan 24, 2020
@mkrupczak3 mkrupczak3 pinned this issue Jan 24, 2020
@mkrupczak3
Copy link
Owner Author

mkrupczak3 commented Jan 29, 2020

On 1/28/20 1:43 PM, vanta wrote:

Hello, I'm still having troubles building gzdoom. I'm using repo version
from 0.4.3 tag (which is the last release). I've tried all NDKs from
r20b to r11c, with following results:

Cloning the repo with --recurse-submodules or running git submodule
update --init fails, since submodules doom/src/main/jni/jpeg8d and
doom/src/main/jni/openal-soft-android point to non-existent commits (so
I had to git reset them to HEAD manually).

All NDKs above r17c had this error message:


/home/**********/android-ndk-r18b/build/core/add-application.mk:178: ***
Android NDK: APP_STL stlport_static is no longer supported. Please
switch to either c++_static or c++_shared. See
https://developer.android.com/ndk/guides/cpp-support.html for more
information. Stop.


NDKs above r14b and up to r17c had this error message:


[armeabi-v7a] Compile++ thumb: gzdoom <= m_alloc.cpp
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp: In function 'void*
M_Malloc(size_t)':
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:64:39: error:
'malloc_usable_size' was not declared in this scope
#define _msize(p) malloc_usable_size(p)
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:78:20: note: in
expansion of macro '_msize'
GC::AllocBytes += _msize(block);
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp: In function 'void*
M_Realloc(void*, size_t)':
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:64:39: error:
'malloc_usable_size' was not declared in this scope
#define _msize(p) malloc_usable_size(p)
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:86:21: note: in
expansion of macro '_msize'
GC::AllocBytes -= _msize(memblock);
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:64:39: error:
'malloc_usable_size' was not declared in this scope
#define _msize(p) malloc_usable_size(p)
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:93:20: note: in
expansion of macro '_msize'
GC::AllocBytes += _msize(block);
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp: In function 'void
M_Free(void*)':
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:64:39: error:
'malloc_usable_size' was not declared in this scope
#define _msize(p) malloc_usable_size(p)
^
doom/src/main/jni/gzdoom_android/src/m_alloc.cpp:213:21: note: in
expansion of macro '_msize'
GC::AllocBytes -= _msize(block);
^
make: *** [doom/src/main/obj/local/armeabi-v7a/objs/gzdoom/m_alloc.o]
Error 1


NDKs below r14b had this error message:


[armeabi-v7a] Compile++ thumb: touchcontrols <= TouchControlsContainer.cpp
In file included from
doom/src/main/jni/MobileTouchControls/TouchControlsContainer.cpp:4:0:
doom/src/main/jni/MobileTouchControls/TouchControlsContainer.h:40:28:
error: non-static data member initializers only available with
-std=c++11 or -std=gnu++11 [-Werror]
uint32_t uiHide = 0; // Set to 1 to hide the cureent UI, set
to 2 to also delete it
^
cc1plus: all warnings being treated as errors
make: ***
[doom/src/main/obj/local/armeabi-v7a/objs/touchcontrols/TouchControlsContainer.o]
Error 1

Hmmmm

I think it's totally awesome that you're interested in this project. You're a braver soul than I for being able to dig through all of that and hack at it with the different versions of the NDK.

It's been a while since I've actually been able to / needed to compile the .so's for the engine using the C and C++ code.

My initial suggestion: try looking at the git blame / history and look for changes TacoTheDank did to the C/C++ library code when he went on a cleaning spree. If you can roll back to before then, you might have a shot.

That malloc error looks familiar, are you working on Windows? I think I saw a forum post (this may/may not be it) where somebody though of patching in Doug Lea's Malloc as a header file to work around Windows not having usable malloc tools at compile time. I didn't have to do this the first time I compiled the app though.

My only other suggestion would be to use 14b or below, and try to see if you can revert some of Taco's changes or get an earlier version of the code to compile.

Please let me know if you get something working. Even this output stuff from the compiler that you've got here is super helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant