AFAIK SIGPROF is not defined in either Linux(5.15) or Windows (VS2022, Windows 11 SDK) nor is the alarm signals Unless they are hidden somewhere obscure. So you should probably check if Qt themselves defines them in some header somewhere.
I think my strategy so far is to turn off the flags leading to the crashpad (module responsible for crash reports). But it is nice to know, if I later need to turn it back on.
Noticed something in the qt code for 6.2, cygwin does not really support any of the posix signals either (no SIGPROF etc.) so one idea might be to look around for cygwin, android, and see if they make any workarounds. And you might want to compile STLPort with the extra C support library, which is meant to increase compatability to both C++ and ISO-C (posix), it contains lots of goodies (both thread, memory and (AFAIR) signals etc.) It was quite a few years ago I had to compile STLPort.
Guys... I have come uppon this problem. It might be a killer. Please consult and confirm :
Quote:
In file included from ../../../../../src/3rdparty/chromium/v8/src/codegen/callable.h:8, from ../../../../../src/3rdparty/chromium/v8/src/codegen/code-factory.h:8, from ./../../../../../src/3rdparty/chromium/v8/src/codegen/code-factory.cc:5, from gen/v8/v8_base_without_compiler_jumbo_6.cc:9: ../../../../../src/3rdparty/chromium/v8/src/codegen/interface-descriptors.h:475:18: error: expected identifier before ‘,’ token 475 | ##__VA_ARGS__, \ | ^
There is some problem with gcc and what appears to be a builtin trick in the compiler : ##__VA_ARGS__
If this proves to be an incompatibility with the current selection of gcc toolchain options for OS 4.1, then I am not going to continue with the build. Sorry. This is too much already. We might as well build something from scratch, then.
Well, meanwhile you'll wait to have such an important answer, you could take a break from that monster and try to port a STL 3D model viewer based on QT: https://github.com/fstl-app/fstl
I'm not 100% positive but you may need to add -fPIC to your compiler invocation. The PIC stands for position independent code (PIC) and refers to the generated machine code which is memory address agnostic, i.e. does not make any assumptions about where it gets loaded into RAM. Sounds like you've mixed some relocatable object code with non-relocatable.
That is probably true. I can see, that -fPIC is used as flag in the build files, but unused for this build. I am aiming at a static build, so it is probably correct, that it is checked off. The assembly described here is autogenerated by some executable as part of the build. I am unsure, if I should go any more into it. I have replaced .quad by .long and hope, that it will not break too many things.
Guys... I need help. I have built the entire chrome source base necessary for creating libQt6WebEngineCore.a. But there is some problem with the build system. Instead of being 256 MB large, it only comes out 900 kb, so obviously something has been left out. I am looking at the build files and ... it is quite complicated, because it uses a combination of CMake and the google build tool 'gn'.
If someone has the time to look at the repos and just give some kind of preliminary evaluation of what could go wrong with such a build. I am hair-raisingly close to being, ehm, tired. It would be so good to at least have a complete build before taking a break.
EDIT : This file should be responsible for the coupling between the two build systems :
I Personally never used Ninja, I used Makefile for Linux and Windows, but 900 Kb vs 256 Mbyte? Have you done a check on what functions is compiled in? If it is .a link library use ar to see which objects are in there and roughly how big, then you get a indication what object probably failed. My gut feeling that all more or less as compiled but only as stubs more or less. to get more controll over cmake, download cmake-gui (it's a separate download).
At this point, I think it best to take a break from the webengine and do some tricks with the actual Qt codebase instead. I will be aiming for some kind of preliminary release and a stream event within the next few weeks. Stay put!
Yes. It is quite large, you know... And lot's of potential loose ends. Like big endian not being supported in the renderer and the v8 bytecode generator. But hey, if we just dive in, it might end up in our ball park...
Well, meanwhile you'll wait to have such an important answer, you could take a break from that monster and try to port a STL 3D model viewer based on QT:
This is interesting. I definetely want to work out some more of the 3D bindings offered by Qt. I am watching this at the moment :
Only caveat is that Qt really wants to use the EGL layering libraries. It is quite rudimentary what we have in os4 ogles2, and that means doing a lot of stuff by hand, that ends up being quite complicated and work consuming. That, and the fact, that there seems to be bugs preventing workability (see earlier posts regarding ogles2).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
It is highly appreciated.
