I followed this instruction: https://github.com/jcaden/libnice/blob/master/README.win32 in order to port libnice on Win32. Everything works correctly with version 0.1.4. However, when I tried to port libnice version 0.1.5 and above, I encountered some errors:
Struct _GMutex is an undefined struct.
I can not find file: inttypes.h, which is included in stunagent.c
If you know how to fix it, please tell me.
Thank you very much.
You have asked the same in libnice mailing lists as well and they have answered it. Hope you have ported the libnice version > 0.1.4 in win32.
http://lists.freedesktop.org/archives/nice/2014-May/000846.html
Related
im pretty much new to c++ and im currently making a project where i need to connect to a mariadb database, so I investigated and found the official mariadb connector/c++, but im not sure if this is the way most people go... so if you have a better aproach to conect to a mariadb server using c++, please tell me bellow.
Im also using gradle for my project, so if you know how to solve my issue using gradle i'd be graceful.
Anyway, the issue is that when i follow the official guide
https://mariadb.com/docs/clients/connector-cpp/#building-the-c-application
and compile with
g++ -o app.exe app.cpp -std=c++11 -lmariadbcpp
i get the following:
enter image description here
and got no idea what to do about it.
Again, maybe I'm going the official way, but also the dumb/bad way?, and if not, how could i do it using gradle?
Thank you for your time! ^-^
When compiling whith gcc or g++ for the missing library.
You have to make shure every install command works from the mariadb official guide, since the guide is deprecated and some folders and/or files have changed names, which will cause your install commands to fail.
In my case was the fact that the downloaded file contained lib64 instead of lib as the guide suggests, but keep in mind there may be more...
I set up OpenCV with Code::Blocks as per this tutorial: http://kevinhughes.ca/tutorials/opencv-install-on-windows-with-codeblocks-and-mingw/.
I've got as far as building the test program at the end successfully, but when I try to run it I get the following error: "The application was unable to start correctly (0xc00000be). Click OK to close the application."
The one thing that is certainly different from the tutorial for me is that I'm working with OpenCV 3.0.0, Code::Blocks 13.12 and the latest version of mingw (number not obvious from their website or the installer).
I found that other people had had this problem in the past, e.g. The application was unable to start correctly (0xc00000be)
However, it has been a long time since that thread was active, I'm working with newer versions of the software and, most importantly, the answer given there didn't help (I compiled openCV with the same mingw that I'm using with Code::Blocks), so I thought this question would be worth asking (sorry if it's not, I'm rather new to this).
Could anybody suggest a fix that might get rid of this error?
A few other things to note:
I didn't download the Code::Blocks that came with mingw as I was advised against it, I got them separately as per the tutorial
I have installed OpenCV and Code::Blocks on my E: drive, though mingw is still on my C:.
I have added both mingw and OpenCV to my PATH variable, and mingw to my Path variable
I have linked the libraries in both the main compiler settings for Code::Blocks and the Build Options of my project.
I'm working from a 64-bit Windows 7 Laptop, but I have done everything 32-bit style as advised in the tutorial.
Thanks in advance!
So, one solution I've found to this problem is to copy all the .dll files from "...\opencv\build\x86\mingw\bin" to the project file (build directory).
Having done that, the project will run fine. This still doesn't (directly) explain why it wont run without those files (at least, several sources including the tutorial imply it should), and so isn't really optimal. I will continue to look for a solution for this so I don't have to clutter every opencv project I make with the .dlls.
However, for anyone simply wanting to get stuck into coding who is having this problem, I recommend that solution.
I have been trying out using Eclipse CDT for a course I am taking. Previously I have been using Visual Studio Express but since that requires me to be online and I have to use the IDE+compiler offline, I switched to Eclipse + Cygwin GCC.
Now everything was working prefectly, until I got an error about file paths in my make file. After reading some of the posts online, the issue seemed to be that Cygwin's make does not resolve absolute Windows file paths because of the ':' symbol and confuses it with a new target definition. The proposed fix was to download a fixed make file. I diligently did so and the programs would compile fine.
But after I went into the first debug session, everything froze. I aborted eclipse and tried a clean build but now the compilation wont happen AT ALL, which is very weird for me.
I can't find a post for a similar problem so I am really stuck now. I was currently working the assumption that my CDT may be corrupt or something so I downloaded Eclipse Luna just today and tried building using that, but no joy. Even a fresh project in a new workspace wont compile.
Appreciate the help in advance.
Did you try redownloading Eclipse? Sometimes Eclipse gets a fatal error glitch that makes it unable to compile anything. I've had this problem before, the only way i was able to fix it was to uninstall and re download the latest version. If this doesnt work, try switching to Bloodshed Dev C++ or codeblocks.
So it seems like an issue with the new make (v3.80). upgating it to v4.08 fixed the issue of not building.
Version 4.08 however does not fix the Windows file paths not being recognized properly and treated as a target definition. I am still getting the multiple target patterns. stop error.
EDIT: Found this on Stack overflow to solve the issue... should have searched better previously.
Very simple application fails with "multiple target patterns" from Eclipse
My ultimate goal is to successfully link to a number of DLLs (opengl32.dll glfw.dll and glu32.dll) from a Go package -- but trying to link to the go-glfw package gave me "not defined" errors.
So I decided to get a very simple cgo dynamic/shared library linking to work, from the simple unmodified example in %GOROOT%\misc\cgo\life. But just invoking the command go build -o life main.go fails with essentially the same linker error, namely:
go-build374967034/_/C_/Go/misc/cgo/life.a(c-life.o)(.text): _assert: not defined
"not defined"... just exactly the same error I had when trying to link glfw as per above.
This is a fresh untampered-with install of Go 1.0.1 freshly downloaded this morning, on a vanilla, fairly recent Win7 64-bit installation. What could possibly go wrong? I know... Windows. Would love to hear any ideas... seems like DLL linking with CGO is a no-brainer and simple to do from what I read around the net. Yet even the simplest of examples fails for me.
I've think this particular bug has been discussed here: http://code.google.com/p/go/issues/detail?id=3261
but I'm not sure if it can be applied to your case. In the end from what I've read they proposed a patching but not really tried 'cause I'm waiting 1.1 release (hoping they'll fix the runtime infamous memory leak ;) )
I tried to port some code onto Mac OS X.
The program uses the "ttmath" library, a header big-num header library.
This library works fine on both windows and linux, but when I try to compile and run it on a Mac, the following error message always shows up :
"can't find a register in class 'BREG' while reloading 'asm'".
I found some documents say that this problem is due to the old version of GCC compiler (build 5488), but this message still shows up after I updated GCC.
currently my GCC version is :
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
and the OS is:
Mac OS X version 10.5.8
I can't find any useful information about how to solve this problem, is there anyone can help me? Thanks a lot!
Thanks for DeadMG!
This problem is due to the PIC-safe option.
I added "-mdynamic-no-pic" and "-fno-pic" when I compile the code, and it works fine now :)