\ oh right, so this doesn't happen in a clean installation?
I've not come across this in any of my tests, however, it is clear that there are some mods installed here. I can see some armor in there, though I'm pretty sure I fixed those iCCP warnings some time ago. Perhaps a specific drawtype is triggering this?
Same issue on Windows: https://forum.minetest.net/viewtopic.php?f=6&t=16243 (Outdated driver, wrong textures)
Android issue: https://forum.minetest.net/viewtopic.php?f=6&t=20091
Possible duplicate of #3080
@rubenwardy this is CONFIRMED bug.
A simple solution is to disable logs from Irrlicht on Android.
None of Minetest developers will not correct this bug.
Right solution - hmm... The problem is at least 4 years. Hardly it will be decided soon. But let the Android players (especially on Android 8. +) will experience problems in the game. Nobody cares.
How do you disable the logs in Android?
I came across this old topic but it is possibly still relevant. http://irrlicht.sourceforge.net/forum/viewtopic.php?t=43774
I agree with @MoNTE48 we could still include an option to enable the Irrlicht logs for debug purposes. We can always patch Irrlicht if the problem lies there, however, from what I can gather it seems more likely a device/vendor specific issue.
Simple solution:
https://github.com/MultiCraftProject/MultiCraft/commit/968954a3cc8dbdb818813ecd9c8476ff94447f7d#diff-4454bb181ab2b8fd8779df3a60282769R117
I confirm this bug happening on Samsung Galaxy S3 Tablet
This makes console/chat unusable
FWIW, I can confirm this bug. Nexus 6P. Fresh install, all data removed. No mods installed.
The strange thing is that it has appeared recently and minetest has been working fine until it began throwing those errors. So something has changed? Is there any way to fix that without recompiling the app?
@codexp
just add this line on minetest.conf
debug_log_level =
(withount any values)
Although, I'm not sure
Log change does not help.
Generally minetest seems clunky on Android - not an Android person myself, so not sure about the work required.
Just for kicks I installed the ad-infested Multicraft Minestest clone. They made some simple changes to improve the look and feel significantly.
Have you tried a dev build of the android app? There's been lots of in-game improvements
I'd love to test, but would not be able to compile it myself.
Is there a compiled apk for download?
Now I have this error on my PC. The only difference is that it will be logged only once on connect.
Whereas on Android it keeps flooding the console.
@lhofhansl This is called fork, and not a _clone_, if you did not.
Disabling the Internet will save you from advertising
Then forced to play single player?
On Sat, Jul 14, 2018, 5:54 AM MoNTE48 notifications@github.com wrote:
@lhofhansl https://github.com/lhofhansl This is called fork, and not
a clone, if you did not.
Disabling the Internet will save you from advertising—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/minetest/minetest/issues/7525#issuecomment-405012568,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWXKYgt5fL99w-h809z-m8bxLefIOHQfks5uGb_AgaJpZM4U-fQD
.
@jastevenson303, _in next major release ads in multiplayer will be disabled_
@MoNTE48 do you have paid version without ads?
offtopic btw!
@codexp yes, $0.99
_but this is offtop in minetest repo!
Here I just offered my corrections in the minetest._
My phone does the same thing, constant flooding of this error.
Android 8.0
MT 0.4.17.2

:large_orange_diamond:
An anonymous source experienced with graphics said this:
If you want to fix GL_INVALID_ENUM errors, use KHR_debug extension with synchronous mode
You will get callstacks if you put breakpoint inside your debugger in the callback
Can that be translated to english please?
:large_orange_diamond:
If this is the same problem CuteAlien is referring to on the Irrlicht forums (link above) then our options could be quite limited. From what I can understand, some drivers may be falsely reporting the existence of certain extensions, hence why this only occurs on some devices.
Since this is now labelled as a blocker I can only suggest one of the following
Pros: Fixes the user-facing issue fairly easily. (I think)
Cons: Possible loss of useful debug information from users.
Pros: You still receive all other log messages.
Cons: More Irrlicht patchwork and maintenance, also a dirty hack.
What seems clear to me is that it’s unlikely to be a problem that can be fixed within the engine itself, however, I hope I can be proved wrong about that :)
I'd prefer option 2. Option 1 is also a dirty hack
how about grouping same error messages as chrome console does?
I'd also suggest a filter of well known errors that should not be logged to the game screen.
How about an option for the user to send logs to support (with single click).
Maybe even automated log sending once in a while (of course with user's permission to help support the game).
And very important: separate console output in chat, game messages and error logs. (this alone would fix the issue with unreadable chat console)
Option 1 is also a dirty hack
I do not consider this to be a hack so long as it is kept optional and by this I do not mean to disable debug logging altogether, only the output to the game window. These and other non-fatal errors are not exclusive to android either, in many cases the best advice we can give is that the error/warning can be safely ignored, unfortunately that is not a lot of comfort to a mobile user with this filling their screen.
I think that chat in multiplayer game plays a central role. If you are unable to communicate or it becomes very hard to do, a lot of usual actions in game become pointless. So this is not only a matter of comfort, but a serious issue.
It should be said, this issue makes multiplayer virtually useless to a huge amount of people. I would guess this has caused many people to switch to multicraft. I think this deserves high priority and should be fixed ASAP!
:large_orange_diamond:
I think it would be better to fix this right than to fix it wrong. I suggest the following:
For 1 I agree, that should be done asap. For 2 it will take someone who is able to reproduce this to properly trace it, however, I do not get the GL_INVALID_ENUM error on my (Samsung) devices. Unfortunately, there is nothing much we can do about the iCCP warnings other than tell server owners and modders to fix their offending textures. Maybe a dev can post a topic on the forums explaining how to fix them and maybe a helper script to automate the process on a remote server.
I can't reproduce on my device either - I have an S7 Edge
I have a Sony device which I could potentially use if I could manage to actually turn it on (too little battery to even charge)
This problem actually on Android 8.+, basically.
I use Android 8.0
I agree with https://github.com/minetest/minetest/issues/7525#issuecomment-410245217 the app should be fixed ASAP.
I am for disabled(hide) error message in game by default in Game.
This problem actually on Android 6,7,8. On my phones, I had the same problem with GL_INVALID_ENUM spaming on full screen. It's very hard to play with this.
I realise this bug is against 0.4.17.2, but for others who are just trying to get things running:
I was experiencing this issue with my Nexus 6p (running omnirom7.1.2) minetest version 0.4.16.17 from f-droid.
I tried wiping the data folder and installing 0.4.17.1-2 from github releases but it crashed immediately.
I the wiped the data folder again and tried 0.4.16 from github releases and everything works fine.
Bump, needs attention as is a blocker for 5.0.0.
@paramat I think the best solution we have in the short-term is what @MoNTE48 suggested here https://github.com/minetest/minetest/issues/7525#issuecomment-402569839 I would also like to leave it enabled for debug builds. Of course we would need his permission to use this code.
@stujones11 Do not make fun of me. Disabling lines with logs on Android is not code :)
@MoNTE48 I was not making fun of you, just respecting your license but I guess this really does not count here. So long as you don't have a problem with us using it, that's great :)
stujones11 i agree, the simple fix is good enough for the short term, doing the proper fix should not delay 5.0, and it can always be done later before 5.0 if someone finds time.
Please can anyone code the simple fix?
@paramat it would simply be that section of code enclosed in a preprocessor directive.
#if !defined(__ANDROID__) || !defined(NDEBUG)
g_logger.log(irr_loglev_conv[event.LogEvent.Level],
std::string("Irrlicht: ") + event.LogEvent.Text);
#endif
Ok thanks i'll code it, unless someone else wants to.
Thanks but I would like to verify that NDEBUG is in fact present for release builds. It should be, otherwise something else is wrong but this still needs to be verified.
Alternatively, there could be a setting for this, disabled by default. I have no real preference either way.
Ok.
stujones11 are you able to verify that yourself or do you need help with that?
are you able to verify that yourself or do you need help with that?
I think I should be able to do that, I just can't actually sign the release. I will try some of those ideas.
Edit: Looking at config.h I think we are okay with this. https://github.com/minetest/minetest/blob/0e306c084284aeafb3d5cde0cfec11a85a11cb9c/src/config.h#L19
Update: I have confirmed with a release build that NDEBUG is defined and visible there. This is not defined for debug builds (as the name implies) so the error messages will still show.
FWIW, I still can't seem to reproduce this even on a cheap smart-phone running Android 8 but clearly others are seeing this.
Thanks, do you want to make the PR or shall i?
Rubenwardy prefers a proper fix be done for 5.0, which is understandable, but at the least any fix can be backported to 0.4.x.
Also, if merged into 5.0-dev this will temporarily help those testing Android, so i think it's worth merging even if temporary.
We would keep this issue open to remind us to do the proper fix.
Rubenwardy is correct that this could also be impacting performance for those affected and I will continue to look into this, however, I am only really guessing until I can reproduce this myself.
We would keep this issue open to remind us to do the proper fix.
:+1:
do you want to make the PR or shall i?
I can but would prefer if you could just do that, it's only +2 lines of code that cannot effect anything but the android build.
Ok.
As of the recent Irrlicht 1.9 updates, I am now able to get MT to build with the latest Irrlicht-ES sources. It may be a bit of a long-shot but there is some chance that this issue no longer presents itself.
What is interesting is that two of our patch files no longer apply. One, irrlicht-native_activity.patch is clearly now already applied upstream, the other irrlicht-texturehack.patch is for a file that no longer exists and I cannot even seem to find where the code has moved to.
It may well be that this patch is no longer required and there is some evidence to suggest that it could even be linked to the GL_INVALID_ENUM error. Specifically this message always seems to accompany it.
https://github.com/minetest/minetest/blob/b78698240c4b0e4ac410e2aafe6d88b34b1618e2/build/android/patches/irrlicht-texturehack.patch#L50
A debug apk is available here for testing: https://www.dropbox.com/s/zowxsxdknps6g6m/Minetest-debug.apk?dl=0
I am particularly keen to hear from anyone that is able to reproduce this issue.
Feature branch with necessary Makefile changes here: https://github.com/stujones11/minetest/tree/android-irrlicht-1.9
@stujones11 Why you download irrlicht from https://github.com/zaki/irrlicht/tree/ogl-es ? In this repo 1 year old code. You can pull code from official svn
@MoNTE48 svn is very slow, at least for me this is much a quicker method of downloading the sources. This git repo is a mirror of the svn, as far I know.
@stujones11 special for you :D https://github.com/MoNTE48/irrlicht/tree/ogl-es
But now i don't know how update this repo :) I just imported svn repo.
@MoNTE48 Thanks, so much for zaki being an an 'automatically' updating mirror :(
I will make another build with the _very_ latest sources as soon as I get the chance, although I doubt much will have changed in a year regarding the ogl-es branch but you never know.
But now i don't know how update this repo :) I just imported svn repo.
I wouldn't know how to update that automatically either but I have no plans no make a PR for this right now anyway. I already have two open and the last one took almost 4 months to process :D
Stu, there's nothing wrong with open PR. Sooner or later they will pay attention. Just need to be checked by several people. I really appreciate your work, in reality the android port looks abandoned. Since I am no longer interested in developing MC, I plan to suggest some interesting changes.
Although it is very likely that after testing they will also be waiting for a long time :)
Stu, there's nothing wrong with open PR.
Sure, but I am not a huge fan of rebasing and merge conflict resolving :D
I plan to suggest some interesting changes.
I look forward to seeing these. It seems a shame you are abandoning MultiCraft, it was probably the most legitimate fork we had. I have no idea what the problem was but also off-topic here :)
I will, however, certainly make a PR sooner if we find proof that it this does indeed fix this issue. Otherwise, there is not much point updating, we could just end up with a lot of new bugs.
@stujones11 your apk from this msg https://github.com/minetest/minetest/issues/7525#issuecomment-437703583 NOT fixed problem, i'm sorry. Maybe,
a year regarding the ogl-es branch
can help we :)
I have no idea what the problem was but also off-topic here :)
Google blocked my developer, wallet and admob accounts. I can't restore my 50+ millions downloads app or re-public new app. Also, for more than two months, they did not answer me about the reason for blocking. This shows that Google just doesn't care about you. Even if you are a "big" developer.
a year regarding the ogl-es branch can help
I will try asap but I am done for today :) you can always substitute the git url and commit hash in the Makefile and try it yourself. It seems doubtful it will help though :(
for more than two months, they did not answer me
Google just doesn't care about you.
That really sucks dude, sorry to hear that!
This is shocking news you are no longer developing MC.
Looks like we really will need to sort out the official app for 5.0.0 since there will be a lot of players moving to another app.
I get a "Can't Open File" error when I try to open the debug APK.
I get a "Can't Open File" error when I try to open the debug APK.
You may need to enable 'unknown sources', for Android 8 it's slightly different https://stackoverflow.com/questions/46005766/installing-apk-cannot-open-file-on-android-8-0
@MoNTE48 FWIW, I have made a build using the latest sources from your svn import, it certainly seems to build a run ok for me. I have updated the link here https://github.com/minetest/minetest/issues/7525#issuecomment-437703583 if you care to try it.
However, I am not very optimistic it well help in this situation. To me, this looks increasingly likely to be a vendor driver bug. Essentially, the driver falsely reports the existence of a particular extension which Irrlicht then attempts to use resulting in the invalid enumerator error.
@stujones11 Yes you are right... Correcting this error will be more difficult than using the latest Irrlicht... Perhaps a logical solution would be to make a patch that turns off this particular error in the Irrlicht itself, and does not disable the display of all errors on Android?
@MoNTE48 I agree, this would be better than disabling all Irrlicht messages. I might see if I can come up with a patch that simply demotes that error to a warning, that way it will still be logged but not spam the game screen (I think anyway)
The most important thing is not create biggest debug.txt...
The most important thing is not create biggest debug.txt...
I agree to some extent, however, I think this is a slightly different issue. MT debug.txt can get very large regardless of this particular error. There probably should be some type of 'auto-cleaning' mechanism. Perhaps just overwrite the old one on each new session.
Yes, because it can become quite large through a large number of games. I'm not sure, but adding a line in txt over 5 MB in size is a resource-intensive task for slow emmc and weak cpu?
5 MB in size is a resource-intensive task for slow emmc and weak cpu?
Time labelling them on each new session would help in this regard but would still fill up the internal storage over time. But that is another possible solution.
Looks like several messages per second, i'd rather these were not logged anywhere.
I might see if I can come up with a patch that simply demotes that error to a warning
Do you mean there may be a practical way to detect that specific error? If so, just don't log it at all, to avoid filling up debug.txt with a useless message.
How about something like:
if 'irrlicht error' then
if stringmatch(error, 'invalid enum') then
don't log
It hopefully won't be intensive because the string matching only runs on errors, so only a few times per second.
Maybe this can be done in the code i touch in #7837 ?
Anyway, if that's possible i think that's good enough for 5.0 release as it only suppresses that one useless error.
Do you mean there may be a practical way to detect that specific error?
Certainly if you patch Irrlicht directly during the build process, that is what I was thinking of doing. However, your idea should work equally well and would allow you to perhaps log the error only once per session? Patching would be slightly more efficient and it saves us from adding yet more android hacks to the MT codebase but I am neutral on the implementation.
I might update my PR in case patching Irrlicht does not happen for some reason. At the least it will be good enough for a temporary fix for 0.4.17.
@paramat Patching irrlicht is nowhere near as difficult as it may sound. However, I just made a very interesting discovery while looking to do this. The only place where this error is shown is guarded by a #ifdef _DEBUG directive. Unless I am mistaken, it looks like we might be building irrlicht in debug mode? We must have been doing so for quite some time if that is the case. I need to investigate this further
From the latest sources, here: https://github.com/MoNTE48/irrlicht/blob/5b8b895cca0cf59bffea6564dd5d6c3e80947d8d/source/Irrlicht/COGLESDriver.cpp#L1442
I cannot show you the exact lines of the 2015 version we are currently using but little has changed.
Well, MoNTE48 says this is a years old bug so i doubt it and hope not.
Patching Irrlicht seems the ideal solution for 5.0, whoever creates the app store release would build using the patched Irrlicht. However that means building from the MT repo would be more difficult. Maybe the MT repo could contain a patched fork of Irrlicht with just that one change?
Patching Irrlicht seems the ideal solution for 5.0, whoever creates the app store release would build using the patched Irrlicht. However that means building from the MT repo would be more difficult. Maybe the MT repo could contain a patched fork of Irrlicht with just that one change?
This is already possible, and is done 4 times already.
https://github.com/minetest/minetest/tree/master/build/android/patches
@MoNTE48 Could you please test this release-mode debug build if you are able.
https://www.dropbox.com/s/8p85rldhplps637/Minetest-debug.apk?dl=0
@paramat What we need to figure out is why _DEBUG is defined, that code should never be compiled in the first place. It is obvious why my debug builds would show this but not the play-store release!
I agree, needs checking.
Good to see patching Irrlicht is already supported in MT.
@stujones11 i can't install this APK, you can sign he or build via Studio?
@MoNTE48 I rebuilt the apk in Studio, it now looks like a debug build but the libs are still built in release mode.
Link updated here https://github.com/minetest/minetest/issues/7525#issuecomment-439147473
@stujones11 thanks, now it working for me.
I don't look any irrlicht errors in chat!
Clearly then @nerzhul is incompetent :P)
@paramat Mystery solved, not a bug!
@stujones11 yes)))
Do you plan to create PR?
@MoNTE48 There is no PR, just make release -j$(nproc) it could not get much easier.
I have absolutely no idea how he managed to do this, unless the whole build is in debug mode :D
@stujones11
I think that nrz build so:
git clone ...
make debug
and after some time
make release
Because of this, libraries (for example, irrlicht) were not re-make and remained compiled with debugging enabled.
Or maybe he did not back-port my build fixes properly, I didn't really check that one.
So to clarify, the current playstore app was built with Irrlicht in debug mode?
Good news, @nerzhul please could you do a point release in the play store to fix this?
stujones11, MoNTE48 thanks so much for your work on this.
@stujones11 ok i'm incompetent, nice
then what is to do, i don't see any change to apply there
then what is to do
make release -j$(nproc)
@nerzhul Just build it properly, in a clean environment. See: https://github.com/minetest/minetest/issues/7525#issuecomment-439225467
I will check the 0.4.17.x version when I get time but it is more likely what MoNTE48 wrote.
I think it's important to make sure this doesn't happen again. I suggest making the builds using CI, as an unsigned release build. To make a play store release, this build can be downloaded from the CI and then signed locally using the key. This signed copy is then uploaded
Having CI Android builds would also be very useful
@nerzhul to be clear, the current playstore app 0.4.17.2 has this build mistake, so it needs to be fixed immediately as a point release.
There's nothing to do for 5.0 of course, except avoid the same thing happening.
@rubenwardy CI is possible but it take 1 hour to build on my machine, don't expect to be faster on travis :p
Less than 5 minutes on Core i7-8700k :D
@nerzhul the whole build for me takes about 10-15 minutes, including the download of the dep sources. Mostly inhibited by the Irrlicht svn download.
My PC is nothing special, well maybe 5 years ago decent spec WTF are you using?
i build MT in 15 sec , but all deps are long because i'm not building them with +8 to prevent some compilation issues due to cross dep build.
Irrlicht SVN download is slower in france than you it seems, for me it's 10-15 min to download that subversion shit from sourceforgeshit.
t's 10-15 min to download that subversion shit from sourceforgeshit.
The simple answer would be to create our own mirror of the Irrlicht-ES sources. Or even Irrlicht istelf, for that matter.
i'm not building them with +8 to prevent some compilation issues due to cross dep build.
This is nonsense, btw
Note, due to #7813 we may need to merge #7820 before fixing the app, but not sure.
Please test the build provided in the release section of GH https://github.com/minetest/minetest/releases/download/0.4.17.1/Minetest-0.4.17.1-3.apk
A user reports they're still getting the same error with that
I can confirm that this issue still exists in 0.4.17.1-3.apk.
However it may be a good idea to wait for some testing of Android 5.0.0-dev first.
Targeting SDK 26 is now mandatory for any new play-store release, so yes, it is necessary but there is no real need to backport it so long as the playstore release is compiled with these changes. Saying that, it does fix some other bugs and shouldn't be hard to merge.
@nerzhul I might also suggest that you upload your release candidate to github releases first so I/we can verify it before you push to the play-store.
Also, given the circumstances, I think this should be a higher priority than code-refactors for you right now. Our current app is unplayable for many with reduced performance for everyone else.
@stujones11 then we need to split the @MoNTE48 PR in multiple parts. First compat for play store with point release in stable-0.4 branch
@nerzhul AFAIK those java changes and bug-fixes should work equally well with version 0.4.x, though I did not try this yet. I don't see any point in splitting them unless there is a need to.
@rubenwardy why minetest official app public in play store on nrz dev account?
Minetest community can't one time pay $25 for official dev account?
On dev account we can download logcats, crash analytics and lots of useful statistics that nrz does not publish.
why minetest official app public in play store on nrz dev account?
Minetest community can't one time pay $25 for official dev account?
+10000
I'm sure many people would be happy to pay for it, but you need co-operation from nerzhul to actually transfer the app
but you need co-operation from nerzhul
He-he, not me, YOU! :)
I don't think this is a problem. Unless _he_ is afraid of losing control. I think that you are much more experienced in Java than it is.
Nerzhul has shared the playstore access with 1 or 2 other core devs as far as i remember. However i agree it's best to have group access to it.
@MoNTE48 in fact i have a real android full app on the store and at work i'm hosting java applications & microservices produces by our agile development team and i help them to increase their code quality and architecture, trolling is easy, but i have more experience than you think :p
for the rights on the app on my account, @celeron55 , @sfan5 and @rubenwardy share the app ownership with me, i'm just the account owner. It was done on my account because i was the only to get one when it was published. I'm not sure if we can move it to another account, there is already a dead MT app in my account (wrong artifact name) and google refused to remove it...
Note, looking for vitals here is the most reported crash
pid: 0, tid: 0 >>> net.minetest.minetest <<<
backtrace:
#00 pc 0000000000014b24 /system/lib/libc.so (strlen+83)
#01 pc 000000000035dd9b /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZNSt6__ndk111char_traitsIcE6lengthEPKc+14)
#02 pc 000000000079aa77 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_Z11Align2Npot2PN3irr5video6IImageEPNS0_12IVideoDriverE+106)
#03 pc 00000000004c5d8d /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN17MenuTextureSource10getTextureERKNSt6__ndk112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEPj+424)
#04 pc 000000000050c1b7 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN8GUITable10allocImageERKNSt6__ndk112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEE+234)
#05 pc 000000000050a87d /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN8GUITable8setTableERKNSt6__ndk16vectorINS_6OptionENS0_9allocatorIS2_EEEERKNS1_INS_11TableColumnENS3_IS8_EEEERNS1_INS0_12basic_stringIcNS0_11char_traitsIcEENS3_IcEEEENS3_ISH_EEEE+8616)
#06 pc 00000000004d4c6d /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN15GUIFormSpecMenu10parseTableEPNS_10parserDataERKNSt6__ndk112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE+2852)
#07 pc 00000000004e37cb /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN15GUIFormSpecMenu12parseElementEPNS_10parserDataERKNSt6__ndk112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE+4242)
#08 pc 00000000004e6d63 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN15GUIFormSpecMenu13regenerateGuiEN3irr4core8vector2dIjEE+9314)
#09 pc 00000000004e94d7 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN15GUIFormSpecMenu8drawMenuEv+618)
#10 pc 00000000004cad2f /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN12GUIModalMenu4drawEv+158)
#11 pc 0000000000a3be1b /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN3irr3gui14CGUIStaticText4drawEv+946)
#12 pc 00000000004c2003 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN3irr3gui11IGUIElement4drawEv+90)
#13 pc 0000000000a246a1 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN3irr3gui15CGUIEnvironment7drawAllEv+96)
#14 pc 00000000004c87f5 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN9GUIEngine3runEv+1048)
#15 pc 00000000004c7cc1 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN9GUIEngineC1EPN3irr14IrrlichtDeviceEP18JoystickControllerPNS0_3gui11IGUIElementEP12IMenuManagerPNS0_5scene13ISceneManagerEP12MainMenuDataRb+1468)
#16 pc 00000000007933bb /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN14ClientLauncher9main_menuEP12MainMenuData+366)
#17 pc 0000000000790ba9 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN14ClientLauncher11launch_gameERNSt6__ndk112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEbR10GameParamsRK8Settings+2496)
#18 pc 000000000078d627 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (_ZN14ClientLauncher3runER10GameParamsRK8Settings+3286)
#19 pc 000000000055a1d1 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (main+2532)
#20 pc 000000000061a79b /data/app/net.minetest.minetest-1/lib/arm/libminetest.so (android_main+134)
#21 pc 0000000000b997e3 /data/app/net.minetest.minetest-1/lib/arm/libminetest.so
#22 pc 0000000000016f23 /system/lib/libc.so (_ZL15__pthread_startPv+30)
#23 pc 0000000000014f43 /system/lib/libc.so (__start_thread+6)
We also get this on some phones
FATAL EXCEPTION: main
Process: net.minetest.minetest, PID: 17266
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "stderr" referenced by "libgmp.so"...
at java.lang.Runtime.loadLibrary(Runtime.java:383)
at java.lang.System.loadLibrary(System.java:998)
at net.minetest.minetest.MtNativeActivity.<clinit>(MtNativeActivity.java:88)
at java.lang.reflect.Constructor.newInstance(Native Method)
at java.lang.Class.newInstance(Class.java:1572)
at android.app.Instrumentation.newActivity(Instrumentation.java:1068)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2303)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2466)
at android.app.ActivityThread.access$1200(ActivityThread.java:152)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1341)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5538)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:960)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
I'm not sure if we can move it to another account
We can
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "stderr" referenced by "libgmp.so"...
We can disable libgmp for Android, in MC i remove this lib and had no difficulties, no usage scenarios, when it is really needed.
I can confirm that this issue still exists in nerzhul's
0.4.17.1-3.apk.
I tried out stujones' unofficial APK, and can confirm that this issue is fixed in 5.0.0-dev. I tried both singleplayer and multiplayer just to be sure.
I tried out stujones' unofficial APK, and can confirm that this issue is fixed in 5.0.0-dev. I tried both singleplayer and multiplayer just to be sure
This will be because stujones1 is building it properly, the problem is from how it is built not the code
I build it properly too... i will provide a 5.0.0-dev APK asap and you will see if that works properly :)
This APK: https://github.com/minetest/minetest/releases/download/0.4.17.1/Minetest-0.4.17.3.apk fixed this problem for me (I was hit by this issue before).
While I'm here: I've set up another automatically updated mirror of the Irrlicht SVN repo (updated daily) here: https://gitlab.com/pgimeno/irrlicht-mirror
I can confirm. The latest APK (0.4.17.1-3 I assume - the versioning is getting really confusing :P) fixes the GL_INVALD_ENUM error for me as well. Thanks a ton. :)
Most helpful comment
@stujones11 ok i'm incompetent, nice