I am trying to use LAME in Unity3d on OS X with Mono c#. I dragged the Lame_enc.dll in but when the wrapper tries to find it, it doesn't and i get
DllNotFoundException: Lame_enc.dll
Yeti.MMedia.Mp3.Mp3Writer..ctor (System.IO.Stream Output, WaveLib.WaveFormat InputDataFormat, Yeti.Lame.BE_CONFIG Mp3Config) (at Assets/Helping Libraries/Lame/Mp3Writer.cs:82)
The problem from what i see, it when i try to 'link' some static methods to the dll:
[DllImport("Lame_enc.dll")]
public static extern uint beInitStream(BE_CONFIG pbeConfig, ref uint dwSamples, ref uint dwBufferSize, ref uint phbeStream);
I know that in order to see dll, on Windows, the dll needs to be in the same folder as the .exe file, but Unity being a multiplatform solution, i don't know how i can tell it where it is.
I've placed the dll in my project root folder, in the Library, in the Editor, but no luck!
Just remove the ".dll",it will work well in Editor,but won't work on mobile phone.I removed the using xxx.window and some unused files,but still the output file xx.mp3 only has 44B.
Related
I am making a computer app in C++/CLR and I just hit the wall. I'm loading the dll using the loadlibrary function and I am able to call the functions too but when I try to send a parameter for example if my function is:
std::string msgbox(std::string str)
{
MessageBoxA (0,str.c_str(),"TiTle", MB_OK | MB_ICONINFORMATION);
return str;
}
In a native c++ app when I call the function after loadlibrary and getprocaddress
std:: tmp = msg ("String");
tmp becomes "String"; and I see a Message box with String as the message but if I use C++/CLR I get like some rubbish while printing the message content in the message box if I pass in a parameter and the tmp variable would contain some trash text too how can I just load it the same way as I am doing but without this trash in the way
This is the output and the source code too:
Source: https://uploadfiles.io/itm93
Error images: https://imgur.com/a/WM7MK4c
It looks like you are compiling your c++ dlls with gcc. You can't pass standard library types between DLLs/applications compiled against different standard libraries.
You either need to compile everything with visual studio (and the same runtime library, you can't mix debug/release or the static/shared runtimes) or only pass raw character pointers over dll boundaries.
I'm migrating an old OWL application to MFC. there were a main library that has the main dialogs and controls , I started writing an alternative classes of MFC to the old OWL like TDialog[inherits from CDialogEx], TEdit..... I added all the needed classes from the OWL now my library build successfully.
I created a new MFC Application [to test the library], i exported a function [SowDialogue] from the dll to be used in the Application , I added the .lib of dll to the MFC application, I called the function to show a simple dialog , the build go successfully, but at the first start the application fail with the following message
I clicked retry and the break to get the line that caused the assertion it was that one
So the problem is with the resources. when i link with the library the MFC can't get the right resources module.
I thought it was because i use a regular dll that uses MFC and shares MFC objects, if i must use an MFC extension library. how can i convert regular library to MFC extension library.
Or any solution to this disaster after a long work
EDIT
this is the call stack, there are no exported functions in this, its all in the application the error come before calling anything from the dll
Solution
the problem was solved when i converted the dll to an MFC extension library, really i created a new mfc extension dll and cheated it's properties, the dll main, the stafx includes and preprocessors definisions
static AFX_EXTENSION_MODULE MFCExtensionDLL = { NULL, NULL };
extern "C" int APIENTRY DllMain( HINSTANCE hInst, DWORD fdwReason, LPVOID)
{
if (fdwReason == DLL_PROCESS_ATTACH)
{
TRACE0("MFCExtension.DLL Initializing!\n");
// Extension DLL one-time initialization
if (!AfxInitExtensionModule(MFCExtensionDLL, hInst))
return 0;
new CDynLinkLibrary(MFCExtensionDLL);
//My initialization code
return 1;
}
else if (fdwReason == DLL_PROCESS_DETACH)
{
// Terminate the library before destructors are called
AfxTermExtensionModule(MFCExtensionDLL);
// my finalization code
return 1;
}
}
the properties
in the properties of project->configuration properties->general Use of MFC = Use MFC in a Shared DLL
,
in the properties of project->configuration properties->C/C++->Preprocessor->Preprocessor Definitions->add _AFXEXT , make sure to delete _USERDLL if it exists
When using MFC in a .dll, you have to make sure that the .dll can find resource handles for things like strings and bitmaps in the .rc file. MFC maintains an internal state for each .dll that points to the resources for that .dll. When calling into that .dll from an application (or another .dll) you have to 'help' MFC get the internal state right or it will not be able to find your resource and will ASSERT.
I can't see the function immediately below the one in the call stack in your example, but if it is an exported function, the MFC state problem is likely what is going on.
Make sure you have put the AFX_MANAGE_STATE macro at the top of any functions accessible from outside (exported functions). That will go a long way to solving your problems.
Microsoft reference: http://msdn.microsoft.com/en-us/library/ba9d5yh5(v=vs.80).aspx
If you use resources or windows from a dll file, you can try this way. This code can be in the dll itself. Whenever the resource is created the current resource handle of the main process will be set as the dll's resource handle and use the handle.
After any window creation or resource change revert it back to the old value.
hdllresource = ::LoadLibrary(<dllfile containing the resource>);
hcurrentInst = AfxGetResourceHandle();
AfxSetResourceHandle(hdllresource );
//do your window creation or resource loading stuff
AfxSetResourceHandle(hdllresource);
I'm following the book of Programming in Objective-C by Stephen G. Kochan. I was trying the code and to improve the class example by myself. I opened a project in Mac OS X / Applications / Command Line Tool and the program executes successfully.
When I opened the project as IOS / Framework & Library / Cocoa Touch Static Library, XCode separates class and implementation files normally. When I try to compile, XCode says it has built successfully but there is no output in the console.
I just followed the book and I am sure there is nothing wrong about Class or the implementation files. "NSLog(#""); files stays in there". According to the book, files are separated by 3:
Interface Part (class part)
Implementation Part (Which instances located in)
int main (int argc, char *argv[]) part.
But when I open the project as cocoa-static library, I get only 1 *.m file. I cannot add any additional *.m file with add -> new file.
My question is, is there any relative problem with my file structure that I am working on? Should I need also separate implementation part and the main part?
I would really appreciate if someone could help with this probelem. I really got stuck and having struggling to proceed next step of the book because I can not try code examples anymore...
Sounds like you're trying to run a static library project. You can't do this - you need to make an app that uses your static library to be able to run at and see the output.
Code:
struct IRenderingEngine {
virtual void Initialize(int width, int height) = 0;
virtual void Render() const = 0;
virtual void UpdateAnimation(float timeStep) = 0;
virtual void OnRotate(DeviceOrientation newOrientation) = 0;
virtual ~IRenderingEngine() {}
};
Learning opengles from a book for 3d iphone programming and it uses this example code but the book is targeted for xcode 3.x
Somehow I feel like its something with xcode 4....
EDIT:
Heres the actual error:
/Users/Dan/Documents/opengles/Hello Arrow/Hello Arrow/IRenderingEngine.hpp:27:2: error: unknown type name 'virtual' [1]
And that legitamtely is all that it takes to fail to compile, absolutely no other files. (Yes I've tried compiling with literally a main.m and this hpp file)
It is recognizing the hpp file as a cpp header file though, if I try to add it to the compiled files it says that "no rule to process file '$(PROJECT_DIR)/Hello Arrow/IRenderingEngine.hpp' of type sourcecode.cpp.h for architecture i386" so I really have no idea what is going on
Note that I compiled with main.m meaning I compiled another Cocoa/Foundation based application
I tried compiling for a c++ application and everything worked out just fine....
Similarly compiling with a main.mm test file worked fine too
heres the actual project, lemme know how insane I really am:
[Removed considering I lost the file]
Please rename the main.m to main.mm. This worked for me.
If you're using Xcode 4, try changing the name of file "AppDelegate.m" to "AppDelegate.mm". It works for me.
Changing the name of file "AppDelegate.m" to "AppDelegate.mm". It's correct!
I moved the #import "IRenderingEngine.hpp" line from the GLView.h file to the GLView.mm - this prevented it from being imported into the main.m and HelloArrowAppDelegate.m files when they were compiled - and restricted the import into the .mm file, that could handle the C++.
I also had to make a couple of other fixes for bugs I'd introduced when typing in the code - so apologies if that wasn't the only thing that needed to be done, but it might help those with similar problems!
if you call C++ files ( even if you only import them ) you need to change the .m file that call's it to .mm
This is just a stupid guess since I've never tried compiling something with the word virtual in a C compiler... but is there any chance that you were trying to compile this C++ code as C code? That's the only reason I can think of that a compiler wouldn't understand the keyword virtual.
The header <stdlib.h> is not the right one to use in a C++ program. When I replaced it with the c++ version of C's stdio library <cstdlib> then your code compiled for me.
I have a header file that is included by both a native cpp file and a managed cpp file(compiled with /clr). It includes only native types, but I want to specify that the native types are visible outside the assembly
(see http://msdn.microsoft.com/en-us/library/4dffacbw(VS.80).aspx).
Essentially, I want:
public class NativeClass // The public makes this visible outside the assembly.
{
};
If I include this code from a native cpp, I get the following error:
error C3381: 'NativeClass' : assembly access specifiers are only available in code compiled with a /clr option
Attempted solution:
I'm currently using a preprocessor solution that causes the public to appear when compiling with the managed client, but it does not appear for the native client:
#ifdef __cplusplus_cli
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public public
#else
#define CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
#endif
CLR_ASSEMBLY_ACCESS_SPECIFIER__Public
class NativeClass
{
};
Question:
Is this the appropriate way to achieve this, or is there a better way?
Have you tried the make_public pragma listed on the MSDN page you linked to?
Otherwise, the solution you have is perfectly valid. I'm curious to know why you want to export native types from a CLR assembly though.