Compiling on ARM 64bit

[sagitter]

Hi all.

I'm building Pioneer on ARM-64bit architectures for Fedora. The release 20160907 is successfully compiled: log / list software used

Latest release 20161022 is failing on ARM64 but i can't recognize the reason. Can you take a look please? Build log Dependencies log

Thanks.

[impaktor]

Because we don't currently support ARM, as far as I know: http://pioneerspacesim.net/forum/viewtopic.php?f=3&t=242

[sagitter]

So, if Pioneer compiled fine in ARM doesn't mean that it works?

[impaktor]

Well, we have also gotten it to compile on ARM, but not to run.

[ecraven]

@sagitter what device are you building it on? it might be interesting to build it on a raspberry pi 3 :)

[sagitter]

@ecraven

I have not a device; the packages are built on a ARM buildroot: http://koji.fedoraproject.org/koji/buildinfo?buildID=812266

On Fedora 26, ARM32 and ARM64: http://koji.fedoraproject.org/koji/buildinfo?buildID=809805

[sagitter]

@impaktor

Well, we have also gotten it to compile on ARM, but not to run.

At this point i need to know which ones architectures are good for Pioneer, please. Among:

ARM, no. PowerPC ? s390 ?

[fluffyfreak]

Pioneer builds, and runs, on:

• x86 - win32
• x86/x86_64 - linux
• x86/x86_64 - OSX

Nothing else.

I have gotten it to compile on the Raspberry Pi 3 however the renderer requires at least OpenGL 3.1 and not one of the mobile subsets like OpenGL ES 2.0 / 3.0 and I don't know of any ARM board that has access to that.

[senderghost]

Latest release 20161022 is failing on ARM64 but i can't recognize the reason. Can you take a look please? Build log

I guess, this is related to following sed patch for libprofiler.a: sed -e '/libjson.a/s| \\|| ; /libprofiler.a/d' -i.p.bak src/Makefile.am

This is because of "../contrib/imgui/libimgui.a" addition to src/Makefile.am in 20161022 release. Try to change sed patch to follows: sed -e '/libprofiler.a/d; $$!N; /libprofiler.a$$/s| \\||; P; D' -i.p.bak src/Makefile.am or (if not required to escape the "$" character for pioneer.spec): sed -e '/libprofiler.a/d; $!N; /libprofiler.a$/s| \\||; P; D' -i.p.bak src/Makefile.am

The idea is to remove " \" for previous line, if line with "libprofiler.a" ends without " \" in it. Based on some example from "Useful one-line scripts for sed".

[senderghost]

To @fluffyfreak: The mentioned sed patch also used for games/pioneer FreeBSD port, because of ARM related issues for contrib/profiler/Profiler.cpp, which depends on x86 assembly. See comment 4 for PR 207559 on FreeBSD Bugzilla for details.

[fluffyfreak]

Sometimes I'm baffled by the open source community. I mean why is there an entire thread talking about how to fix a problem with our builds and code but with no-one mentioning it to us until now?

I did the std::chrono stuff but must have missed some. I wonder how it ever worked on the RPi3?

The answer isn't a sed patch for the build system it's to fix the code.

None of which is of any help since Pioneer does not support running on ANY ARM system since none of them support the required renderer.

[fluffyfreak]

I think the only two sane options here are:

• A) Remove Pioneer from your ARM 32/64 bit builds.
• B) Fix the code so that it works using the std::chrono code path.

Really though A is the only logical option since once you've gotten Pioneer to compile it won't actually run or do anything. At best it will crash or exit during loading due to not being able to create the renderer.

[senderghost]

None of which is of any help since Pioneer does not support running on ANY ARM system since none of them support the required renderer.

I may agree that it may doesn't work, if no required hardware support, but there is a different situation about the builds on supported architectures, where ARM included for Fedora Linux and FreeBSD. This is why it was fixed this way (with using patches to remove contrib/profiler and related files from build) for specific cases.

Sometimes I'm baffled by the open source community. I mean why is there an entire thread talking about how to fix a problem with our builds and code but with no-one mentioning it to us until now? ... B) Fix the code so that it works using the std::chrono code path.

I don't have access to ARM builds on FreeBSD to fix this another way or report it as an issue here.

I just proposed how to fix the build on ARM for current pioneer.spec on Fedora Linux.

[fluffyfreak]

Ok I'm going to make a note of some things to look at when I'm not at work later: http://pkgs.fedoraproject.org/cgit/rpms/pioneer.git/tree/pioneer.spec?id=3ff183ff86727d1d8284e94ed7212695de03a6fb#n135 https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/Makefile#L89 https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/files/patch-contrib_PicoDDS_PicoDDS.cpp https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/files/patch-src_GameConfig.h

Some/all of which might be worth back-porting to Pioneer, depending on what people think.

Also I should have a patch for the ARM thing later today now that I know about it.

[senderghost]

https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/Makefile#L89 https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/files/patch-contrib_PicoDDS_PicoDDS.cpp https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/files/patch-src_GameConfig.h

The mentioned patches are not related to ARM builds, but some compilers and include files on FreeBSD operating system (for different versions). I think, there is a need to post what error messages they fixed, which requires some time to reproduce.

[sagitter]

@senderghost Thanks for the patch, again.

[laarmen]

The thing is, as logn as we don't have anybody working on an OpenGL ES renderer (and I'm not volunteering), I don't think you should bother with the ARM builds. And by "you" I mean both @fluffyfreak and the nice packager.

On Tue, Oct 25, 2016 at 11:46 AM Andrew Copland notifications@github.com wrote:

Ok I'm going to make a note of some things to look at when I'm not at work later:

http://pkgs.fedoraproject.org/cgit/rpms/pioneer.git/tree/pioneer.spec?id=3ff183ff86727d1d8284e94ed7212695de03a6fb#n135

https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/Makefile#L89

https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/files/patch-contrib_PicoDDS_PicoDDS.cpp

https://github.com/freebsd/freebsd-ports/blob/master/games/pioneer/files/patch-src_GameConfig.h

Some/all of which might be worth back-porting to Pioneer, depending on what people think.

Also I should have a patch for the ARM thing later today now that I know about it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pioneerspacesim/pioneer/issues/3846#issuecomment-255988700, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkONTfkeUKn6-34QdNVO8SaeMwKnJOdks5q3c_-gaJpZM4KfEoZ .

[senderghost]

There is a Dummy Renderer, just in case.

The possible approach is to create dynamic rules for building of contrib/profiler files (i.e. Profiler.cpp, libprofiler.a), based on "--enable-profiler" configure option (which is disabled by default):

./configure --help | grep enable-profiler
  --enable-profiler       Enable internal profiler

Then this may be isolated to contrib/profiler/Profiler.h case, related to correct defines for supported architectures (as it was for aarch64 on Fedora Linux).

The mentioned sed patches does exactly this.

Otherwise, this issue is already fixed (for reporter). There are many ARM boards and hard to determine what may have support or not, in my opinion. There is a WIP for OpenGL 2.1 renderer, but may be unrelated.

[laarmen]

To be fair, it isn't a behaviour specific to open source. It's just that you would only notice it in the FOSS context because the side channel isn't behind closed doors.

On Tue, Oct 25, 2016 at 10:27 AM Andrew Copland notifications@github.com wrote:

Sometimes I'm baffled by the open source community. I mean why is there an entire thread talking about how to fix a problem with our builds and code but with no-one mentioning it to us until now?

I did the std::chrono stuff but must have missed some. I wonder how it ever worked on thue RPi3?

The answer isn't a sed patch for the build system it's to fix the code.

None of which is of any help since Pioneer does not support running on ANY ARM system since none of them support the required renderer.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pioneerspacesim/pioneer/issues/3846#issuecomment-255970559, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkONS-0Y_HUKwGodNOYxCQnMjlBBVRZks5q3b1cgaJpZM4KfEoZ .

[senderghost]

To @fluffyfreak: Perhaps, this issue is not right place to discuss about mentioned patches, but since you noted about them here.

Some descriptions: 84amd64: FreeBSD 8.4 amd64, GNU/GCC 4.8.2 with GCC 4.2 includes in base (which is EOL currently). 93amd64: FreeBSD 9.3 amd64, GNU/GCC 4.8.5 (with possible EOL on December 31, 2016). 102amd64: FreeBSD 10.2 amd64, LLVM/Clang 3.4.1 (with possible EOL on December 31, 2016).

1) https://github.com/freebsd/freebsd-ports/blob/f81a8530f4df1040b94dcac6c466b8a1202a1dfb/games/pioneer/files/patch-src_GameConfig.h 84amd64: this was proposed in PR 193213. 93amd64: ok. 102amd64: ok.

2) https://github.com/freebsd/freebsd-ports/blob/f81a8530f4df1040b94dcac6c466b8a1202a1dfb/games/pioneer/files/patch-contrib_PicoDDS_PicoDDS.cpp 93amd64: ok. 102amd64: with error message:

PicoDDS.cpp:423:23: error: use of undeclared identifier 'malloc'; did you mean 'valloc'?
        char* pData = (char*)malloc(sizeof(char)*size);
                             ^~~~~~
                             valloc
/usr/include/unistd.h:583:7: note: 'valloc' declared here
void    *valloc(size_t);                        /* obsoleted by malloc() */
         ^
PicoDDS.cpp:430:3: error: use of undeclared identifier 'free'
                free(pData);
                ^
2 errors generated.

this was proposed in PR 193213.

3) https://github.com/freebsd/freebsd-ports/blob/ad301a025fc7d38f935abc6b8068a182ebedc276/games/pioneer/Makefile#L89 or sed -e 's/std:://g' src/Orbit.cpp or

--- src/Orbit.cpp.orig
+++ src/Orbit.cpp
@@ -145,7 +145,7 @@ double Orbit::OrbitalTimeAtPos(const vec
    vector3d approx3dPos = (matrixInv * pos - vector3d(c, 0., 0.)).Normalized();

    double cos_v = -vector3d(1., 0., 0.).Dot(approx3dPos);
-   double sin_v = std::copysign(vector3d(1., 0., 0.).Cross(approx3dPos).Length(), approx3dPos.y);
+   double sin_v = copysign(vector3d(1., 0., 0.).Cross(approx3dPos).Length(), approx3dPos.y);

    double cos_E = (cos_v + m_eccentricity) / (1. + m_eccentricity * cos_v);
    double E;
@@ -159,7 +159,7 @@ double Orbit::OrbitalTimeAtPos(const vec
    }
    else
    {
-       E = std::acosh(cos_E);
+       E = acosh(cos_E);
        if(sin_v < 0)
            E *= -1.;
        meanAnomaly = E - m_eccentricity * std::sinh(E);

93amd64: with error message:

Orbit.cpp: In member function 'double Orbit::OrbitalTimeAtPos(const vector3d&, double) const':
Orbit.cpp:148:17: error: 'copysign' is not a member of 'std'
  double sin_v = std::copysign(vector3d(1., 0., 0.).Cross(approx3dPos).Length(), approx3dPos.y);
                 ^
Orbit.cpp:148:17: note: suggested alternative:
In file included from /usr/local/include/SDL2/SDL_stdinc.h:81:0,
                 from /usr/local/include/SDL2/SDL_main.h:25,
                 from /usr/local/include/SDL2/SDL.h:32,
                 from libs.h:12,
                 from Orbit.h:7,
                 from Orbit.cpp:4:
/usr/include/math.h:268:8: note:   'copysign'
 double copysign(double, double) __pure2;
        ^
Orbit.cpp:162:7: error: 'acosh' is not a member of 'std'
   E = std::acosh(cos_E);
       ^
Orbit.cpp:162:7: note: suggested alternative:
In file included from /usr/local/include/SDL2/SDL_stdinc.h:81:0,
                 from /usr/local/include/SDL2/SDL_main.h:25,
                 from /usr/local/include/SDL2/SDL.h:32,
                 from libs.h:12,
                 from Orbit.h:7,
                 from Orbit.cpp:4:
/usr/include/math.h:222:8: note:   'acosh'
 double acosh(double);
        ^
  CXX      Pi.o

this was proposed in PR 203427. 102amd64: ok.

4.1) sed -e 's/std::to_string/to_string/g' src/graphics/opengl/GenGasGiantColourMaterial.cpp or

--- src/graphics/opengl/GenGasGiantColourMaterial.cpp.orig
+++ src/graphics/opengl/GenGasGiantColourMaterial.cpp
@@ -48,7 +48,7 @@
    }
    // extract the top 16-bits to get how many octaves we can use
    const Uint32 octaves = (desc.quality & 0xFFFF0000) >> 16;
-   ss << "#define FBM_OCTAVES " << std::to_string(octaves) << std::endl;
+   ss << "#define FBM_OCTAVES " << to_string(octaves) << std::endl;

    // No lights
    ss << "#define NUM_LIGHTS 0\n";

93amd64: with error message:

GenGasGiantColourMaterial.cpp: In constructor 'Graphics::OGL::GenGasGiantColourProgram::GenGasGiantColourProgram(const Graphics::MaterialDescriptor&)':
GenGasGiantColourMaterial.cpp:51:34: error: 'to_string' is not a member of 'std'
  ss << "#define FBM_OCTAVES " << std::to_string(octaves) << std::endl;
                                  ^
GenGasGiantColourMaterial.cpp:51:34: note: suggested alternative:
In file included from GenGasGiantColourMaterial.cpp:9:0:
./../../StringF.h:145:20: note:   'to_string'
 inline std::string to_string(const T& value) {
                    ^

was found while testing 20161022 release on FreeBSD 9.3 amd64. 102amd64: ok.

4.2) https://github.com/freebsd/freebsd-ports/blob/ad301a025fc7d38f935abc6b8068a182ebedc276/games/pioneer/Makefile#L91 or sed -e 's/std::to_string/to_string/g' src/graphics/opengl/RendererGL.cpp or

--- src/graphics/opengl/RendererGL.cpp.orig
+++ src/graphics/opengl/RendererGL.cpp
@@ -317,7 +317,7 @@ void RendererOGL::CheckErrors(const char
        // now build info string
        std::stringstream ss;
        if(func) {
-           ss << "In function " << std::string(func) << "\nOn line " << std::to_string(line) << "\n";
+           ss << "In function " << std::string(func) << "\nOn line " << to_string(line) << "\n";
        }
        ss << "OpenGL error(s) during frame:\n";
        while (err != GL_NO_ERROR) {

93amd64: with error message:

RendererGL.cpp: In static member function 'static void Graphics::RendererOGL::CheckErrors(const char*, int)':
RendererGL.cpp:320:65: error: 'to_string' is not a member of 'std'
    ss << "In function " << std::string(func) << "\nOn line " << std::to_string(line) << "\n";
                                                                 ^
RendererGL.cpp:320:65: note: suggested alternative:
In file included from RendererGL.cpp:9:0:
./../../StringF.h:145:20: note:   'to_string'
 inline std::string to_string(const T& value) {
                    ^

this was proposed in PR 209357. 102amd64: ok.

[impaktor]

Non-native speakers might not be familiar with the meaning of the seldom used word "moot". I recommend looking it up, since this whole issue is the very definition of a moot point, as far as I can tell.

EDIT: I called this "issue" a *pull request".

[senderghost]

To @impaktor: If you meant about mentioned patches, then there is a possibility, that they are FreeBSD specific (because of different compilers and include files used). This is why I wrote about related error messages. No need to apply them blindly.

If you meant about sed patches for contrib/profiler, then they may be considered as intermediate solution (and not what proposed to apply by upstream), independent from definition of "moot", because building (i.e. what issue about) and running (i.e. what other people talking) are different things.

[impaktor]

@senderghost No, I mean about this issue. Sorry I posted it at 5 am this morning, and wrote "pull request" when I meant "issue".

What I mean, (I thought it was obvious): why the heck do we have an issue like this, and a long discussion on how to get it compiling on ARM, when ARM is not supported in any way and it doesn't run on ARM. It's like opening an issue about Pioneer not compiling on Commodore 64.

If someone volunteers to implement a renderer for ARM, then it would be another thing, but that's a big undertaking.

[senderghost]

To @impaktor: The reason of this issue is broken sed patches (which I proposed to @sagitter some months ago) for ARM architecture on Fedora Linux. The error message didn't say about this, so he asked about this here, as I understood.

The issue about running pioneer on ARM was already raised on related PR 207559 with words: "The pioneer application may require OpenGL 3.x graphics support". So, personally, I'm well aware about this.

[impaktor]

So this issue, with title: "Compiling on ARM 64 bit", is not about compiling on ARM, but a general question about how to build pioneer on Fedora, for the supported architectures, i.e. not ARM? If so, then the titile should be changed.

[senderghost]

To @impaktor: The title of this issue may be correct (but specific in current contents). Without sed patches you may get concrete error message(s) from compiler, related to x86 assembly used in contrib/profiler/Profiler.cpp. The internal profiler is not required to build/run pioneer application (without "--enable-profiler" configure option, where most profiler defines are empty). Since this issue was tried to be fixed on fffd081f567313687b1fbff6b2d60295308b5bbe, it may be legit to discuss. The "Running on ARM" is different topic, in my opinion, while you can't "run" it, if it wasn't built.

[sagitter]

So this issue, with title: "Compiling on ARM 64 bit", is not about compiling on ARM, but a general question about how to build pioneer on Fedora, for the supported architectures, i.e. not ARM? If so, then the titile should be changed.

No; i didn't know why suddenly Pioneer was not built anymore just on ARM buildroots; and i did not even know that Pioneer can't run on no-x86/x86_64 machines otherwise i would built it on x86/x86_64 exclusively from the beginning. Even if i build a package on different architectures does not mean that i have physically all related hardware, the final users or upstream developers are precious to define if a software works fine or not with a specific hardware.

Having said that i guess i can stop building Pioneer on no-x86/x86_64 architectures by now.

[fluffyfreak]

Closing issue as we don't support non-x86/x86_64 platforms yet.

[senderghost]

To @sagitter: Could you please check following patch, instead of mentioned sed patches:

--- contrib/profiler/Profiler.h.orig
+++ contrib/profiler/Profiler.h
@@ -151,6 +151,7 @@ namespace Profiler {
            calls += b.calls;
        }

+   #ifdef __PROFILER_ENABLED__
    #if !defined(USE_CHRONO)
        #if defined(__GNUC__)
            static inline u64 getticks() {
@@ -166,6 +167,9 @@ namespace Profiler {
    #else
        static inline u64 getticks() { return std::chrono::high_resolution_clock::now().time_since_epoch().count(); }
    #endif
+   #else
+       static inline u64 getticks() { return 0; }
+   #endif

        u64 ticks, started;
        u32 calls;
--- contrib/profiler/Profiler.cpp.orig
+++ contrib/profiler/Profiler.cpp
@@ -1,5 +1,7 @@
+#ifdef PIONEER_PROFILER
 #define __PROFILER_SMP__
 #define __PROFILER_CONSOLIDATE_THREADS__
+#endif

 #define css_outline_color "#848484"
 #define css_thread_style "background-color:#EEEEEE;margin-top:8px;"

This may disable x86 assembly, which is not used, if internal profiler disabled by default.

[sagitter]

Could you please check following patch

Does not work with the release 20161022, patching fails: https://kojipkgs.fedoraproject.org//work/tasks/6300/16206300/build.log

[senderghost]

Does not work with the release 20161022, patching fails

Looks like, this is because of spaces instead of tabs used in GitHub comments. I sent you original patches by email. Probably, better to check ba3d38b61df4e2dcea5e7cc16b10d8a81e7e3620 instead.

[sagitter]

Commit 069a6c91d6e1cec1d98efbf3bd76a0b011edda4e built on Fedora 24: http://koji.fedoraproject.org/koji/taskinfo?taskID=16209275

Do you need an ARM64 build?

[laarmen]

Not really. We wouldn't be able to run it anyway.

On Wed, Oct 26, 2016 at 5:50 PM Antonio notifications@github.com wrote:

Commit 069a6c9 https://github.com/pioneerspacesim/pioneer/commit/069a6c91d6e1cec1d98efbf3bd76a0b011edda4e built on Fedora 24: http://koji.fedoraproject.org/koji/taskinfo?taskID=16209275

Do you need an ARM64 build?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/pioneerspacesim/pioneer/issues/3846#issuecomment-256391616, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkONY2ZTq8m1ChtGNlIgvzCy8PJtITUks5q33a1gaJpZM4KfEoZ .

[senderghost]

Commit 069a6c9 built on Fedora 24: http://koji.fedoraproject.org/koji/taskinfo?taskID=16209275

Ok, thanks.

Do you need an ARM64 build?

I just asked about some building checks for ARM, which fixes this issue. The build log shows, that it builds on armv7hl. I guess, the check for aarch64 will do the same for ARM64.

[impaktor]

OK, so it builds on ARM. Now what?

If anyone is trying to provide it as a package (e.g. Fedora-ARM) -- without pioneer actually working -- then I'm very strongly against this. People would see the package and go "oh, cool, I'd like to run that", install it, and then it wouldn't run.

Enter frustration, and disappointment: some would say "wow, what a crock of shit Pioneer is, doesn't even run, incompetent bastards", and give up. This would reflect very poorly on us who work on Pioneer. Others would start to read FAQ, wiki, post on SSC, dev-forum, or on the issue tracker "Pioneer crashes on Fedora".

(yes, I know some distributions wouldn't allow non-functioning packages, while others would, e.g. Arch Linux User repository, I suspect; and others)

[impaktor]

If anyone is trying to provide it as a package (e.g. Fedora-ARM) -- without pioneer actually working -- then I'm very strongly against this.

Clarification: with "this" I mean "binary build", (sorry if that was unclear).

OK, I've read the 2 page monologue that @senderghost just wrote to me on IRC, before he logged out, so I'm answering here, after having re-read everything in this thread.

<Sender> Looks like, you was unhappy to discover, that
         cross-platform project, such as pioneer, also works on other
         operating systems (e.g. FreeBSD) ...

I would greatly appreciate it if you didn't make false assumptions of what I mean (at no point have I objected to any *BSD); please refrain from this kind of straw man argument.

         ... and even build on different architectures (ARM, may
         be PowerPC, etc., where working C++ compiler).

No, but I don't want to provide a build of Pioneer on a platform where it doesn't work, for reasons I described in my last post.

<Sender> From this point of view, actual developers are aware for what it was for.
         Moreover, the pull 3847 wasn't required before, when contrib/profiler
         was removed from the build by other methods. While you still build it
         for Travis purpose, may be. From this point of view, this is
         artificial problem created by actual developers. Try harder next
         time, may be.

Sounds like I'm not an "actual developer"? It is true I have not read the patches in this PR, that is exactly why I have asked, right here in this thread, if the title of this issue aught to be changed, and what we're actually discussing. I interpreted the answer as "yes, we are discussing building Pioneer on ARM". Even a question has been raised here in this thread, about providing pioneer builds on ARM (e.g. "Do you need an ARM64 build?"). What I wrote in my post above condenses down to "please don't provide non-working builds of Pioneer, it makes us look bad".

And I thought the discussion in this thread was strange as we're basically talking about how to provide non-working ARM builds of Pioneer.

@sagitter Apologies if any of my posts were short, as in lacking in usual courtesy phrases, I usually write those, but was/am tired. Reading them, I see I can be interpreted as grumpy, which I didn't mean to be, (except this post). Anyway, thanks for reporting, I know you have no way of knowing we don't support ARM (or that I'm usually less grumpy), and we're usually less scary than in this thread.

[senderghost]

OK, so it builds on ARM. Now what?

Now, try to understand what was a cause of this issue. The cause was a contrib/profiler source code, which contains x86 assembly. This is "artificial" issue, because pioneer application doesn't require to build internal profiler by default (without "--enable-profiler" configure option). Therefore, this is not an ARM issue, but contrib/profiler related and how it builds for pioneer application (even if not required, but possible for Travis builds usage). You may check this with following (sed) patches (as shell script):

#!/bin/sh

sed -e '/^SUBDIRS/s/ profiler//' -i.bak contrib/Makefile.am
sed -e '/libprofiler.a/d; $!N; /libprofiler.a$/s| \\||; P; D' -i.bak src/Makefile.am
sed -e '/contrib\/profiler/d' -i.bak configure.ac

To @impaktor: What you said above is also applicable for *BSD, Linux, Mac OS X, Windows, etc., where pioneer application may have concrete hardware requirements to run, but crashes, requires more (GPU) memory, concrete OpenGL version support, etc.

"Do you need an ARM64 build?"

This question was related to me, paraphrasing: "Do you need to check 069a6c91d6e1cec1d98efbf3bd76a0b011edda4e commit for ARM64 build also?". It wasn't: "Do you need compiled package for ARM64 to check how it runs on ARM hardware?". This is complete misunderstanding, in my opinion.

As I understood, the pioneer is cross-platform application. There is a need for working C/C++ compiler and available dependencies to build.

On the other hand, @fluffyfreak was interested to build pioneer application for ARM in fffd081f567313687b1fbff6b2d60295308b5bbe commit. The discussion provided some information how to (additionally) fix this issue in pull #3847.

To @impaktor: It wasn't very kind to use some words from IRC, without actual context (especially on public). I suggested to do not make this personal (also on IRC).

[sagitter]

@impaktor

Based on that i learn by this thread, i'm not building/providing anymore Pioneer on non-x86_x86_64 architectures with Fedora. Please, let us know (as external packagers) if something changes by this point of view.

[sagitter]

"Do you need an ARM64 build?"

This question was related to me, paraphrasing: "Do you need to check 069a6c9 commit for ARM64 build also?". It wasn't: "Do you need compiled package for ARM64 to check how it runs on ARM hardware?". This is complete misunderstanding, in my opinion.

Yes, probably part of this thread borns by misundestandings caused by my "unusual" English. :-1:

[laarmen]

Allright, that's enough. This is annoying me enough that I will use the heaviest weapon in my arsenal: CAPS!

As far as I know, our position on ARM is the following: we don't support it at all, although we would like to. As such, we welcome any advancement on the issue, such as build patches. HOWEVER, as long as nobody provides a renderer, it is a VERY BAD IDEA to distribute any binary on that platform, since it will crash. No "if" about it, we know that for a fact. We're already sufficiently profficient at crashing the game on platforms who could potentially run the game, let's not add to that.

This has nothing to do with *BSDs, Linux distros, Windows, NeXT, AmigaOS, Android, that old punchcard reader in your attic. ARM platform simply doesn't provide OpenGL rendering (as far as I know. And no, pure software rendering doesn't really count).

As far as "not making things personal" go, I'd say that prefixing a discourse on IRC with someone's nickname is not really the way to go. But what do I know?

So, in the interest of peace, prosperity, and my inbox's sanity, and since I consider all technical points have been addressed, I'm shutting down this thread.

[fluffyfreak]

Thankyou @sagitter that addresses our worries which @impaktor is trying to express.

It's nice that Pioneer compiles and links on non-x86 architectures but it does not run. We simply do not want to mislead people into thinking that they can download Pioneer and it will work on ARM/PPC/etc platforms.

We are a small volunteer team and do not have the resources, experience or equipment to handle other platforms at the moment.