clang --version clang version 11.0.0 (https://github.com/llvm/llvm-project 1bf5ffa164f19094ece5809a4cceeedb740b9281) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: D:\dev\llvm\win64_ninja_release\bin
"-target" "x86_64-unknown-windows" Yes, this is not "x86_64-msvc-windows" or whatever. On Sat, 14 Mar 2020 at 01:16, Martin Storsjö <mar...@martin.st> wrote: > > On Sat, 14 Mar 2020, Egor Pugin wrote: > > >> The first hunk seems harmless. But why would you like to define > > `WINPTHREAD_API` yourself? > > > > Custom build system. Building winpthreads under native win32 with > > clang (not clang-cl) without msvc compat. > > Clang in such mode requires __attribute__ ((dllexport) and > > __attribute__ ((dllimport), not __declspecs. > > That doesn't sound like the clang behaviour I know of. > > What clang target do you use, a mingw32 or msvc one? (If you're using an > official llvm release from llvm.org, it's a msvc target by default. If you > specify anything custom with -target, that overrides it.) > > In MSVC mode, __declspec() is a native construct that is understood > directly as is. In MinGW mode (in clang, and GCC also does the same when > targeting mingw), __declspec(x) is a macro that expands to > __attribute__((x)), and I don't know of a way to even disable that builtin > define. > > So with which clang version and/or clang target do you manage to have > __declspec(dllexport) not be understood? > > // Martin > > > > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Egor Pugin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
