If the --no-gnu-unique flag is removed the build will fail later.
[12/207] Compiling C++ object 'src/dxbc/5c53ffa@@dxbc@sta/dxbc_header.cpp.o'.
In file included from ../src/dxbc/dxbc_reader.cpp:3:
In file included from ../src/dxbc/dxbc_reader.h:6:
In file included from ../src/dxbc/dxbc_tag.h:3:
In file included from ../src/dxbc/dxbc_include.h:3:
In file included from ../src/dxbc/../dxvk/dxvk_shader.h:5:
In file included from ../src/dxbc/../dxvk/dxvk_include.h:6:
In file included from ../src/dxbc/../dxvk/../util/util_env.h:3:
In file included from ../src/dxbc/../dxvk/../util/util_string.h:7:
In file included from ../src/dxbc/../dxvk/../util/./com/com_include.h:11:
In file included from /opt/wine-staging/4.15/include/wine/windows/unknwn.h:13:
In file included from /opt/wine-staging/4.15/include/wine/windows/ole2.h:25:
In file included from /opt/wine-staging/4.15/include/wine/windows/objbase.h:252:
/opt/wine-staging/4.15/include/wine/windows/objidl.h:6100:15: error: types cannot be declared in an anonymous struct
union __WIDL_objidl_generated_name_0000000C {
^
In file included from ../src/dxbc/dxbc_reader.cpp:3:
In file included from ../src/dxbc/dxbc_reader.h:6:
In file included from ../src/dxbc/dxbc_tag.h:3:
In file included from ../src/dxbc/dxbc_include.h:3:
In file included from ../src/dxbc/../dxvk/dxvk_shader.h:5:
In file included from ../src/dxbc/../dxvk/dxvk_include.h:8:
In file included from ../src/dxbc/../dxvk/../util/util_flags.h:5:
In file included from ../src/dxbc/../dxvk/../util/util_bit.h:4:
In file included from /usr/bin/../lib64/clang/8.0.1/include/x86intrin.h:29:
In file included from /usr/bin/../lib64/clang/8.0.1/include/immintrin.h:32:
In file included from /usr/bin/../lib64/clang/8.0.1/include/xmmintrin.h:39:
/usr/bin/../lib64/clang/8.0.1/include/mm_malloc.h:59:22: error: use of undeclared identifier '_aligned_malloc'; did you mean 'aligned_alloc'?
__mallocedMemory = _aligned_malloc(__size, __align);
^
/usr/include/stdlib.h:583:14: note: 'aligned_alloc' declared here
extern void *aligned_alloc (size_t __alignment, size_t __size)
^
2 errors generated.
winegcc: clang++ failed
Full log: dxvk.log
I do not intend to waste any time on fixing this. Supporting regular winegcc builds is already annoying enough, and the errors you are seeing when removing the --no-gnu-unique flag happen inside system headers, not inside DXVK code. Have you actually checked whether your winegcc works at all?
The first error is already being worked around, see #1179.
Have you actually checked whether your winegcc works at all?
Yes, wine-nine-standalone builds. https://github.com/iXit/wine-nine-standalone/pull/54
I do not intend to waste any time on fixing this.
Well that is unfortunate, its valuable to have both gcc and clang working in the event of compiler issues and without this being fixed this kind of sabotages anyone that wishes to spend time testing wine with clang.
clang does work in combination with mingw. It's just your winegcc builds that are broken at the moment, and I don't plan to support those forever anyway since wine itself is moving to PE files.
In any case, how do you expect me to fix issues that are not inside my code but some missing symbol in some system header, especially when I'm not even using the missing symbol directly? There's just nothing I can do here, and figuring out why exactly this is happening just isn't a useful thing to spend my time on compared to some actual issues.
clang does work in combination with mingw.
I know there are people in other projects that are working towards improving this, regardless I don't have mingw and there doesn't seem to be a good mingw build for Slackware yet which is not trivial to add. Removing this support would be unfortunate for some users, but I don't understand the implications of how PE files would make this harder?
In any case, how do you expect me to fix issues that are not inside my code but some missing symbol in some system header, especially when I'm not even using the missing symbol directly?
I see two issues, the first is that there is a gcc specific compiler flag being hardcoded in the dxvk cross files and the second is the build failure. If the build failure is something broken in wine then I can report it upstream instead if the first issue is fixed.
but I don't understand the implications of how PE files would make this harder?
My point is that the number of good reasons to support building .dll.so's is getting smaller when even wine itself stops using them for the most part.
I see two issues, the first is that there is a gcc specific compiler flag being hardcoded in the dxvk cross files and the second is the build failure.
Pointing the compiler in the right direction is literally the point of having cross files. You're using a different compiler than these files were written against.
--no-gnu-unique was added because apparently it's necessary, see PR #513.
and there doesn't seem to be a good mingw build for Slackware yet
That's a Slackware problem, not a DXVK problem. Building wine with PE files also requires mingw.
My point is that the number of good reasons to support building .dll.so's is getting smaller when even wine itself stops using them for the most part.
Frankly that does not seem like a very good reason when considering how hefty of a dependency mingw is. If wine forced mingw then that would be different, but its fully possible to build and use wine without mingw installed.
Pointing the compiler in the right direction is literally the point of having cross files. You're using a different compiler than these files were written against.
Ideally the build system should be able to determine if its using gcc, clang or another compiler during configure and act accordingly. Making new cross files that differ only in one or two lines would be silly and hard to use for build scripts like used in Slackware when winegcc may be built by gcc or clang. Looking at the PR the original change to add it in meson.build was probably better.
Well, feel free to file a PR, but the build system is already a horrible mess because it supports all these different environments (and MSVC on top of that). Adding more stuff in there is just going to make it worse.
I don't really see how having the option to build something that likely results in broken binaries is particularly useful, though, unless clang has a similar option or does whatever no-gnu-unique does by default. That is, if you can even fix the header issue.
Well, feel free to file a PR
If only it wasn't meson I would be more likely to touch it...
I don't really see how having the option to build something that likely results in broken binaries is particularly useful
The intended goal is to work towards debugging and fixing issues either here or in the respective upstreams as they are found. It just happens that the issue in the cross files is the first one.
@orbea
error: use of undeclared identifier '_aligned_malloc';
Try this patch:
--- a/src/util/util_bit.h
+++ b/src/util/util_bit.h
@@ -1,7 +1,14 @@
#pragma once
#ifndef _MSC_VER
+ #ifdef __clang__
+ #pragma push_macro("_WIN32")
+ #undef _WIN32
+ #endif
#include <x86intrin.h>
+ #ifdef __clang__
+ #pragma pop_macro("_WIN32")
+ #endif
#else
#include <intrin.h>
#endif
@pchome Thanks, but unfortunately that doesn't change the errors.
Edit: I was just still missing https://github.com/doitsujin/dxvk/issues/1179...
@orbea
Thanks, but unfortunately that doesn't change the errors.
Oh, I just realized I using an old D9VK version w/ only d3d9 build enabled. So, i guess, there are more places to fix for DXVK. I did a quick test using clang-tidy, so no guaranteed this is a proper fix.
Alternatively mm_malloc.h could be redefined.
So, at least for clang-tidy, adding -D__WIDL_objidl_generated_name_0000000C= and -D__MM_MALLOC_H (or -D_mm_malloc, found in my old experiments) help silence the errors for DXVK. There was some ICEs, but that's another story.
@pchome Thanks again, I can confirm the build succeeds here after the following.
--no-gnu-unique is removed.-D__MM_MALLOC_H is added.If you're needing to define random include guards there's obviously something wrong with your build setup
I was able to avoid that define with this hack to /usr/lib64/clang/8.0.1/include/mm_malloc.h.
--- mm_malloc.h.orig 2019-09-04 19:23:02.465276823 -0700
+++ mm_malloc.h 2019-09-04 19:30:05.531413286 -0700
@@ -55,8 +55,8 @@
void *__mallocedMemory;
#if defined(__MINGW32__)
__mallocedMemory = __mingw_aligned_malloc(__size, __align);
-#elif defined(_WIN32)
- __mallocedMemory = _aligned_malloc(__size, __align);
+//#elif defined(_WIN32)
+// __mallocedMemory = _aligned_malloc(__size, __align);
#else
if (posix_memalign(&__mallocedMemory, __align, __size))
return 0;
The gcc version doesn't check for _WIN32 and does not have this problem.
Expanding on @pchome's original patch this works.
diff --git a/src/util/util_bit.h b/src/util/util_bit.h
index 42191298..5fddc64a 100644
--- a/src/util/util_bit.h
+++ b/src/util/util_bit.h
@@ -1,7 +1,14 @@
#pragma once
#ifndef _MSC_VER
+#ifdef __WINE__
+#pragma push_macro("_WIN32")
+#undef _WIN32
+#endif
#include <x86intrin.h>
+#ifdef __WINE__
+#pragma pop_macro("_WIN32")
+#endif
#else
#include <intrin.h>
#endif
It seems winegcc does not respect __clang__.
Edit:
$ winegcc -dM -E - < /dev/null | grep -i clang
#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
#define __CLANG_ATOMIC_INT_LOCK_FREE 2
#define __CLANG_ATOMIC_LLONG_LOCK_FREE 2
#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __VERSION__ "4.2.1 Compatible Clang 8.0.1 (tags/RELEASE_801/final)"
#define __clang__ 1
#define __clang_major__ 8
#define __clang_minor__ 0
#define __clang_patchlevel__ 1
#define __clang_version__ "8.0.1 (tags/RELEASE_801/final)"
This workaround also already exists in two places.
When building dxvk with a copy of
winegccwhich has been built byclangand using thebuild-wine32.txtorbuild-wine64.txtcross files the build will fail because onlygccsupports--no-gnu-unique.I am not sure if this flag is important to keep or how to work around this using meson...
I am building
dxvkwith this command line.System information
4.151.3.30.51.28.0.1Log files