Meson build - Windows

[tmarrinan]

Hello.
I am having an issue building with Meson on Windows.

First, when I install Python 3.6 for windows, the executable is python.exe (not python3.exe). When I run meson.py .. . --backend=vs2015 I get an error saying Program python3 found: NO.

I created a symlink from python.exe to python3.exe. This resolved that issue and successfully creates a MSVC solution. However, when building, it has several errors along the lines of:

"C:/Python36/python3.EXE" "python" "C:/projects/libepoxy/src/gen_dispatch.py" <...>
C:/Python36/python3.EXE: can't open file 'python': [Errno 2] No such file or directory

It appears as though the gen_dispatch.py is set to be called from python twice, which is what causes the error.

[ebassi]

Right, this is addressed in #100. I assume you're using a newer version of Meson.

[tmarrinan]

Yes - I am grabbing the latest version of Meson (0.38.0).
I couldn't quite tell from the status of #100 if any solution has been found and integrated into master?

[ebassi]

No, it hasn't yet, but I'm going to work on it ASAP.

[ebassi]

I've merged PR #100 which means that you'll need both Python 3 and Python 2 installed in order to build Epoxy.

We cannot really drop the Python 2 requirement because various platforms shipping Epoxy do not have Python 3 — which is also why we are keeping the autotools build.

If you install Python 2 and Python 3, everything should work out of the box. Maybe in the future I'll add a new gen_dispatch.py script that only uses Python 3, and have the Meson build strictly depend only on Python 3.

[tmarrinan]

Thanks!
I am still however receiving errors during my build. These are the steps I do:

1. clone libepoxy repo
2. make directory 'build' inside libepoxy repo
3. download meson 0.38.0
4. run meson.py .. . --backend=vs2015
5. run msbuild /t:Build /p:Configuration=debugoptimized /p:Platform=Win32 libepoxy.sln

I have done this with only Python 2.7 in my path, only Python 3.6 in my path, and both 2.7 and 3.6 in the path (making a symlink from python.exe to python3.exe for 3.6). All attempts to build fail at the msbuild stage.

There are a number of link errors similar to:
error LNK2001: unresolved external symbol _epoxy_glCreateShader

[ebassi]

Seems like a symbol visibility issue; I cannot reproduce it when cross-compiling, so it could be an issue that is exposed because of some missing compiler flag.

It would be helpful if you could attach a build log to the issue.

[tmarrinan]

I've attached a sample build output from the msbuild command
Microsoft Build - Epoxy.txt

[codicodi]

I have similar issue. Epoxy.dll is built without problems, but executables fail to link to it. Static build works though, so I think some symbols are not exported/imported correctly.

Edit:
This is probably the issue (from common.h):

#ifndef EPOXY_PUBLIC
# define EPOXY_PUBLIC extern
#endif

This works for importing functions from dll, but to import data symbols __declsped(dllimport)is required

Edit2:
Hmm the lines above probably do not matter during build as config.h declares:
#define EPOXY_PUBLIC __declspec(dllexport) extern
in tests even before common.h is included. Symbols are still not imported though. And user code won't work without dllimport.

[ebassi]

Indeed, it seems we need __declspec(dllimport) for the export symbols in the dispatch table on MSVC.

[tmarrinan]

I am still getting the same error after merging the latest into my fork.
@codicodi, could you tell me your build steps? I listed the 5 steps I do to attempt and build libepoxy and was wondering where our processes differ.

[tmarrinan]

In case it matters, here is the output from Meson:

cd <path_to_libepoxy>\build
C:\Python36\python.exe <path_to_meson-0.38.0>\meson.py .. . --backend=vs2015
The Meson build system
Version: 0.38.0
Source dir: C:\projects\libepoxy
Build dir: C:\projects\libepoxy\build
Build type: native build
Project name: libepoxy
Native c compiler: cl (msvc 19.00.24215.1)
Build machine cpu family: x86
Build machine cpu: x86
Has header "KHR/khrplatform.h": NO
Compiler for c supports argument -Wpointer-arith: NO
Compiler for c supports argument -Wmissing-declarations: NO
Compiler for c supports argument -Wformat=2: NO
Compiler for c supports argument -Wstrict-prototypes: NO
Compiler for c supports argument -Wmissing-prototypes: NO
Compiler for c supports argument -Wnested-externs: NO
Compiler for c supports argument -Wbad-function-cast: NO
Compiler for c supports argument -Wold-style-definition: NO
Compiler for c supports argument -Wdeclaration-after-statement: NO
Compiler for c supports argument -Wunused: NO
Compiler for c supports argument -Wuninitialized: NO
Compiler for c supports argument -Wshadow: NO
Compiler for c supports argument -Wmissing-noreturn: NO
Compiler for c supports argument -Wmissing-format-attribute: NO
Compiler for c supports argument -Wredundant-decls: NO
Compiler for c supports argument -Wlogical-op: NO
Compiler for c supports argument -Werror=implicit: NO
Compiler for c supports argument -Werror=nonnull: NO
Compiler for c supports argument -Werror=init-self: NO
Compiler for c supports argument -Werror=main: NO
Compiler for c supports argument -Werror=missing-braces: NO
Compiler for c supports argument -Werror=sequence-point: NO
Compiler for c supports argument -Werror=return-type: NO
Compiler for c supports argument -Werror=trigraphs: NO
Compiler for c supports argument -Werror=array-bounds: NO
Compiler for c supports argument -Werror=write-strings: NO
Compiler for c supports argument -Werror=address: NO
Compiler for c supports argument -Werror=int-to-pointer-cast: NO
Compiler for c supports argument -Werror=pointer-to-int-cast: NO
Compiler for c supports argument -fno-strict-aliasing: NO
Compiler for c supports argument -Wno-int-conversion: NO
Library dl found: NO
Found Pkg-config: NO
Dependency egl found: NO
Dependency x11 found: NO
Library libGLESv1_CM found: NO
Library libGLESv2 found: NO
Library opengl32 found: YES
Library gdi32 found: YES
Program src/gen_dispatch.py found: YES (python C:\projects\libepoxy\src/gen_dispatch.py)
Build targets in project: 13

[codicodi]

Unfortunately latest patch didn't help for me either.
As I mentioned before tests include config.h, which defines EPOXY_PUBLIC before common.h has a chance to define it as dllimport.

[ebassi]

Oh, ouch; I didn't see the config.h in the tests. That's not really nice, since config.h is meant to be used while building Epoxy itself, and the tests should be testing client code, not internal behaviour. Let's see if I can fix this in a sensible way.

[tmarrinan]

@codicodi, can you still provide your build process? As I am unable to even build a dll (regardless of whether it functions or not), comparing my workflow to yours would be helpful.

[codicodi]

Sure, here you go:
msbuild-log.txt
meson-config-log.txt

Your log mentions dll was successfully created, see line 146

[ebassi]

@codicodi I've updated the WGL tests, which were the only ones that included config.h, to not include the header any more.

[codicodi]

Cool, it builds for me now. Many thanks!

[tmarrinan]

Yup - working for me too!