Build error: OwlShmBuffer.m: error: incompatible type for argument 2 of ‘CGContextDrawImage’
#13
Comments
|
Also fails with gcc14: |
|
The type should be |
|
Indeed, so that takes a |
|
The other thing about IOSurface is I never made a full EGL implementation based on it / |
On 10.5 there is also no
Unfortunately, no, I am not. @RJVB Tagging you re EGL. |
I had to drop most of libdispatch usage when making it build on GNU/Hurd anyway. What's left is some in |
|
BTW, a stupid question: how to pass two flags at a time? However I pass those to environment, only the first is actually used and another one discarded. |
|
Do you mean the flags for a C compiler? Just the following should work:
At which stage? Do you not end up with |
|
Thank you, I will try. By the way, I got this configure failure now: Configure uses Somehow configure does not like this ) |
|
Passing flags this way (via
It is not just |
|
On Wednesday November 27 2024 00:46:56 Sergey Fedorov wrote:
> The other thing about IOSurface is I never made a full EGL implementation based on it / `OwlIOSurfaceBuffer`; if you happen to be proficient in GL, it'd be great if you could work on that.
Unfortunately, no, I am not.
@RJVB Tagging you re EGL.
Saying I'm proficient in GL would be a huge overstatement, saying "I'm EGL" simply wrong. I've gotten Mesa to build a working software EGL driver but apart from that I'm not even certain what EGL really is and if it would be feasible to make a sort of hybrid EGL implementation that uses native OpenGL where possible to get *some* acceptable performance.
Software/CPU EGL is fine for simple/small-scale UI effects or for remote rendering where you don't expect fluid graphics anyway, but really not ideal as the main engine for all local rendering.
|
|
I had to drop most of libdispatch usage when making it build on GNU/Hurd anyway. What's left is some in `OwlMIG.m`; that should be rewritten anyway.
FWIW, I think there is a bug with thread-local storage in the posix/pthreads layer on OS X that leads to memory leaks, but not in libdispatch.
|
|
On Wednesday November 27 2024 04:40:08 Sergey Fedorov wrote:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_x11_owl/owl/work/owl-91abf02613cd2ddb97be58b5b6703240320233a0/Sources/Mach/OwlMIG.m:35:5: error: implicit declaration of function 'dispatch_source_set_event_handler'; did you mean 'dispatch_source_set_event_handler_f'? [-Wimplicit-function-declaration]
35 | dispatch_source_set_event_handler(source, ^{
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| dispatch_source_set_event_handler_f
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_x11_owl/owl/work/owl-91abf02613cd2ddb97be58b5b6703240320233a0/Sources/Mach/OwlMIG.m:35:47: error: expected expression before '^' token
35 | dispatch_source_set_event_handler(source, ^{
| ^
```
It is not just `libdispatch`, it is also using blocks – this won’t compile with gcc, any version of it (until its upstream finds time to add support into the compiler).
That's a simple ObjC file, not ObjC++ . IIUC that means there should be less risks with going from an Apple Block to an enclosure ("lambda" function) or in this case, a function pointer. You're installing an event handler here, so the handler code is *probably* called synchronously whenever an event occurs, rather than async on a separate thread.
The code doesn't compile with Apple's GCC which did have blocks support IIRC?
|
Well, with dispatch there is an issue that we just do not have it on 10.5 (I tried, but it does not compile there, in fact it failed even on 10a190 i386, ironically; it only works on 10.6 ppc), and blocks are out of question until Iain fixes that in gcc. But pthreads do have issues, I agree with you. |
Do you recall some example where that was done? I just never dealt with this.
Hmm, looks like it did actually, at least on 10.6.8, but linking fails: I will try passing arch flags explicitly. |
That was my idea with this, yes. Fully native OpenGL.framework, with a custom EGL implementation that does things on top of IOSurface and the |
|
Please test whether PPC Owl and x86 Wayland clients can interact just fine?
Again, you're just going to have to build without IOSurface and MIG. |
|
@bugaevc At the moment I know nothing about how this is supposed to work ) Is there something simple I can try? |
|
@RJVB BTW can it work in principle if C/C++ compiler is a modern gcc, while ObjC compiler is Xcode gcc? In most cases gcc-4.2 is not a workable option, since ports need C/C++11 or higher. But in Cocoa modules blocks may be used, so modern gcc cannot compile those. |
|
On Wednesday November 27 2024 05:53:54 Sergey Fedorov wrote:
Do you recall some example where that was done? I just never dealt with this.
I did it recently for building webkit-gtk with GCC - but that was using lambdas (ObjC++) and for (synchronous) calls to another thread.
ld: warning: in /opt/local/lib/libwayland-server.dylib, file was built for ppc7400 which is not the architecture being linked (x86_64)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
… |
|
On Wednesday November 27 2024 05:58:23 Sergey Bugaev wrote:
2. We should be able to make OwlMIG only use libdispatch when it's available, if at all
+++
That was my idea with this, yes. Fully native OpenGL.framework, with a custom EGL implementation that does things on top of IOSurface and the `owl-iosurface-unstable-v1` Wayland extension (well, a v2 of that rather), to enable sharing GPU buffers between the clients and Owl. I even had a small prototype, though the API was different from EGL.
Hmmm, sounds like an interesting exercise but also a bit of a futile one if you have any intentions of using this on recent Mac systems where GL is an endangered species from what I understand.
Can "official" Wayland be built using only Vulkan? In that case it might be more worthwhile to write a partially accelerated Vulkan implementation on top of OpenGL - that's definitely something that is missing!
|
|
On Wednesday November 27 2024 06:11:59 Sergey Fedorov wrote:
@RJVB BTW can it work in principle if C/C++ compiler is a modern gcc, while ObjC compiler is Xcode gcc? In most cases gcc-4.2 is not a workable option, since ports need C/C++11 or higher.
You'd have to try but I think there's more chance it'll work with [Obj]C than [Obj]C++ - C11 requirements are fortunately still pretty rare.
For testing wayland you'd need a wayland client. You could try to build GTk3 with the Wayland backend.
Or do as the other Sergey suggested on a different issue ticket: build `waypipe` and run Wayland apps remotely from a Linux box. With that we do know that the endianness must be the same on both ends though.
|
|
@bugaevc Looks like Apple documentation is lying here: it claims the function exists in 10.6+, and initially I assumed I got an error on 10.6 ppc due to its pre-release SDK. However, this fails on standard 10.6.8 just as much: While it could be that it is present on i386 but missing on ppc, looks like it is not the case that it is just available in 10.6+. |
|
On Wednesday November 27 2024 06:42:36 Sergey Fedorov wrote:
While it could be that it is present on i386 but missing on ppc, looks like it is not the case that it is just available in 10.6+.
It can also just be missing from the headers but be available in the library.
|
|
Just in case anyone wants to try this out:
P. S. This is likely to work on some subset of macOS versions and fail elsewhere. |
|
Natively on 10.6 ppc this is missing: Maybe UPD. I checked the headers, it is not really 10.6 ppc (10a190) as such lacks it. |
|
@RJVB Yeah, worth checking that also, though with 10.6.8 (standard release) it should not be the case. |
|
On Thursday November 28 2024 05:52:52 Sergey Fedorov wrote:
Maybe `IOSurface` stuff can be controlled with a configure switch? Rather than either unilaterally disabling it for ppc or trying to guess at compile time whether it is 10.6.8 or an earlier 10.6.
I think you should consider 10.6/PPC as a "largely 10.5" or something of the sort, where IOSurface doesn't get used.
|
For purposes of OpenGL that seems to be the case indeed. |
|
Restored original OpenGL from 10a190, here we go:
|
|
Well, the "failed to grab a socket" error is not very interesting 😃 Perhaps you could set |
|
@bugaevc The app does not pick the value from the env, but in CLI I can launch it without errors: What should I try? I have no apps which use Wayland, so need to know what to build which could work on macOS :) |
If you mean running the application from the Finder aka via LaunchServices, then no. Those applications will run as a child of a process/environment that your shell (CLI) is also a child of. You can set environment values for that parent process via NB: those should persist through login cycles and reboots! |
|
On Friday November 29 2024 05:25:11 Sergey Bugaev wrote:
ideally, we'd want the user experience to be that they can either launch Owl from Finder / LaunchServices (without getting the error message)
The simplest approach for that would be to set the missing env. var to something platform-appropriate if it isn't already set, at startup.
, or just start one of the clients, and have Owl auto-spawn.
Launchd provides a mechanism to do that via an env. variable that is used by XQuartz (it explains the weird DISPLAY variable if you use this mechanism) as well by DBus.
From what I understand it reacts to a client trying to access the specified variable, so using one of the standard XDG protocol variables wouldn't be ideal but assuming the connection logic happens via (is hidden by) the underlying Wayland library it should be possible to introduce a platform specific variable (DBus does this too).
The mechanism also creates the socket for you, and this requires some code inside the server application (not sure why clients can just use the value in the env. var. but it is what it is).
I disable auto-launching in XQuartz because I want to have a standard :0.0 DISPLAY value I can type in when needed. With Wayland things don't work that way AFAICT so auto-launching would be a good idea.
|
|
On Friday November 29 2024 03:28:08 Sergey Fedorov wrote:
What should I try? I have no apps which use Wayland, so need to know what to build which could work on macOS :)
As I said, try building port:GTk3 with wayland support. You can just enable it as an additional variant to the +x11 variant. This should give you a few test/demo applications.
|
Not the variable, but from a client connecting to the Unix socket to which the variable is pointing.
That's just how socket activation works: clients just connect to the socket (and they can receive the path to it via means other than env), whereas the server listens on it. But it's launchd who initially listens on the socket, and your server has to "check in" and get the socket fd created by launchd. |
|
On Friday November 29 2024 06:41:47 Sergey Bugaev wrote:
Not the variable, but from a client connecting to the Unix socket to which the variable is pointing.
That would mean that the variable gets set and the socket created even if no one ever requests it? I keep meaning too check that upon login but I always forget and then my dbus daemon is already running :-/
That's just how socket activation works: clients just _connect_ to the socket (and they can receive the path to it via means other than env), whereas the server listens on it. But it's launchd who initially listens on the socket, and your server has to "check in" and get the socket fd created by launchd.
Yeah, I figured it had to be something like that.
|
Yep. But sockets (and env) are cheap; the actual server/daemon is only started up when some client actually connects to the socket (if so configured). |
|
On Friday November 29 2024 07:15:51 Sergey Bugaev wrote:
Yep. But sockets (and env) are cheap; the actual server/daemon is only started up when some client actually connects to the socket (if so configured).
Env. yes, of course, but a socket takes (at least) 2 fds, no? And Darwin isn't as generous with those as Linux is. But I guess the socket doesn't actually have to be created (and we can probably never check if it is without going through the relevant code). Kind of an inverse Heisenberg problem ;)
|
|
Did you retire the port already, or is it in a different branch?
|
Sorry, not related to the issue. But is the wayland variant available through the macports tree or yer local ports repo? I can't seem to find it 😆 . Also how would it overcome the issue of EGL support? |
|
On Wednesday December 11 2024 06:23:02 Zaphh wrote:
Sorry, not related to the issue. But is the wayland variant available through the macports tree or yer local ports repo?
Not currently, it will be once I get it to work on my end. In the meantime you can try patching the port yourself.
Also how would it overcome the issue of EGL support?
That remains to be seen, in general!
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The first error was
OwlKnownClientsManager.m:46: error: ‘for’ loop initial declaration used outside C99 mode; after passing-std=c99, the build proceeded, but failed here:The text was updated successfully, but these errors were encountered: