MantisBT - CMake
View Issue Details
0014029CMakeModulespublic2013-03-19 22:342014-06-02 08:37
Paul "TBBle" Hampson 
Benjamin Eikel 
normalminoralways
closedfixed 
Microsoft Visual StudioMicrosoft Windows7 SP1
CMake 2.8.10.2 
 
0014029: FindSDL and FindSDL_image modules cannot find the SDL-distributed VC++ development libraries
The Visual C++ development packages for SDL and SDL_image include both x86 and x64 libraries with the same name, but in different paths.

The current FindSDL and FindSDL_image Modules do not handle this correctly, and fail to locate them.

Grab the SDL-distributed development packages for Visual Studio:
http://www.libsdl.org/release/SDL-devel-1.2.15-VC.zip [^] (from http://www.libsdl.org/download-1.2.php [^])
http://www.libsdl.org/projects/SDL_image/release/SDL_image-devel-1.2.12-VC.zip [^] (from http://www.libsdl.org/projects/SDL_image/ [^])

Set SDLDIR and SDLIMAGEDIR to the top level of those extracted zips.

Build a CMake project that uses
FIND_PACKAGE( SDL REQUIRED )
FIND_PACKAGE( SDL_image REQUIRED )

The CMake invocation will fail
The fix I have locally (against 2.8.11 rc1) is basically the same for both modules:

I add:

if(CMAKE_GENERATOR MATCHES Win64)
    set(MSVC_DEVEL_PATHSUFFIX lib/x64)
else()
    set(MSVC_DEVEL_PATHSUFFIX lib/x86)
endif()


before the find_library blocks, and then in the find_library invocations, change PATH_SUFFIXES to:

PATH_SUFFIXES lib ${MSVC_DEVEL_PATHSUFFIX}

That's been working fine for me here.
msvc
Issue History
2013-03-19 22:34Paul "TBBle" HampsonNew Issue
2013-03-20 04:16Benjamin EikelNote Added: 0032677
2013-10-03 23:01Paul "TBBle" HampsonNote Added: 0033971
2013-10-04 03:13Benjamin EikelNote Added: 0033972
2013-10-09 20:11Paul "TBBle" HampsonNote Added: 0034087
2013-10-10 06:23Paul "TBBle" HampsonNote Added: 0034092
2013-10-10 06:24Paul "TBBle" HampsonTag Attached: msvc
2013-10-10 08:57Brad KingNote Added: 0034096
2013-10-10 09:00Brad KingNote Added: 0034097
2013-11-11 16:33Benjamin EikelNote Added: 0034430
2013-11-17 18:46Paul "TBBle" HampsonNote Added: 0034454
2013-11-17 20:10Paul "TBBle" HampsonNote Added: 0034455
2013-11-18 15:10Benjamin EikelNote Added: 0034474
2013-11-21 14:17Benjamin EikelNote Added: 0034507
2013-11-21 14:33Benjamin EikelStatusnew => resolved
2013-11-21 14:33Benjamin EikelResolutionopen => fixed
2013-11-21 14:33Benjamin EikelAssigned To => Benjamin Eikel
2013-11-21 15:31Brad KingNote Added: 0034508
2014-06-02 08:37Robert MaynardNote Added: 0036021
2014-06-02 08:37Robert MaynardStatusresolved => closed

Notes
(0032677)
Benjamin Eikel   
2013-03-20 04:16   
Question to other CMake developers: Should these additional paths be added to the SDL find modules or is there a CMake-wide solution (maybe adding them to the standard library search paths)?
(0033971)
Paul "TBBle" Hampson   
2013-10-03 23:01   
It's been pointed out to me (but I haven't tested it yet) that doing the following before calling the FindSDL module would function as a workaround, although it is overriding a CMAKE-detected variable and so would need to be reset back afterwards.

IF(CMAKE_GENERATOR MATCHES Win64)
   SET(CMAKE_LIBRARY_ARCHITECTURE x64)
ELSE()
   SET(CMAKE_LIBRARY_ARCHITECTURE x86)
ENDIF()
(0033972)
Benjamin Eikel   
2013-10-04 03:13   
Thank you for your reply. In my opinion, your workaround sounds like there is a problem with the CMAKE_LIBRARY_ARCHITECTURE variable. Maybe it is related to issue 14457 (http://www.cmake.org/Bug/view.php?id=14457 [^]).
(0034087)
Paul "TBBle" Hampson   
2013-10-09 20:11   
The problem is that the correct value for "CMAKE_LIBRARY_ARCHITECTURE" on 32-bit Win32 is "x86" for some libraries, and "Win32" for others. For 64-bit Win32, it's normally "x64" although the Visual Studio C++ runtime's folder is "amd64".

A quick survey of my machine: the DirectX SDK and the v7 and v8 Microsoft SDKs use "x86" and "x64", but the Visual-Studio bundled runtime and ATL/MFC libs use "" and "amd64". Python's build system (at least in 2.7) also outputs its libs to "" and "amd64". The v6 Microsoft SDKs use "" and "x64".

Currently both 32-bit and 64-bit are coming up with "" for CMAKE_LIBRARY_ARCHITECTURE, so issue 14457 does affect this, but resolving that probably won't resolve this. I expect resolving issue 14457 for Visual Studio would match the runtime library, giving "" and "amd64" for 32-bit and 64-bit MSVC compiler respectively.

What I'd suggest is that once issue 14457 is resolved for Visual Studio, we can check the value of CMAKE_LIBRARY_ARCHITECTURE in FindSDL.CMake to add the right library PATH_SUFFIXES for the current architecture. So like my current workaround, but without relying on the generator name.
(0034092)
Paul "TBBle" Hampson   
2013-10-10 06:23   
Looking at issue 0014457, that's not the issue, that's a bug in code that should work.

A check through the code suggests that right now, neither MSVC nor Clang-simulating-MSVC will have "CMAKE_${lang}_VERBOSE_FLAG" set, and so will not try to populate CMAKE_LIBRARY_ARCHITECTURE.

I wrote up a patch to do that, and submitted it as issue 0014473. If and when this goes it, FindSDL.cmake can mangle CMAKE_LIBRARY_ARCHITECTURE to match the upstream-provided SDK with no extra work and without relying on the generator as I do now.

http://cmake.org/Bug/view.php?id=14473 [^]
(0034096)
Brad King   
2013-10-10 08:57   
Issue 0014457 is on a system with hand-built toolchain not configured with the system architecture triplet AFAICT.

The proposal in 0014473 is not a general solution because different packages may not agree on the per-architecture directory name.

The path suffixes approach proposed in the "additional information" is the right approach for FindSDL IMO.
(0034097)
Brad King   
2013-10-10 09:00   
Re 0014029:0034096: Oh, and to set path suffixes without relying on the generator name, check the value of CMAKE_SIZEOF_VOID_P:

 http://www.cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_SIZEOF_VOID_P [^]
(0034430)
Benjamin Eikel   
2013-11-11 16:33   
I posted a fix proposal [1]. Please, try if it works for you, if it really fixes your issue, and report back. Then, I will merge it into next.

[1] http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e7e4f05a2a4f3ddeda70493639bb3b0f5b6c573e;hp=13da9f00245694d3dee9f4c9b245f0e3941284c5 [^]
(0034454)
Paul "TBBle" Hampson   
2013-11-17 18:46   
I haven't tested the modules yet, but on brief inspection, SDL_sound probably shouldn't be changed this way as, as far as I can see, there's no current upstream-supplied binary Visual Studio devkit.

The VC6 project files in the source distribution of SDL_sound only produce 32-bit libs, and output into a "VisualC/win32lib" folder. We could probably guess that their 64-bit lib folder would be "VisualC/win64lib" if we want to apply this patch's logic. The headers are in the top-level of the source archive.
(0034455)
Paul "TBBle" Hampson   
2013-11-17 20:10   
I've just tested SDL and SDL_image in my local project, both 32-bit and 64-bit, and they appear to be working fine. I checked the directory layout of SDL_ttf, SDL_net and SDL_mixer's VC-devel packages and they match SDL and SDL_image.

So apart from SDL_sound mentioned above, this looks fine to me.
(0034474)
Benjamin Eikel   
2013-11-18 15:10   
Thanks for the report! I changed the search path for SDL_sound to search for “VisualC/win32lib” [1]. I did not add a search for “win64lib“, because I could not find that string in the VisualC projects of SDL_sound.

[1] http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=057479d3ccaffa7b8423a307554015dbcf23478d [^]
(0034507)
Benjamin Eikel   
2013-11-21 14:17   
I merged the changes to next [1]. Thank you again for your fruitful cooperation!

[1] http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=182974bdb9a7368df3ace0bf5ec2ac0d6abc19bc [^]
(0034508)
Brad King   
2013-11-21 15:31   
I squashed the two fixes into:

 FindSDL: Add additional search paths on MSVC
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96197198 [^]
(0036021)
Robert Maynard   
2014-06-02 08:37   
Closing resolved issues that have not been updated in more than 4 months.