|
|
I could use some assistance deciphering enclosed "make" output.
I like to start with "In file included..."
The last number is probably source line (?)
Does the sequence tells the "hierarchy " of the headers (?)
Is there a single source of error - "error: size of array" (?)
I am not asking for solution, I just need some guidance to logically analyze the output and correct the error.
Thanks
Cheers
Addendum
Does
/usr/include/glib-2.0/glib/gtypes.h:422:3: note: in expansion of macro 'G_STATIC_ASSERT'
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
tells me to look at definition of G_STATIC_ASSERT (?)
Do I understand correctly that notes " note:...." being added by make are not necessarily in some relation / sequence and can start debugging from any place?
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$ sudo make
make --no-print-directory all-am
CC lib/bluetooth.lo
CC lib/hci.lo
CC lib/sdp.lo
CCLD lib/libbluetooth.la
CC lib/uuid.lo
CCLD lib/libbluetooth-internal.la
arm-linux-gnueabihf-ar: `u' modifier ignored since `D' is the default (see `U')
CC gdbus/mainloop.lo
In file included from /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9:0,
from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from gdbus/mainloop.c:28:
/usr/include/glib-2.0/glib/gtypes.h: In function '_GLIB_CHECKED_ADD_U64':
/usr/include/glib-2.0/glib/gmacros.h:232:53: error: size of array '_GStaticAssertCompileTimeAssertion_0' is negative
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gmacros.h:229:47: note: in definition of macro 'G_PASTE_ARGS'
#define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
^
/usr/include/glib-2.0/glib/gmacros.h:232:44: note: in expansion of macro 'G_PASTE'
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gtypes.h:422:3: note: in expansion of macro 'G_STATIC_ASSERT'
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
^
Makefile:5858: recipe for target 'gdbus/mainloop.lo' failed
make[1]: *** [gdbus/mainloop.lo] Error 1
Makefile:3278: recipe for target 'all' failed
make: *** [all] Error 2
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$
SOLUTION FOUND
OK, against my better judgment , I just hate 'try this and see' ) I changed the cast to (unsigned long) and here are the abbreviated results :
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$ sudo make
make --no-print-directory all-am
CC gdbus/mainloop.lo HORRAY IT passed !
CC gdbus/watch.lo
CC gdbus/object.lo
CC gdbus/client.lo
CC gdbus/polkit.lo
CCLD gdbus/libgdbus-internal.la
arm-linux-gnueabihf-ar: `u' modifier ignored since `D' is the default (see `U')
............
CC client/gatt.o
CCLD client/bluetoothctl
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lglib-2.0
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -ldbus-1
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lreadline
collect2: error: ld returned 1 exit status
Makefile:4136: recipe for target 'client/bluetoothctl' failed
make[1]: *** [client/bluetoothctl] Error 1
Makefile:3278: recipe for target 'all' failed
make: *** [all] Error 2
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$
This last error is definitely telling "make" is attempting to cross compile ( client ) and looking for "arm" resources.
I'll work on that and ask for assistance if needed.
I really appreciate all the support with the last case.
I do not need to find out why the source code has a 64 bits bug in it.
Prefer not to fix somebody else working code.
I am trying hard not to screw something and break this "autotools" chain of command, so I'll be happy with this hack.
Thanks again
Cheers
modified 10-May-19 14:53pm.
|
|
|
|
|
It looks that the size of the unsigned long long provided by the platform you're (cross) compiling for, doesn't comply with the requested one (should be the same of guint64, that is 8 bytes).
|
|
|
|
|
You may be right, I found this definition:
guint64
typedef unsigned long guint64;
An unsigned integer guaranteed to be 64-bits on all platforms. Values of this type can range from 0 to G_MAXUINT64 (= 18,446,744,073,709,551,615).
To print or scan values of this type, use G_GINT64_MODIFIER and/or G_GUINT64_FORMAT.
Thanks
|
|
|
|
|
Am I on the right track ?
Apparently the type unsigned long long is not "typedef.
It also looks line 422 should not be used per comment note.
#ifndef _GLIB_TEST_OVERFLOW_FALLBACK
#if __GNUC__ >= 5
#define _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS
#elif __has_builtin(__builtin_uadd_overflow)
#define _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS
#endif
#endif
#define g_uint_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U32(dest, a, b)
#define g_uint_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U32(dest, a, b)
#define g_uint64_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U64(dest, a, b)
#define g_uint64_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U64(dest, a, b)
#if GLIB_SIZEOF_SIZE_T == 8
#define g_size_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U64(dest, a, b)
#define g_size_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U64(dest, a, b)
#else
#define g_size_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U32(dest, a, b)
#define g_size_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U32(dest, a, b)
#endif
/* The names of the following inlines are private. Use the macro
* definitions above.
*/
#ifdef _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS
static inline gboolean _GLIB_CHECKED_ADD_U32 (guint32 *dest, guint32 a, guint32 b) {
return !__builtin_uadd_overflow(a, b, dest); }
static inline gboolean _GLIB_CHECKED_MUL_U32 (guint32 *dest, guint32 a, guint32 b) {
return !__builtin_umul_overflow(a, b, dest); }
static inline gboolean _GLIB_CHECKED_ADD_U64 (guint64 *dest, guint64 a, guint64 b) {
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
return !__builtin_uaddll_overflow(a, b, (unsigned long long *) dest); }
static inline gboolean _GLIB_CHECKED_MUL_U64 (guint64 *dest, guint64 a, guint64 b) {
return !__builtin_umulll_overflow(a, b, (unsigned long long *) dest); }
#else
static inline gboolean _GLIB_CHECKED_ADD_U32 (guint32 *dest, guint32 a, guint32 b) {
*dest = a + b; return *dest >= a; }
static inline gboolean _GLIB_CHECKED_MUL_U32 (guint32 *dest, guint32 a, guint32 b) {
*dest = a * b; return !a || *dest / a == b; }
static inline gboolean _GLIB_CHECKED_ADD_U64 (guint64 *dest, guint64 a, guint64 b) {
|
|
|
|
|
The #defines above show that the offending function could (or should) have been invoked either through the alias g_uint64_checked_add() or g_size_checked_add(), but the latter only if sizeof (size_t) is 8 bytes. but that doesn't add any helpful information with respect to fixing the problem: that casting a guint64* to (unsigned long long)* is not a valid operation for the target system you are compiling for.
What is in line 28 in mainloop.c? Have you called g_uint64_checked_add() when you should have called g_size_checked_add instead? What are the types of the arguments you use in the function call?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
The assert is telling you that the defined sizes of the guint64 and unsigned long long types are not the same, so the code cannot be built for the target that you are trying.
|
|
|
|
|
You have to interpret the error information back to front:
1. The make error
Vaclav_ wrote: Makefile:5858: recipe for target 'gdbus/mainloop.lo' failed
tells you that the target mainloop.lo could not be built, and the messages above are output from the compiler that was called in an attempt to build this target.
2. The compiler output gives you accurate information on how it tried to expand a macro, resulting in C code that doesn't compile, and why it doesn't compile (negative array index).
3 The last lines of the compiler output show the condition that is statically checked, and ultimately leading to the compile error: as already pointed out, apparently the type unsigned long long does not have the same size as guint64.
The output further above above shows how the static assert macro expansion turns the value of this condition (false) into an invalid array type definition, but that information is not neede or useful to you; you only need to know that an assertion failed, find out why this happened, and (how (or if) you can fix it.
4. The static assert was invoked in function _GLIB_CHECKED_ADD_U64, and this function was called somewhere in mainloop.c (in line 28, according to the compiler). That means you should check the function call: maybe you're calling the wrong function for the job. Or maybe you shouldn't use guint64 for the target system you're compiling for.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Thanks, this is exactly what I was asking for.
All I wanted to know was answered in your first line.
I certainly appreciate you taking the time to walk thru the process.
I forgot to stress - this is not my code - it is a product of "make" produced with the aid of "configure" script which is part of canned "bluez" source code.
The "configure" is optioned to build "C" library, not to install "bulez" package, for ARM architecture. The "configure" and associated processes ( make and make install) are run on X86 architecture - hence "the problem".
All of this is "created" by autotools.
So I need to be careful not to "disturb" the code created by autotools.
Some of the code has very noticeable notes that "it was created bu autotools" , hence do not mess with it.
Cheers
|
|
|
|
|
It appears that the available source and 64 bit OS (I am using) is being confirmed as an issue.
I would hope if quint64 was "typedef" it would be in gtypes.h header. It is not there, maybe it is not needed to be "typedef".
I am still not sure why when (quint64) is used it is typecasted as "long long" when the define I found is just "long". I guess I need definition of "long" as used by glib code.
Perhaps I could just try to change the typecast to (unsigned long) but not sure why it would work.
What is really bothersome is that the comments in the header file clearly states "use the macros above " and not the failing function.
.
|
|
|
|
|
i want to call python function from c++. i copy the c++ and python code from this site. but when i try to compile c++ code then it show an error. the error is:
fetal error: python.h: no such file or directory
how can i solved this problem ?
|
|
|
|
|
Shohel hasan wrote: error: python.h: no such file or directory
how can i solved this problem ?
Be sure that "python.h" file exists!
|
|
|
|
|
Go back to the article where you copied the code from and check that the file python.h was also copied. If it is not there then post a question in the forum at the end of the article. The author should then be able to help you.
|
|
|
|
|
|
Hello everyone,
I'm sure it's been thought of various times before, but I'm waiting for a rebuild so this is more productive and self-entertaining than staring at the walls...
Just thinking about it without putting any really useful brain cells at risk, it would seem like it would kill two opposing birds with one stone. Lots of people hate having long namespaces used all over the place. Other people say it's a really bad thing because it can lead to clashes down the line and such. But an XML style scheme could work for both.
Any help will be appreciated.
|
|
|
|
|
Sounds completely pointless. It would be needlessly complicated to solve a non-existent problem.
|
|
|
|
|
david3217 wrote: hate having long namespaces
Having to type more is never a good reason to change anything. That's what you have autocompletion for. You should strive to write code that is easy to understand and manage. Writing less is not helping either. Using XML style will make your code harder to read and manage.
And if you really can't stand it, C++ already offers using. E. g. if you do a lot of I/O, you can write
using std::cout;
using std::endl;
using std::cin;
to abbreviate your code in your source file (never in a header file!). Not that it's really neccessary...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Quote: Having to type more is never a good reason to change anything
I disagree (I know, it is a matter of personal taste, anyway).
It is not just typing, but also reading back what you have (or some other developer has) typed. Think at progresses made in mathematics with the introduction of the symbolic notation (it is a far fetched example, but it gives you the idea).
|
|
|
|
|
If you type more, the resulting text should make your code more readable, not less. If it doesn't, that is an entirely different problem.
As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Quote: If you type more, the resulting text should make your code more readable, not less
Verbosity does not imply clarity. Often writing less makes your text more readable ("Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte"  ).
Quote: As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
I do agree with you on this (still, I believe that 'i' is a better name than 'index').
|
|
|
|
|
CPallini wrote: still, I believe that 'i' is a better name than 'index'
It depends...
In a very short for loop I usually prefer using 'i'.
However, if I fill in some listbox/listcontrol I prefer using 'index' or 'item' rather than 'i'.
|
|
|
|
|
The problem arises when you need to fill a listbox in a very short for loop. 
|
|
|
|
|
|
CPallini wrote: Verbosity does not imply clarity
That's why I said 'should'
CPallini wrote: (still, I believe that 'i' is a better name than 'index')
I agree that 'index' is no more useful a name than 'i'. If there is any implied meaning to an index other than being the i'th element in a container, I prefer a variable name that reflects this meaning. For example if I have a curve consisting of several joined edges, I prefer 'edge_index' over 'i' or 'index'. Not only does this add clarity, it also makes my code extendable: if I later find I want to process each edge as a list of points, I have no problem naming the nested loop variable as 'point_index', and i wouldn't need to rename the existing loop variable.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
