On 6 December 2016 at 18:08, Jeremy Huddleston Sequoia <jerem...@apple.com> wrote: > >> On Dec 6, 2016, at 06:04, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> >> On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia >> <jerem...@apple.com> wrote: >>> >>>> On Dec 5, 2016, at 11:52 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: >>>> >>>> From: Emil Velikov <emil.veli...@collabora.com> >>>> >>>> No point in having an identical code in two places. >>>> >>>> Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf >>>> type. This change is both API and ABI safe since the header uses the >>>> correct GLXPbufferSGIX and both types are a typedef of the same >>>> primitive XID. >>>> >>>> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com> >>>> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> >>> >>> Reviewed-by: Jeremy Sequoia <jerem...@apple.com> >>> (not tested yet, though) >>> >> Thanks. >> >>>> --- >>>> Jeremy, humble poke to send any/all Macports patches to the list ;-) >>> >>> What patches are you referring to? AFAIK, all the patches we have in >>> MacPorts are hacks that have been rejected by mesa or are things I don't >>> think should be in mesa due to lack of polish/hack status. See: >>> https://github.com/macports/macports-ports/tree/master/x11/mesa/files >>> >> Almost, but not quite ;-) >> >> - 0001-mesa-Deal-with-size-differences-between-GLuint-and-G.patch >> Should not longer be needed with the BUILDING_MESA workaround. > > Thanks, I'll give that a try. > >> - 0002-applegl-Provide-requirements-of-_SET_DrawBuffers.patch >> Some serious work needed. > > Yep. That's why I haven't resent it. Need time to make it better. > >> - 0003-glext.h-Add-missing-include-of-stddef.h-for-ptrdiff_.patch >> Should not be needed since the header is included further up in the >> file. Alternatively poke Khronos and upstream it. > > Yep, that was the result of the conversation on the list. I filed a khronos > bug and don't think they've acted on it. I'll check the status when I get > some time. > The only way I see this being an issue is by something (glcorearb.h ?) is setting the GL_VERSION_1_5 define before including glext.h, thus the #include <stddef.h> [in the #ifndef GL_VERSION_1_5 section] gets omitted.
Then again we should get all the includes at the top or at least outside the "extern C" guard. I'll see if we can get these sorted. >> - no-missing-prototypes-error.patch >> No traces of it on the list and no commit message describing why it's >> needed :'-( > > https://trac.macports.org/ticket/46827 > > IMO, this is a hack and doesn't meet the bar of upstreaming at this quality > level as it's not a real fix. > Hmm nasty indeed. Fwiw it looks like a nice candidate to address in the toolchain. >> - patch-include-GL-mesa_glinterop_h.diff >> No longer needed - fixed upstream > > Thanks. I'll test removing it when I get a chance. > >> - static-strndup.patch >> We have WIN32(?) strndup in src/util/strndup.[ch]. Static inline into >> include/posix_string.h alongside strnlen. Or better yet add a patch >> for the build toolchain, thus one doesn't need to fix these in every >> project ;-) > > Yeah, that's why I haven't upstreamed this. It's not the correct fix. > > The build toolchain can't be patched. It is the gcc-4.2 that shipped with > Xcode 3 about 10 years ago. We try to support the Apple-provided toolchain > for building ports for as long as possible. When it becomes too unwieldy, we > blacklist it in individual ports. That causes a newer toolchain to be used > (my preferred ones being clang-3.4 or clang-3.7; clang-3.8 has some bad > codegen issues, so I don't trust it, and 3.9+ currently don't build on Snow > Leopard). > Thinking out loud (sort of): If permissions to the header(s) is not an issue one can add static inline implementations (and missing declarations ?). Alternatively having a "cc" wrapper which always includes the local (fixed) header(s) prior to anything else should get you going. At the same time: not sure how many other projects depend on such fixes, so it may be that doing this will be more work than what its worth. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
