Hi! When I try to compile dbus-glib, comes the error that fails at trying to include some libraries or functions. Tried with 0.106 and also downgrading to the stable version. I'll attach the log for more details. Reproducible: Always
Created attachment 423404 [details] The build log
Essence from the build log: Failed assertions G_STATIC_ASSERT (sizeof (dbus_int64_t) == sizeof (gint64)); G_STATIC_ASSERT (sizeof (dbus_uint64_t) == sizeof (guint64)); in dbus-gvalue.c.
(In reply to Felix Janda from comment #2) > Essence from the build log: Failed assertions > > G_STATIC_ASSERT (sizeof (dbus_int64_t) == sizeof (gint64)); > G_STATIC_ASSERT (sizeof (dbus_uint64_t) == sizeof (guint64)); > > in dbus-gvalue.c. Fine. Commenting those lines fixed my issue, but I don't know if that's a good idea. I'm using ~amd64.
(I wrote comment 2 just to save others some effort with reading the build log.) It is really strange that these asserts fail. It would be interesting to see which of G_STATIC_ASSERT (sizeof (dbus_int64_t) == 8); G_STATIC_ASSERT (sizeof (gint64) == 8); fail. It might also be useful to know which versions of dbus and glib you are using.
Could you please all add emerge --info?
(In reply to Michael Palimaka (kensington) from comment #5) > Could you please all add emerge --info? http://pastebin.com/vfJ8LcnJ
(In reply to Felix Janda from comment #4) > (I wrote comment 2 just to save others some effort with reading the build > log.) > > It is really strange that these asserts fail. It would be interesting to see > which of > > G_STATIC_ASSERT (sizeof (dbus_int64_t) == 8); > G_STATIC_ASSERT (sizeof (gint64) == 8); > > fail. It might also be useful to know which versions of dbus and glib you > are using. DBus 1.10.6 Glib 2.46.2-r1 Both ~amd64
are you still suffering this bug on an updated system?
(In reply to Pacho Ramos from comment #8) > are you still suffering this bug on an updated system? Yes, I'm still, no matter the version. The issue is the same. Just tried building and the result is the same.
Could you attach the output of: emerge --info dbus-glib ?
(In reply to Gilles Dartiguelongue from comment #10) > Could you attach the output of: emerge --info dbus-glib ? (Previous output ommited because it was attached previously) ================================================================= Package Settings ================================================================= dev-libs/dbus-glib-0.106::gentoo was built with the following: USE="-debug -static-libs -test" ABI_X86="32 64 -x32"
Yeah, I didn't see that pastebin. We don't recommend using pastebin, because your never know if it will be really stored when someone reads it or not, contrary to bugzilla which is meant to hold files related to bugs.
Also the emerge --info shows your system is outdated to current ~amd64 so I would really like to know if anything changed or not. If not, I would recommend upgrading your system as a first step.
(In reply to Gilles Dartiguelongue from comment #13) > Also the emerge --info shows your system is outdated to current ~amd64 so I > would really like to know if anything changed or not. If not, I would > recommend upgrading your system as a first step. This is because this bug was reported in January and no one took on mind on that. We're now in September and the issue is still not being fixed. And the system is already updated, so...
Created attachment 445328 [details, diff] Using this patch, solves the problem, at least for me.
*** Bug 597088 has been marked as a duplicate of this bug. ***
I just figured that none of glib, dbus or dbus-glib actually pulls pkgconfig[abi_x86_32] but everything still builds fine on my system whether or not I have i686-pc-linux-gnu-pkg-config. Anyway, did you manage to build a previous version of dbus-glib ever ? Could you run the following : $ cat test.c <<EOF #include <dbus/dbus.h> #include <glib.h> #include <stdio.h> int main(int argc, char *argv[]) { printf("dbus %zu\n", sizeof (dbus_uint64_t)); printf("glib: %zu\n", sizeof (guint64)); } EOF $ x86_64-pc-linux-gnu-gcc $(x86_64-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1) test.c ; ./a.out dbus 8 glib: 8 [~] $ x86_64-pc-linux-gnu-gcc -m32 $(i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1) test.c ; ./a.out dbus 8 glib: 8
(In reply to Gilles Dartiguelongue from comment #17) > I just figured that none of glib, dbus or dbus-glib actually pulls > pkgconfig[abi_x86_32] but everything still builds fine on my system whether > or not I have i686-pc-linux-gnu-pkg-config. > > Anyway, did you manage to build a previous version of dbus-glib ever ? > > Could you run the following : > $ cat test.c <<EOF > #include <dbus/dbus.h> > #include <glib.h> > #include <stdio.h> > > int main(int argc, char *argv[]) { > printf("dbus %zu\n", sizeof (dbus_uint64_t)); > printf("glib: %zu\n", sizeof (guint64)); > } > EOF > $ x86_64-pc-linux-gnu-gcc $(x86_64-pc-linux-gnu-pkg-config --cflags glib-2.0 > dbus-1) test.c ; ./a.out > dbus 8 > glib: 8 > [~] > $ x86_64-pc-linux-gnu-gcc -m32 $(i686-pc-linux-gnu-pkg-config --cflags > glib-2.0 dbus-1) test.c ; ./a.out > dbus 8 > glib: 8 I though I mentioned that I tried with ALL dbus-glib versions (even the stable one, as I said in "no matter the version"), and the error is the same. Also I tried the code you posted and works fine in both cases.
(In reply to Gilles Dartiguelongue from comment #17) > I just figured that none of glib, dbus or dbus-glib actually pulls > pkgconfig[abi_x86_32] but everything still builds fine on my system whether > or not I have i686-pc-linux-gnu-pkg-config. > > Anyway, did you manage to build a previous version of dbus-glib ever ? > > Could you run the following : > $ cat test.c <<EOF > #include <dbus/dbus.h> > #include <glib.h> > #include <stdio.h> > > int main(int argc, char *argv[]) { > printf("dbus %zu\n", sizeof (dbus_uint64_t)); > printf("glib: %zu\n", sizeof (guint64)); > } > EOF > $ x86_64-pc-linux-gnu-gcc $(x86_64-pc-linux-gnu-pkg-config --cflags glib-2.0 > dbus-1) test.c ; ./a.out > dbus 8 > glib: 8 > [~] > $ x86_64-pc-linux-gnu-gcc -m32 $(i686-pc-linux-gnu-pkg-config --cflags > glib-2.0 dbus-1) test.c ; ./a.out > dbus 8 > glib: 8 As mentioned in the bug I filed (which was marked a duplicate of this one), I have dbus-glib-0.106 installed, but portage wants to update it to 0.108, and that fails to build. I just ran your test, and the last command gave me "dbus 4" instead of 8:. $ x86_64-pc-linux-gnu-gcc $(x86_64-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1) test.c ; ./a.out dbus 8 glib: 8 $ x86_64-pc-linux-gnu-gcc -m32 $(i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1) test.c ; ./a.out dbus 4 glib: 8
Now things start to make some sense: When dbus is built it records some results found during configure time into the header dbus/dbus-arch-deps.h, in particular for the definition of dbus_int64_t. The logic of the configure script is to take int if int is 64bit, otherwise long if that is 64bit, and otherwise long long. So on when ABI=32, long long will be used, and when ABI=64, long will be used. The observed bug is that when dbus is in Gentoo's multilib setup only one of the generated dbus-arch-deps.h headers can be installed. In our case just the 64bit header has been installed, and it has the wrong definition of dbus_int64_t. There are many ways dbus could be fixed. For example, its configure script could be made to prefer long long over long and int.
Protip: /usr/lib32/dbus-1.0/include/dbus/dbus-arch-deps.h I have a correct type there. What does 'i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1' say? $ i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib32/dbus-1.0/include
Sorry for saying nonsense about Gentoo multilib. On the other hand, the pkg-config output already shows the problem: "-I/usr/include/dbus-1.0" comes in the include line before "-I/usr/lib32/dbus-1.0/include", so "/usr/include/dbus-1.0/include/dbus/dbus-arch-deps.h" will be preferred over the correct header.
There shouldn't be such a file in there. Is it owned by the package?
Sorry again, the other file is in "/usr/lib64/..." and so shouldn't give any problems. So it remains unclear what is wrong. @jorgicio: To repeat mgorny's request, what does "i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1" say? Could you also post the content of "/usr/lib32/dbus-1.0/include/dbus/dbus-arch-deps.h"?
Created attachment 450730 [details] /usr/lib32/dbus-1.0/include/dbus/dbus-arch-deps.h
(In reply to Michał Górny from comment #21) > What does 'i686-pc-linux-gnu-pkg-config > --cflags glib-2.0 dbus-1' say? > > $ i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1 > -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include > -I/usr/include/dbus-1.0 -I/usr/lib32/dbus-1.0/include I get the same output as you posted.
Well, that doesn't seem to make sense. What is your active GCC version?
$ gcc-config -l [1] x86_64-pc-linux-gnu-5.4.0 *
Could you attach also the output of x86_64-pc-linux-gnu-gcc -E -m32 $(i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1) test.c where test.c is as in comment 17?
Created attachment 450780 [details] results of x86_64-pc-linux-gnu-gcc -E -m32 $(i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1) test.c
Now we are getting close: You should not have a header /usr/include/dbus-1.0/dbus/dbus-arch-deps.h. What does `equery belongs "/usr/include/dbus-1.0/dbus/dbus-arch-deps.h"` say about this header? If it belongs to sys-apps/dbus, is it still there after reemerging dbus? If so, it would be nice to have a build log of dbus.
$ equery belongs "/usr/include/dbus-1.0/dbus/dbus-arch-deps.h" * Searching for /usr/include/dbus-1.0/dbus/dbus-arch-deps.h ... $ Comes up blank.
So the header was not installed by gentoo. Have you maybe done a manual installation of dbus at some point? Looking into the header would at least tell you what version of dbus it is from. Anyway, dbus-glib should compile fine with the bad header removed.
Hey, that did it! I don't know how the header got there (running ls -l on it before deleting it showed a date in April), but I'll happily move on without it. Thanks for the help!
(In reply to Felix Janda from comment #24) > Sorry again, the other file is in "/usr/lib64/..." and so shouldn't > give any problems. So it remains unclear what is wrong. > > @jorgicio: To repeat mgorny's request, what does > "i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1" say? Could > you also post the content of > "/usr/lib32/dbus-1.0/include/dbus/dbus-arch-deps.h"? Sorry, I just watched that. The output of the first command you mentioned is this: hackenherr:dev-libs# i686-pc-linux-gnu-pkg-config --cflags glib-2.0 dbus-1 [20:12:11] -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib32/dbus-1.0/include as well as: hackenherr:dev-libs# equery b /usr/include/dbus-1.0/dbus/dbus-arch-deps.h [20:12:43] * Searching for /usr/include/dbus-1.0/dbus/dbus-arch-deps.h ... sys-apps/dbus-1.10.12 (/usr/lib64/dbus-1.0/include/dbus/dbus-arch-deps.h) And the content of the such mentioned file: http://pastebin.com/kSc3LH6u Also, why is this invalid? The issue is still not solved I think.
Also: Reemerged dbus, then did the ebuild b as I did before, and the outputs are the same.
Well... I had to do a very stupid trick: I deleted the header conflicting file, reemerged dbus, then the header didn't go back again, rebuilt dbus-glib and the issue is gone. I didn't know why before deleting that header, the equery b still associates it to dbus. "Strange Things" came here to Gentoo. Thanks anyways.
