Closed notsilverhoft closed 1 week ago
To me, c2man is also a pain in the ass while building.
I will check this later, please stick to docker at this moment, since that is a reliable way to freeze the state of all those dependencies.
And the dev tools should be installed by these lines:
https://github.com/VitoVan/pango-cairo-wasm/blob/main/build.sh#L9-L29
To me, c2man is also a pain in the ass while building.
I will check this later, please stick to docker at this moment, since that is a reliable way to freeze the state of all those dependencies.
Ok, referencing the c2man issue, is it possible to rewrite Fribidi to ignore c2man, it seems kinda useless unless people really care about the Fribidi documentation I'm not sure why the actual build is so reliant on it.
is it possible to rewrite Fribidi to ignore c2man
It is possible, but I tried and gave up that idea, because it seems more clumsy than just build the damn c2man.
So, maybe you could find a way to build it once in Fedora, take the whole thing, and drop it in the project. The question is, why can't c2man see GCC on Fedora? And why isn't there any documentation on it? This thing was built to be a pain in the ass.
I'm curious if I just made a fork, I did build c2man, maybe I just put it in Fribidi, and removed the c2man build line in the build.sh, it would just go with it.
@VitoVan Issue was solved with #4 . This should work for Docker, I was also able to build Pango, I think Debian is just screwed.
I have tried to build on Fedora with and without docker, on Debian with and without docker, and on Codespaces with and without docker. When building with an edited build.sh file on Codespaces and Debian, I was able to build Fribidi with no issues, but Pango would always fail, the problem seemed to be with the cpu section of the meson crossfile, from memory, I believe it said something to the effect of "host 'emscripten', and host cpu type 'wasm32' are not supported". I know for sure that's not exactly what it said, and I no longer have the edited file, I may have logs but I'm not sure. I became frustrated, as I had edited everything I could, and I still had no luck, so I took some time to think. I thought maybe the issue was just the fact that I had been using the wrong distribution. I used VirtualBox to try and build from Fedora, and with some editing I came across the exact same issue. So I finally went to docker. I was already in the Fedora virtual machine, and I attempted to build from Docker. I was not even able to reach Pango, because Fribidi had failed building:
I noted that c2man was missing, so I searched the log for where the issue was, and there was an error in building c2man. So I tried to build it by itself, and it wasn't able to find the C compiler in Fedora. I tried making a fork of this repository, and updating the submodule, to see if it was a version issue, to no avail. So I am thinking the issue is with finding the C compilers on Fedora, I installed all of them just in case(Bison, Flex GCC, etc.), and tried to direct the install script to the exact path of the C compilers, including EMCC. I then tried it on my Linux Mint computer, and with some trial and error I was able to get c2man to install. So c2man installs on Debian distros, and has problems with Fedora, this would explain why I was able to get to Pango earlier. This made me wonder if it was just a question of file structure, and the locations of programs in Gedora, so I tried to build with docker in my Codespace, also based on Debian, and still received the same error. I then tried installing c2man individually and succeeded. It's possible it wont build because the docker image is Fedora, and the C compilers in Fedora just don't work, but I'm not sure. The only reason I came here was because I couldn't get Pango to build with WASM, and I have a project that requires both Pango and Cairo, to build with EMscripten. It does work with build.sh in Debian, but I still run into the Pango error, should I stick to docker, and solve this, or go back to native Debian, and open a new issue?
Thanks for reading.