I'm trying to link my XPCOM extension against the 1.9.3a3pre SDK and I get the following:
error LNK2001: unresolved external symbol _moz_xmalloc
So, what lib do I need to link to? The documentation doesn't say.
This is on Windows right now, but I'll need it to build on Mac and Linux (32bit/64bit) as well.
Edit: Now with bounty.
Edit: Update: Turns out FF3.7 was cancelled. So I don't have to worry about this until FF4.
I have same error, and linking to mozalloc helps for that.
define 'XPCOM_GLUE' in C++ Preprocessor Definition property. It will fix the linking error.
Try defining MOZ_NO_MOZALLOC when compiling your extension, you will then get a DLL that uses your CRT's allocators. (Don't forget to use the NS_* allocators for XPCOM-compatible memory.)
Add MOZ_NO_MOZALLOC in C++->Preprocessor->Definition property.
Use xpcomglue_s_nomozalloc.lib instead of xpcomglue_s.lib in Linker->Input->Additional Dependencies
It will be OK!
reminder note: another option that can cause this even though everything else seems to be configured correctly in the project, is pointing at the wrong libs folder - such as 32 bit version for a 64 bit build.
edit v40 mozalloc.lib has changed name to mozglue.lib and has some additional methods.
edit v41 mozglue.lib has changed name to mozcrt.lib
Related
I'm trying to compile a Windows DLL for code originally intended for a Unix platform. One problem I have is that Windows fopen() defaults to O_TEXT, but Unix defaults to O_BINARY.
Windows recommends two ways to solve this:
Use _set_fmode() function, didn't work for me probably because I could not call it from correct context.
Link with binmode.obj object file. This file is included with the compiler, and the compiler knows where to look for it.
The latter worked for my own code, but it does not seem to work for third party static libraries. Looking at the linker output, I can see that static libraries are included before binmode.obj, but binmode.obj was included before my own object files.
The real solution should be to persuade all external libraries to include binmode.obj, but this is somewhat non-trivial and might incur significant maintenance overhead in the future.
So I'd like to try to move the binmode.obj to the beginning of the linker command line, but this proved to be surprisingly difficult. I've tried:
target_link_libraries( mylib PRIVATE binmode.obj ) - Got correct position, but got renamed to binmode.obj.lib casuing linker error.
Tried making a static library with binmode.obj as a pre-compiled object, but got an error that the file has a relative path. I have no idea how to make it a full path.
Tried adding it as a linker flag in different ways, even including using toolchain file, but it all ended up with binmode.obj being placed after libraries.
I'm now out of ideas and feel I need help with this. Any suggestions how to fix this?
#fabian's comment made me read the right part of CMake documentation, which made me realize that UNKNOWN library type could be used. Using the following code in CMake I could make binmode.obj appear before all libraries:
add_library( binmode_obj UNKNOWN IMPORTED GLOBAL )
set_target_properties( binmode_obj PROPERTIES IMPORTED_LOCATION binmode.obj )
target_link_libraries( mylib PUBLIC binmode_obj )
This solved my problem of trying out if link binmode.obj before libraries might fix my original problem. It didn't, unfortunately. But that is another problem...
I am using Asio in a Rcpp package, and am therefore using the package AsioHeaders.
I have added BH and AsioHeaders in the "LinkingTo" part of the DESCRIPTION file of my package. I have also added comments
// [[Rcpp::depends(BH)]]
// [[Rcpp::depends(AsioHeaders)]]
in my code. So normally, the linking should be fine when compiling the package.
And it is when I compile it on Linux. But when trying to compile it on Windows, I get linking errors that are solved by linking -lws2_32 and -lwsock32.
I am thus wondering, whether I should edit the Makevars file so that these are linked on Windows but ignored on Linux, or if I have done something wrong using AsioHeaders?
AsioHeaders maintainer here. Quick questions:
Which version of AsioHeaders? It just updated at CRAN. Is this a change from the new version (which would suprise me ...)?
Make sure you are not accidentally using Asio functionality from Boost which will require linking. See the three packages using AsioHeaders.
If your package is truly header-only then LinkingTo: is all you need. R will find the header directories for you. In particular, you do not need link instructions in src/Makevars* because, well, header-only.
Also, you probably meant // forward slashes for your C++ comments above...
I can't, for the love of God, to static link the ZLIB libs. I have been struggling for a couple hours now with no success. Well, I have followed this tutorial and successfuly compiled both zlibstat.lib and zlibwapi.lib for 32 bits. After setting up my project to use the ZLIB folder with the libraries (Linker > General > Additional Library Directories) and setting zlibwapi.lib (only) as an dependency (Linker > Input > Additional Dependencies) I got it to work, however, that was a dynamic link (I need to distribute my application with the ZLIB dll). I usually use dynamic linking on Debug and static on Release.
I have tried looking for what the hell is the zlibstat.lib and whats it used for, if not for static linking, assuming the "stat" suffix.
Are there any preprocessor to be added into my project, something like ZLIB_STATIC or something, to use static linking of ZLIB or should I have never removed the ZLIB_WINAPI from the zlibstat project, just like the above link told me to do? Is it impossible to static link ZLIB (then, whats zlibstat.lib for?)?
I am pretty lost. Any help is GREATLY appreciated.
Edit (Extra information):
Errors:
error LNK2001: unresolved external symbol _inflateInit_#12
error LNK2001: unresolved external symbol _inflate#8
error LNK2001: unresolved external symbol _inflateEnd#4
Linking:
Unlike the dynamic link (that worked) where I added zlibwapi.lib as a dependency, for the static linking I'm trying to achieve I added zlibstat.lib as a dependency instead! No other libs were added!
This question might look like this (kind of).
I have finally managed to solve my problem. For those that end up in such a problem, heres how to solve it:
If you followed the tutorial in my first post, you would have removed ZLIB_WINAPI from the zlibstat project's Preprocessor. However, after setting up my own project (setting ZLIB dependencies path, LIB dependencies libraries etc) that uses ZLIB, I 'accidently' included/defined the damned ZLIB_WINAPI macro in the header file I'm using ZLIB, right before including "zlib.h".
One curious thing about this is that when launching the app on debug mode (which was using dynamic linking), everything succeeded and worked like a charm, without any warnings or whatsoever, HOWEVER, on release mode (which was using the static linking), it crashed.
So, to clear things up, the tutorial tells us to remove the ZLIB_WINAPI preprocessor from the zlibstat project, which produces the static lib, whilst the zlibvc project has the ZLIB_WINAPI in its preprocessor. In other words, that means that if we're using different linkings for each configuration (debug/release), we have to add the ZLIB_WINAPI macro or not!
Define the ZLIB_WINAPI macro before including "zlib.h" if youre using dynamic linking (zlibwapi.lib) and that the zlibvc project remains unmodified (assuming you correctly followed the tutorial from the link above) and do not define it if you removed ZLIB_WINAPI from the zlibstat project (like the tutorial tell us to)!
One helpful macro I used on my own project is as follows:
// Since we used dynamic linking for debug, we have to define the ZLIB_WINAPI
#if defined(_WIN32) && defined(_DEBUG)
#define ZLIB_WINAPI
#endif
#include <zlib.h>
Things got really confusing and I really hope I was clear enough.
I'm having a weird problem when trying to register the .dll i created using regsvr32.
During development everything went fine, the debug version registers and works fine. Now i wanted to create a Release version, but that Version does not register anymore.
regsvr32 comes up with the following error:
The module "mpegsplitter.dll" failed to load.
Make sure the binary is stored at the specified path or
debug it to check for problems with the binary or
dependent .DLL files.
The specified procedure could not be found.
Some research brought me to the dependency walker, which does tell me this
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
It also does show a dependency on "crtdll.dll" that the debug version does not have (The function view shows soem functions that normally should be in ole32.dll), which is colored red'ish.
So far so good, i guess its somehow related to what the dependency walker shows there.
But where do i go from here? How do i fix it?
Any help would be greatly appreciated, that has been keeping me busy for several hours already.
Thanks!
I have the same problem. When I compared the different between "Command Line" (in Project Properties -> Linker) of Release and Debug mode, I found out that the "Optimization" options (in Project Properties -> Linker) of Release mode was turned on while ion Debug not.
Turning of Optimization for linker in Release mode solved the problem
Is it possible that the debug version is compiled with _ATL_MIN_CRT but the release version isn't? You can set this with the Minimize CRT Use in ATL project property as well.
I fixed it. It was actually being caused by the order of some mingw libraries i included to link against ffmpeg. Oh well, how weird.
In my case, the difference was in Module Definition File entry between DEBUG and RELEASE. The DEBUG version was pointing to the .DEF file where as the RELEASE had it empty.
I'm trying to test out a library that provides a VC++ example; however, I use gcc/g++ for all of my projects.
Well, the way the VC++ example accesses the library is it uses the #import directive, passing the location of the library DLL, then it does a using namespace LIBRARYNAME, and then it's able to create some undefined type (I'd assume it's defined in the DLL) and create a new instance of it with __uuidof. From then on, to call one of the library functions the example just does a createdObj->foo() and that's that.
Well... g++'s #import is different from VC++'s import (see here), so this example won't work for me.
Is there any way this can be converted to compile under g++, or am I SOL until the library developer provides me with a static library I can try out?
If you are using cygwin, then this page: http://www.cygwin.com/cygwin-ug-net/dll.html will provide you with all the help you need.
If you are using mingw, you can accomplish the same thing, but you probably won't have grep and sed, so you'll have to use some other method of doing the filtering to get your .def file.
If you were using #import in VC++ it means the DLL isn't a regular DLL, it's a COM DLL.
Since gcc doesn't have COM support, you'll just have to wait for the library author to write a non-COM version.
Maybe it could have helped you to use the OLEViewer and "View type information" to extract the basics of the IDL. Or maybe you could just use the VC++ generated .tlh and .tli files and import them into your G++ project.
I guess this answer is way too late, but right now I'm encountering similar issues myself so I just got into this thread. Hope you found the solution on time.
Regards.