I'm using the latest github version from https://github.com/bulletphysics/bullet3
To generate the visual studio solution, I've used the 'vs2010.bat' located in bullet3/build3. This sets it up as static libraries however. If I change the configuration type to dynamic, the .dlls are generated properly, but no .lib-files.
I've also tried using CMake with "BUILD_SHARED_LIBS" enabled, but again, no .lib-files are generated.
What's the proper way of building bullet as shared libraries?
At the moment it is not possible using Visual Studio on Windows to generate import libs (.lib) when using shared libraries for Bullet. The reasons is that no symbols are explicitly exported. Shared libraries work fine using gcc or clang on Linux and Mac OSX. It would require quite a bit of work to instrument the code to fix this issue.
See also https://cmake.org/Wiki/BuildingWinDLL
Related
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
I'd like to build a keyboard layout that runs on Win7 and later without using MSKLC.
I downloaded the Keyboard Layout Samples, and although it says it requires VS2013 Preview and WDK8.1 Preview, it builds using VS2012 and WDK8 after changing the "Platform Toolset" property from "WindowsApplicationForDrivers8.1" to "WindowsApplicationForDrivers8.0".
But: Checking the kbdus.dll built with Dependency Viewer reveals that it imports quite a lot of stuff from kernel32.dlland from msvcr110.dll. This is in contrast to kbdus.dll from the Windows\system32 directory, which, as one might expect, does not import anything and exports one single function.
My first question: Is it an issues that the dll built imports from msvcr110.dll?
I guess it is, as Win7 does not include this dll. (Honestly, I'm wondering how this can be, because these are official Microsoft samples.)
Tweaking around with compiler and linker settings, I managed to get rid of imports from msvcr110.dll, but the dll built still imports a lot of stuff and is quite large (> 70kB), compared to the original kbdus.dll (7kB). It's the same with x86 and x64, Debug and Release builds. I'm looking for the /compileandlinkanddonothingfancy switch.
My second question: How can these dlls be built correctly?
(Note: I found this question, but it is about WDK7. That will be what I try next, if I don't get it with WDK8.0)
I think one should pass /noentry to the linker.
I am atempting to build a Multiplatform desktop application using WxWidegts. As the IDE I am using Codlite. Version info is
Codlite: Revision 5770
WxWidgets: 2.9.4
OS: Windows 7
Compiler: g++
The problem is, after compiling, trying to start the program will give an error that tells me wxbase294u_gcc_cl.dll is missing. I thought maybe its a debug library thing, so I set the build configs to release but still the same error.
My understanding was that Wxwidgets builds nativly to the OS so it shouldn't be dependant on such a large dll. The dll exists in the libs that was installed by Codlite, but the system does not seem to pick it up.
Am I supposed to build using VC++? not sure how to set that on the build settings.
I've been a WebApp guy for a long time and new to Cross-Platform devlopment, so help me out if I'm going the wrong way.
Thanks in advance.
The wxWidgets library code must be linked to your application code. This can be done in two ways: A) to use static libraries, which are linked to your application executable when it is built, or B) to use DLLs, which are linked to your application when it runs.
From your question, you have built your application to use DLLS.
You have two options to fix this problem. Easiest will be to copy the required DLLs into your application folder.
You can also change the codelite options to use wxWidgets static libraries - you will need a codelite expert to help you to do that.
I took a quick look at the codelite webpage. It does look like codelite uses wxWidgets DLLs by default. To change this, you will need to built wxWidgets the "DIY" way as described here but set the SHARED make option to 0
I have installed GCC and GTK+. Its working fine, but i need to statically link GTK+ libraries with my application (it's a small application) so that there exist only one '.exe'.
mingw-cross-env has fixes to build gtk and all related libs statically
It is supported with a few minor issues (like having trouble finding configuration files), but you will have to compile GTK+ yourself! (the default binaries do not include static libraries)
See this mailing-list thread for more information on this issue.
The correct answer would be two words: not supported. Really, if you want to distribute your application, being it 2 or 100000 lines, just bind a copy of GTK+ with it.
I have a DLL project in VS 2008 Pro which uses OpenMP. I use /MT as 'code generation' option, because I want all my dependencies statically linked into my DLL, since I do not want to distribute many libraries to my clients - everything shall be included in this one DLL file. The problem is that my resulting DLL still depends on VCOMP90.DLL.
How can I get rid of this dependency?
Some information:
/openmp is set in compiler options
I statically link against vcomp.lib
include is set
using multithreaded library (/MT)
Thanks a lot for your help!
I don't think you'll be able to get rid of the DLL dependency - vcomp.lib is an import library for the VCOMP90.DLL - it's not a static library:
http://msdn.microsoft.com/en-us/library/0h7x01y0.aspx
It doesn't look like a static lib is provided.