Skip to content
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.

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

dll vs static build issues on Windows #103

Closed
tksharpless opened this issue Apr 19, 2016 · 8 comments
Closed

dll vs static build issues on Windows #103

tksharpless opened this issue Apr 19, 2016 · 8 comments

Comments

@tksharpless
Copy link

Twin problems currently prevent using glog on Windows:
1] cmake offers no option to build a dll, creates only a static build
2] glog headers all assume a dll ("__declspec(dllimport)"), there is no check for static. So linking with the static library fails.

@tksharpless
Copy link
Author

It is possible to build a dll using the readymade MSVC projects. But not to link glog statically.

@tksharpless
Copy link
Author

BUT the readymade projects won't build 64-bit without modification. [AAARRRGH]

@sergiud
Copy link
Collaborator

sergiud commented Apr 20, 2016

Actually, CMake does offer an option to build DLLs: https://cmake.org/cmake/help/v3.5/variable/BUILD_SHARED_LIBS.html. This option applies to CMake enabled glog as well.

@sergiud
Copy link
Collaborator

sergiud commented Apr 20, 2016

By the way, as I'm aware that you are trying to build Ceres with glog on Windows, I must note that this is in fact possible. However, this requires minor changes in Ceres' CMakeLists.txt. See cmake/INSTALL.md how to use the CMake version of glog.

@tksharpless
Copy link
Author

Thanks Sergiu,

Are you telling me I could get a dll build of glog just by setting a cmake
variable? Then why not offer that option as a checkable item in your cmake
script (I use cmake-gui on Windows and will not edit scripts unless there
is no other way).
I have been able to build ceres with the static glog libraries that the
as-distributed cmake setup makes.
But only by changing this bit of logging.h:

// Annoying stuff for windows -- makes sure clients can import these functions

/// even if they want to use the static library! -- TKS

#ifndef GOOGLE_GLOG_DLL_DECL

if defined(_WIN32) && !defined(CYGWIN)

ifdef GLOG_STATIC

define GOOGLE_GLOG_DLL_DECL

else

define GOOGLE_GLOG_DLL_DECL __declspec(dllimport)

endif

else

define GOOGLE_GLOG_DLL_DECL

endif

#endif

Now defining GLOG_STATIC in all builds does the trick.

-- Tom

On Wed, Apr 20, 2016 at 5:27 AM, Sergiu Deitsch notifications@github.com
wrote:

By the way, as I aware that you are trying to build Ceres with glog on
Windows, I must note that this is in fact possible. However, this requires
minor changes in Ceres' CMakeLists.txt. See cmake/INSTALL.md
http://../tree/master/cmake/INSTALL.md how to use the CMake version of
glog.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#103 (comment)

@sergiud
Copy link
Collaborator

sergiud commented Apr 21, 2016

@tksharpless That's correct. Just by calling CMake using ``cmake -DBUILD_SHARED_LIBS:BOOL=ON` will generate a Visual Studio solution that produces DLLs. Unfortunately, CMake chose not to provide a default cache entry for the option which would allow to modify it via cmake-gui. But you can add the option yourself using the above command line call. As a side note, Ceres works with static glog as well.

@dashesy
Copy link

dashesy commented Aug 8, 2017

When I use this

cmake .. -Dgflags_DIR=/c/devel/gflags/tmp/ -DBUILD_SHARED_LIBS=1

To build glog shared library on Windows I get this error when I try to build the solution:

1>c:\devel\glog\src\stacktrace_windows-inl.h(42): error C2375: 'google::GetStackTrace': redefinition; different linkage

That line is this:

    GOOGLE_GLOG_DLL_DECL
    int GetStackTrace(void** result, int max_depth, int skip_count) {

During build it must be export, during usage it must be import. I think GOOGLE_GLOG_DLL_DECL definition is not complete.


Edit: This error is the current master. The release v0.3.5 compiles fine

@sergiud
Copy link
Collaborator

sergiud commented Aug 8, 2017

@dashesy I can confirm the problem. Can you please create a new issue since this problem is unrelated to the one of the original author? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants