8000 Build on Windows platforms needs different shared library targets · Issue #35 · kahypar/kahypar · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Build on Windows platforms needs different shared library targets #35< 8000 /span>

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
franklist opened this issue Jan 8, 2019 · 2 comments
Closed

Build on Windows platforms needs different shared library targets #35

franklist opened this issue Jan 8, 2019 · 2 comments

Comments

@franklist
Copy link

When trying to build this on a Windows platform, I came across the following error, which you can also see on your failing Windows build on appveyor linked on the main github page for this project

CMake Error at lib/CMakeLists.txt:13 (install):
  install Library TARGETS given no DESTINATION

This appears to be because of the following lines:

install(TARGETS kahypar
		LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
		PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})

The catch seems to be that shared library targets have to be handled differently depending on the platform. The CMake documentation reads:

For non-DLL platforms shared libraries are treated as LIBRARY targets, except that those marked with the FRAMEWORK property are treated as FRAMEWORK targets on OS X. For DLL platforms the DLL part of a shared library is treated as a RUNTIME target and the corresponding import library is treated as an ARCHIVE target. All Windows-based systems including Cygwin are DLL platforms. The ARCHIVE, LIBRARY, RUNTIME, and FRAMEWORK arguments change the type of target to which the subsequent properties apply.

I was able to get it to build on my machine based on this StackExchange post by changing the code as follows:

if(WIN32)
	install(TARGETS kahypar
		RUNTIME DESTINATION ${CMAKE_INSTALL_LIBDIR}
		PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
else()
	install(TARGETS kahypar
		LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
		PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
endif()

I don't have much experience with CMAKE so I can't guarantee this fix will work for everyone. I also ran into an issue with the Windows build where I had to adjust the linking behavior for boost (with add_definitions(-DBOOST_ALL_NO_LIB) ), but I won't create a new issue for it until I'm sure it wasn't accidentally created by this fix of mine.
@SebastianSchlag
Copy link
Member

Thank you very much for opening up this issue and giving a concise problem description/solution.

I actually haven't looked at the windows build for quite a while, because the tests were too slow on the appveyor builds, which lead to build timeouts all the time.

Did you have to add the "-DBOOST_ALL_NO_LIB" for all targets, or only for the kahypar library?

I am currently travelling. I will take a look at this when I am back in Germany next week.

@franklist
Copy link
Author
franklist commented Jan 9, 2019 •
edited
Loading

The other issue with the libraries that I found was encountering an error similar to the following:

fatal error LNK1104: cannot open file 'libboost_system-vc90-mt-gd-1_44.lib'

Which was odd because the CMake configuration included an absolute path to the problematic file, which did exist. I found the suggestion here that it was due to "interference with the auto-linking". A possible solution is to add the following two lines to kahypar\CMakeLists.txt. (adding just the first line alone would result in an "unresolved external symbol boost::program_options..." error). I added them right below the "find_package(Boost" command

  add_definitions(-DBOOST_ALL_NO_LIB)
  add_definitions(-DBOOST_PROGRAM_OPTIONS_DYN_LINK=1)

This is the only place I had to make this definition change.

I don't have enough knowledge of CMake processing to know whether this is a separate issue or caused by the change to a runtime library. I also don't know if this change to boost dynamic library linking would have unintended consequences.

I don't need a fix implemented in the main branch by any deadline so don't worry. I'm just sharing what I needed to do to get the build working on my system.

SebastianSchlag pushed a commit that referenced this issue Jan 16, 2019
addressing boost linking issues on windows
e0e789f 
The fixes proposed in issue #35 do not seem
to interfere with linux builds and make KaHyPar
usable again on windows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@SebastianSchlag @franklist
0