[Piglit] [RFC PATCH 2/2] cmake: build the util libraries as shared under Windows

[Jose Fonseca]

On 23/11/14 18:11, Emil Velikov wrote:
> On 23/11/14 11:18, Jose Fonseca wrote:
>> On 22/11/14 22:26, Emil Velikov wrote:
>>> Rather than rebuilding every single test as we change the util
>>> libraries and increase the size of each test by ~9MiB (as noticed
>>> in the mingw-w64 build), just revert to shared piglitutil* libs.
>>
>> This is great. I actually tried to do this, a year ago or so, but I gave
>> up half way through trying to overcome "missing symbols". I don't know
>> if changes in piglit made this easier or if you found a better solution,
>> but I'm happy you worked it out.
>>
> The compile-time missing symbols should be resolved with patch 01/02. If
> there are any missing at runtime, can you provide any information -
> which symbol(s) on what Windows, is piglit/glut/etc build via
> mingw{32,-w64} or MSVC, etc. ?
>
>>> TODO:
>>>    - Check if the DLLs are installed and where.
>>>    - If there is one or more executables linking against them, but located
>>> in a different folder, see the next todo note.
>>>    - Modify the python scripts to set PATH to the location of the DLLs.
>>> Alternatively apply any of the other solutions as mentioned here
>>
>> The solution is to put all .dlls on the bin directory, next to the
>> executables.
>>
>> And I think that the
>>
>>     set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${piglit_BINARY_DIR}/bin)
>>
> I'm not sure if that will collide with the install() directive below,
> thus the notes and contingency plan :P
>
>> on piglit's top CMakeLists.txt.
>>
>> That said, I think I'd like first to get piglit + waffle on windows
>> wokring reliably, before DLL'ifying the libraries.  This way I don't
>> have to worry about testing with glut.
>>
> DLL'ifying the libraries is not related to using glut/waffle. Thus one
> can just have it ticked off (confirm that it works ok), for either (or
> both) builds and worry about the waffle WGL bugs as we uncover them :)
>
> My current (waffle) builds are
>   - Linux: (GCC default build) ~1150 files, 33MiB in size
>   - Windows: (MSVC default build) ~1030 files, 4.9GiB in size.
> ~70% of which are the debug symbols.
>
> So it's approx 45 times larger, when we ignore the debug symbols and
> that Windows has ~10% tests less. Or 170 times if we consider it.
>
> Hope that's enough to convince you that it might be nice to have this
> earlier rather than later :)

I don't mind to get it in once all problems are ironed out.  But your 
commit message highlitghted some rough edges.   Furthermore this is not 
working for me:

$ ninja -C build/mingw32
ninja: Entering directory `build/mingw32'
[120/2334] Generating builtin_uniform_tests.list
/home/jfonseca/work/vmware/tests/piglit/generated_tests/builtin_function.py:1262: 
RuntimeWarning: overflow encountered in uint_scalars
   f('op-assign-sub', 2, 110, lambda x, y: x - y, 
match_assignment_operators,
/home/jfonseca/work/vmware/tests/piglit/generated_tests/builtin_function.py:1304: 
RuntimeWarning: overflow encountered in uint_scalars
   f('op-sub', 2, 110, lambda x, y: x - y, match_simple_binop,
[173/2334] Generating constant_array_size_tests.list
/home/jfonseca/work/vmware/tests/piglit/generated_tests/builtin_function.py:1262: 
RuntimeWarning: overflow encountered in uint_scalars
   f('op-assign-sub', 2, 110, lambda x, y: x - y, 
match_assignment_operators,
/home/jfonseca/work/vmware/tests/piglit/generated_tests/builtin_function.py:1304: 
RuntimeWarning: overflow encountered in uint_scalars
   f('op-sub', 2, 110, lambda x, y: x - y, match_simple_binop,
[192/2334] Linking CXX executable bin/fbo-incomplete.exe
FAILED: : && /usr/bin/i686-w64-mingw32-g++  -Wall -g  -static-libgcc 
-static-libstdc++ 
target_api/gl/tests/fbo/CMakeFiles/fbo-incomplete.dir/fbo-incomplete.cpp.obj 
  -o bin/fbo-incomplete.exe 
-Wl,--out-implib,target_api/gl/tests/fbo/libfbo-incomplete.dll.a 
-Wl,--major-image-version,0,--minor-image-version,0 
/home/jfonseca/projects/sdk/mingw32/lib/libfreeglut.a 
target_api/gl/tests/util/libpiglitutil_gl.dll.a -lopengl32 -lglu32 
/home/jfonseca/projects/sdk/mingw32/lib/libfreeglut.a -lopengl32 
target_api/no_api/tests/util/libpiglitutil.dll.a -lkernel32 -luser32 
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 
-ladvapi32 && :
/usr/lib/gcc/i686-w64-mingw32/4.6/libgcc_eh.a(unwind-sjlj.o):(.text+0x2e0): 
multiple definition of `__Unwind_SjLj_Register'
target_api/gl/tests/util/libpiglitutil_gl.dll.a(d000023.o):(.text+0x0): 
first defined here
/usr/lib/gcc/i686-w64-mingw32/4.6/libgcc_eh.a(unwind-sjlj.o):(.text+0x3a0): 
multiple definition of `__Unwind_SjLj_Unregister'
target_api/gl/tests/util/libpiglitutil_gl.dll.a(d000026.o):(.text+0x0): 
first defined here
/usr/lib/gcc/i686-w64-mingw32/4.6/libgcc_eh.a(unwind-sjlj.o):(.text+0x6a0): 
multiple definition of `__Unwind_SjLj_Resume'
target_api/gl/tests/util/libpiglitutil_gl.dll.a(d000024.o):(.text+0x0): 
first defined here
collect2: ld returned 1 exit status
[192/2334] Building C object 
target_api/gl/tests/fbo/CMakeFiles/fbo-incomplete-texture-02.dir/fbo-incomplete-texture-02.c.obj
ninja: build stopped: subcommand failed.


I suspect that this patch series is insufficient on its own.  Just like 
when I tried to do this, we need to use the 
declspec(dllexport)/declspec(dllimort) attributes rigorously to avoid 
exporting too many or too little symbols.  And this is hard work, since 
for every DLL "foo" we need a "-DBUILDING_FOO" define while building, 
and then have in the header

   #ifdef BUILDING_FOO
   #define FOO_EXPORT declspec(dllexport)
   #else
   #define FOO_EXPORT declspec(dllimport)
   #endif

then prefix all exported simbols with FOO_EXPORT.


In short, I agree that shaving time from compile or space from binaries 
would be quite nice, but keeping things building and running without 
problems is critical, and I'm afraid that updating piglit to use DLLs on 
Windows won't be something that can be rushed.  And since I can't afford 
to neglect my other duties I must insist that we deal with one 
disruptive problem at a time -- waffle on Windows, or DLLs on Windows -- 
but not both simultaneously.


Jose