I have the projects setup as described in the readme, and have GLib 2.28.8 installed and compiling. When I get to compiling gstreamer, I get thousands of errors that indicate to me that something is wrong with the build setup or with GLib versions. I couldn't find an easy source of other GLib versions for windows (I've tried both the dev and sources version of GLib here: http://www.gtk.org/download/win32.php ).
The first compile error is:
...\build\gstreamer-1.0.5\gst/gstobject.h(170): error C2079: 'lock' uses undefined struct '_GMutex'
In gstobject, lock is defined as:
GMutex lock; /* object LOCK */
Which Visual studio finds as defined in gthread.h
typedef struct _GMutex GMutex;
So everything looks fine to me, but maybe I'm overlooking something. glibconfig.h also defines _GMutex* as GStaticMutex, could that be interfering?
I am using glib.2.28.8, also encountered the same problem. The following two threads (1 and 2) also discuss the related problem.
In my case, just add
struct _GMutex
{
/*< private >*/
gpointer p;
guint i[2];
};
before
struct _GMutex GMutex;
Maybe you should try to update your Glib to 2.32.0
I successfully build GStreamer-1.0.5 both on Linux and Windows Xp, with Glib 2.32.4
See configure.ac
dnl GLib
GLIB_REQ=2.32.0
AG_GST_GLIB_CHECK([$GLIB_REQ])
Related
I've just "upgraded" MSVC2015 to Update 2 and encountered boost::asio issue 12115...
I'm glad to say that the workaround described in boost issue 12115 i.e. removing service_has_move from line 43 of basic_io_object.hpp works fine to change:
#if defined(BOOST_ASIO_HAS_MOVE)
...
static const bool value =
sizeof(service_has_move::eval(
static_cast<service_type*>(0),
static_cast<implementation_type*>(0))) == 1;
...
#endif // defined(BOOST_ASIO_HAS_MOVE)
to
#if defined(BOOST_ASIO_HAS_MOVE)
...
static const bool value =
sizeof(eval(
static_cast<service_type*>(0),
static_cast<implementation_type*>(0))) == 1;
...
#endif // defined(BOOST_ASIO_HAS_MOVE)
I'm not a great fan of editing libraries, especially not boost!
So can someone please tell me whether this is actually a boost issue or whether the issue is MSVC2015 changing it's move behaviour in Update 2?
FYI, the original code compiled and worked fine under MSVC2015 Update 1 and MinGW 4.9.2 (on Windows 10) and GCC 5.3.1 (on Fedora) using both boost 1.60.0 and 1.61.0.
I'm currently using boost 1.61.0 but boost issue 12115 was raised on boost 1.60.0.
I think it's pretty obvious who is at fault. If you had to delete something in boost to fix this, then boost is at fault, no? The macro BOOST_ASIO_HAS_MOVE is defined based on compiler detection in the boost config header(s). Obviously when you updated, the compiler version and other info that these headers relies on was not a match, so the namespace you had to delete was not defined.
There are many references to using i2c_smbus_ functions when developing embedded Linux software to communicate on the I2C bus. When i2c_smbus functions such as i2c_smbus_read_word_data are referenced in software project for ARM8 processor errors such as ‘i2c_smbus_read_word_data’ was not declared in this scope are generated at compile.
Investigation of the following header files indicate the absence of most i2c_smbus function definition.
/usr/arm-linux-gnueabi/include/linux/i2c.h
/usr/arm-linux-gnueabi/include/linux/i2c-dev.h
Also in that following reference i2c.h file has all the i2c_smbus defined.
How can this problem be resolved?
Research references
Using I2C from userspace in Linux
I2C Communication from Linux Userspace – Part II
I2C dev interface
Because you are using a wrong header file for your application.
If you see an extern on the function i2c_smbus_read_word_data() in your header, it's a header file for your kernel, but not for your application. The Linux kernel has i2c_smbus_read_word_data() and other i2c smbus functions for its internal use. But they are a) not system calls, or b) not accessible from your application.
Instead, get i2c-tools from Linux Kernel Wiki and install it. If you are using Debian, just
sudo apt-get install libi2c-dev
and use i2c_smbus_read_word_data() or any other interfaces they offer.
Version Notes
i2c-dev, untill version 3.x, used be a header only package, meaning that there was no library to link to. All functions were inline functions defined using ioctl().
e.g.)
static inline __s32 i2c_smbus_access(int file, char read_write, __u8 command,
int size, union i2c_smbus_data *data)
{
struct i2c_smbus_ioctl_data args;
args.read_write = read_write;
args.command = command;
args.size = size;
args.data = data;
return ioctl(file,I2C_SMBUS,&args);
}
:
static inline __s32 i2c_smbus_read_word_data(int file, __u8 command)
{
union i2c_smbus_data data;
if (i2c_smbus_access(file,I2C_SMBUS_READ,command,
I2C_SMBUS_WORD_DATA,&data))
return -1;
else
return 0x0FFFF & data.word;
}
But since v4.0, it start to be a standard shared library with libi2c.so.0 and i2c/smbus.h. You have to include the header file in your source code
#include <i2c/smbus.h>
And link libi2c.so.0 with -li2c
gcc -o a.out main.o -li2c
I ran into this today. The i2c_smbus_* functions are defined in:
/usr/include/linux/i2c-dev.h
...but when I would try to cross-compile for ARM on an older version of Ubuntu, I was running into errors such:
i2c_smbus_read_block_data was not declared in this scope
Turns out the functions are not defined in the equivalent ARM-specific location:
/usr/arm-linux-gnueabi/include/linux/i2c-dev.h
When cross-compiling, this 2nd older header file is the one used. Had to re-declare locally a few of the inline i2c_smbus_... functions to get around the problem.
Based on https://unix.stackexchange.com/questions/621854/usr-include-linux-i2c-dev-h-does-not-contain-i2c-smbus-read-word-data-functio, I have found this fixes the function not defined errors:
#include <i2c/smbus.h>
I am currently working with legacy code that references various i2c_smbus functions. It has:
#include <linux/i2c-dev-user.h>
and it fails to compile. Surely, this include used to work, but it seems the lib's header files changed at some point. I did refresh/reinstall libi2c-dev recently.
Note that I added the above include. I can't remove the original include. It is still needed.
FYI: I have not tried cross-compiling yet.
From the i2c Linux kernel documentation:
Please note that there are two files named "i2c-dev.h" out there, one is distributed with the Linux kernel and is meant to be included from kernel driver code, the other one is distributed with i2c-tools and is meant to be included from user-space programs. You obviously want the second one here.
So you need to include the i2c-dev.h from i2c-tools not from the Linux kernel.
I have installed boost_1_54 on windows by checkout from svn and then
bootstrap
.\b2
QuantLib library dependent on boost compiles well all but one project: test-suite which uses BOOST_MESSAGE. this is undefined. I can see that there is no BOOST_MESSAGE in my version of boost.
Therefore is this QuantLib incompatibility or have I missed something?
On my linux boost version the same thing applies to BOOST_MESSAGE - it is undefined
I have seen this but I am not sure how to interpret this.
I'm afraid you gave us more credit than we deserved :)
We haven't compiled QuantLib against Boost svn yet. The latest I've tried is Boost 1.53 (the latest released version) in which BOOST_MESSAGE was still available.
Thanks for the heads-up, though. I'll patch the library so that it's ready for next version. As mentioned in the comments, it should be as simple as adding
#if BOOST_VERSION > 105300
#define BOOST_MESSAGE(msg) BOOST_TEST_MESSAGE(msg)
#endif
to test-suite/utilities.hpp.
on linux I had to add
libboost_unit_test_framework.so
to the Linker->Libraries and
#include <boost/test/unit_test.hpp>
#define BOOST_MESSAGE( M ) BOOST_TEST_MESSAGE( M )
is already present in test/test_tools.hpp.
on windows I have different #defines and this is not present, so I added it to the
unit_test_log.hpp
where BOOST_TEST_MESSAGE is defined (in boost files to avoid same issue again in the case of other applications using BOOST_MESSAGE).
BOOST_MESSAGE issue resolved but still can't disambiguate
const void* = boost::test_tools::check_is_close
and
const void* = boost::test_tools::check_is_small
because these are templates. so the solution is to remove it (test-suite compiles well) or use appropriate pointers to function templates
on Windows, after romoval or function
_use_check
in utilities.hpp
changed to not have pointers to TEMPLATE functions as default, so changed to:
void _use_check(
const void*,
const void*) const {}
there were still errors while building test-suite project. unresolved externals: fdmhestonfwdop, fdmblackscholesfwdop, fdmsquarerootfwdop. obviously this classes (headers+source) I had to add to Quantlib project, build library QuantLib-vc110-mt-gd.lib again and rebuild test-suite project then.
after pleasure with VS linker error "lnk1210 exceeded internal ilk size limit link with incremental no" (it really likes RAM, but on windows I have this resource quite limited), it is OK. compiled. : p
I am getting run time crash in the following piece of code and not able to debug also. Please review and let me know what's going on.
// CppConsole.cpp : Defines the entry point for the console application.
//#include "stdafx.h"#include <iostream>#include <assert.h>
class Test : public std::tr1::enable_shared_from_this<Test>
{
public:
Test():x(0),y(0),z(0){};
int x;
float y;
double z;
};
int _tmain(int argc, _TCHAR* argv[])
{
std::tr1::shared_ptr<Test> t1(new Test);
std::tr1::shared_ptr<Test> t2 = t1->shared_from_this();
return 0;
}
I have include all the headers and the program is compiling fine. This is the error i am getting:
CppConsole.exe - Entry Point Not Found The procedure entry point
?_Xweak#tr1#std##YAXXZ could not be located in the dynamic link
library MSVCP90D.dll
If I comment out this line
std::tr1::shared_ptr t2 = t1->shared_from_this();
the program runs without crashing.
Update: Question can be closed for now. I will try to install VS feature pack and see weather the program executes without any crashes.
Googled it (The procedure entry point ?_Xweak),found this : http://blog.nilretain.org/
EDIT : I Build and Run it successfully on my msvc 2008 on xp-sp3 ,which has later version of msvcp90d.dll.
Maybe you can download and install the latest redist-version of msvc90 and rebuild.
EDIT: your dependencies says something is missing. check this out :
http://answers.yahoo.com/question/index?qid=20090623140325AAInugo
You need a template argument:
std::tr1::shared_ptr<Test> t1(new Test);
std::tr1::shared_ptr<Test> t2 = t1->shared_from_this();
The compiler should report an error if it is not present. (Visual C++ 2010 does)
It appears that your compiler is not linking against a DLL with the needed runtime functions. For instance, if you added the headers to your include path, but don't link to the latest version of the C++ runtime (check your project's settings), or installing the Visual C++ 2008 feature pack didn't work, or you installed the feature pack but then tried to compile from Visual Studio 2005, etc.
Basically the "process the source code (including headers)" step is working fine, but the "link all the DLLs" step is failing. And it's failing because the runtime you're linking against doesn't have the needed functions for shared_ptrs or weak_ptrs.
I had this problem when developing under M$ Windows SP3 with M$ Visual Studio 2008. I tried and combined many hints that I could find on the web. To no avail. The solution was simple, I had to install SP1 pack for M$ Visual Studio 2008!
The thing is that my external DLLs used C++ TR1 functions that I was not aware of. The M$ Visual Studio 2008 without SP does not have the right runtime DLLs.
So, just make sure you have that SP1 for your M$ Visual Studio 2008 first before trying any other solution.
I need to update boost libraries to version 1_46, currently Rad Studio XE/2010 have 1_39 version. When I try just to overwrite boost include path compile fails with various errors from Borland VCL. When i try to add new boost libs in other path keep previous version it also fails with compile condition errors when constructing std::* classes.
I need shared_memory_manager support that is available only in new boost versions. Is there any other ways to upgrade boost libraries or use shared memory that will be available to same processes?
Compilation errors when compiling with new boost version only:
[BCC32 Error] bad_weak_ptr.hpp(44): E2113 Virtual function 'bad_weak_ptr::what() const throw()' conflicts with base class 'std::exception'
[BCC32 Error] xlocale(953): E2228 Too many error or warning messages
There are dozens of locations inside of boost which check the compiler version in order to determine whether or not certain workarounds are needed. (checking against both __CODEGEARC__ and __BORLANDC__) You need to test each of these and update the version number as appropriate. Also there are a number of defines set inside the config/compiler/codegear.hpp file (typically BOOST_HAS_* and BOOST_NO_*) which you also need to turn on/off for different versions of the compiler.
It is a very tricky and time consuming process.