Failed to build on Manjaro #1477
Comments
|
you need nasm, or a assembler compatible with its output |
|
I already have nasm installed, it was on the list of dependencies tho doxygen was missing so whats the problem then? |
|
Its either not correctly set up or not on your path or something else that is keeping cmake from being able to call it, its hard to tell and you would probably know the best how your system works since its gentoo so its kinda hard to give advice much Edit: don't know why I thought you were running gentoo, don't issue when you just woke up lol, but googling around for issues relating to this is still probably your best bet |
|
Haha have your coffee first :P |
|
I will double check but I am pretty sure I installed nasm but I am not sure if I know how to resolve this myself, tho you guys should be able to help. I just want to help report the issue. I compiled it on Arm64 Manjaro but got a different error |
|
Only x86 is supported, so building on ARM wont work. (unless you're cross compiling for x86 I guess) |
|
Yeah that's fair enough, I just wanted to test but will it support Arm64 later on?
Back to the issue tho do you have any idea what's happening with the |
|
Probably |
Requires that someone writes an ARM backend for the goal compiler. |
|
you could set |
|
Oh ok how do I do that? In cmakecache I do see |
|
did a cmake clean and tried again and got this error instead |
|
the error happened earlier - the |
|
Sure |
|
You should be able to add |
|
Yep can confirm that allowed it to compile Did the test and it passed So where is the binary and extractor binary? |
They should be in the |
|
Will this patch be added to the code? |
|
Having the same build issue on Arch32 |
|
The project is x86_64 only. |
|
Oh so it doesn't support 32bit x86 either? but why doesn't it support 32bit x86? |
|
Because we make use of 64-bit registers, instructions and and addressing space. |
|
Ah I see, I know I have already sort of asked but like other projects like RE3 or Devilutionx which can compile for multiple architectures with no issues, will this project ever get that kind of code changes to do that later on? |
|
If someone else wants to do it, sure. But we're not planning on it. |
|
Ok thanks for the update |
|
The fix to the lzokay library has been merged into master #1530 So the actual underlying build issue appears to be resolved #1477 (comment) Closing as there doesn't seem to be an outstanding issue here anymore? Feel free to re-open if im mistaken. |
Are you guys using assembly? shouldn't the OS manage the pointers, memory spaces and registers? |
|
This question keeps coming up so I'll give a real answer for why it's not easy for this project to support other architectures.
|
|
Wait so why did you write your own compiler instead of using a mature compile like GCC? you've made it harder for yourself and unlike your compiler you have made GCC is modular. This would allow you to easily port it to different architectures with far less work as it's already done in GCC |
|
As someone who is a software engineer for a living this is just stupid, a word of advice is restandardize on GCC or something that is mature. |
|
The game is written in GOAL, which is a custom programming language developed by naughty dog and not supported by gcc or clang or any existing compiler. Did you even look at the code or read the first sentences of the readme? It's all a custom lisp language and the point of the project was to port this custom language to x86. |
|
We're just figuring out how it all works and just asking questions on how it all works to get a better understanding. Would it have to use this custom language to work? Just sounds like more work to use a old non standard compiler |
|
Sorry if I misunderstood something, I’m getting this secondhand from @coreybruce. But can’t this be reimplement in something like c++, I’m looking for answers mostly I’m not here to troll |
|
The point of the project is to port Naughty Dog's custom language to x86, not to port the game's codebase to C++. |
|
Yeah @Biggamer11 has a lot more skills when it comes to this but I am also just wanting to help and ask questions as this is a awesome project and wish to help improve anyways I can :) |
|
What about transpiler to convert it to code to something intermediate to be compiled on gcc that way you could possibly have something that can use the custom language and have portablity |
|
Understandable, but please take a few moments to read some code or the readme first. There's 400,000 lines of this type of code in jak 1, and we think that jak 2 will be about 1 million lines. Porting it to C++ is not very easy because there are a ton of weird features in their language that C++ doesn't support. It is, of course, technically possible to reimplement all their stuff in C++ but we'd have to rework a lot of the engine to actually be possible in C++. I decided not to try porting it to C++ because:
|
|
What features in C++ would you need exactly? |
|
On the topic of using an IR / transpiler (like LLVM). This question has been asked before a few times, here was the response that is hopefully informative:
|
|
I'm passionate about this game and I apologize if it comes across as confrontational. It wasn’t my intention. Best of luck to your project and wish it success. |
|
GOAL's weird features that don't map well to c++ are:
some of these could be solved with clever c++, but these aren't the sort of problems I'm interested in solving. In the end our objective isn't to make jak and daxter playable on as many computers as possible - it's more about the tools they used to develop the game. |
no worries - we're aware that our approach isn't the best for everyone's use case, but it's a tradeoff that we're happy with. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi I just wanted to get some help compiling this on Manjaro also you were missing the dependency doxygen in the Arch dependencies mentioned.
Here is my log also
Is there anything else missing?
The text was updated successfully, but these errors were encountered: