Hi,
building the master branch (a267bc2) on Debian systems fails when
linking the unit tests to the "check" library with this error:
CCLD unit/test-eir
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libcheck.a
(check.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be
used when making a shared object; recompile with
-fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libcheck.a:
could not read symbols: Bad value collect2: ld returned 1 exit status
make[1]: *** [unit/test-eir] Error 1 make: *** [all] Error 2
AFAIU this is a Debian quirk, the facts of the issue are more or less
these (please correct me if I am wrong):
- libcheck.a, as per upstream default, is generally built with -fPIC
- Debian policy tells that by default .a are not expected to be
built with -fPIC, so they provide libcheck_pic.a as alternative
instead.
- BlueZ build system tries to dynamically link the unit tests to
libcheck.a, but on Debian systems this is a non-PIC library and on
X86_64 linking to non PIC as shared library is not allowed.
After a little bit of research I found out that gstreamer people also
had run into that issue and they have a m4 macro to pickup
libcheck_pic.a if present:
http://cgit.freedesktop.org/gstreamer/common/tree/m4/check.m4
I have no idea if you BlueZ dev too want to handle this in-tree or
leave the burden to distributors.
The workaround I use for now is:
- run "make" and let the build system fail
- show the failing command with "make V=1"
- change -lcheck to -lcheck_pic and rerun the command
- "make" will now proceed with the build
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
On Tue, 15 Nov 2011 11:59:38 +0900
Marcel Holtmann <[email protected]> wrote:
> Hi Brian,
>
> > >> I believe it is more likely an X86-64 issue. And support for libcheck
> > >> is checked (and is there), but for some reason fails in this instance.
> > >
> > > So what does "pkg-config --libs check" actually tells you?
> >
> >
> > $ pkg-config --libs check
> > -lcheck
>
> there you have your problem. It should return -lcheck_pic if that is
> required for building with a dynamic library. File a bug with Debian for
> this.
>
Indeed, I suggested this workaround here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605207
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Hi Brian,
> >> I believe it is more likely an X86-64 issue. And support for libcheck
> >> is checked (and is there), but for some reason fails in this instance.
> >
> > So what does "pkg-config --libs check" actually tells you?
>
>
> $ pkg-config --libs check
> -lcheck
there you have your problem. It should return -lcheck_pic if that is
required for building with a dynamic library. File a bug with Debian for
this.
Regards
Marcel
Hi Marcel,
On 11/14/2011 6:53 PM, Marcel Holtmann wrote:
>> I believe it is more likely an X86-64 issue. And support for libcheck
>> is checked (and is there), but for some reason fails in this instance.
>
> So what does "pkg-config --libs check" actually tells you?
$ pkg-config --libs check
-lcheck
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Brian,
> >> I think using a “libcheck_pic aware” m4 macro is the way to go, ideally
> >> this should be provided in the check package itself, I'll try asking the
> >> Debian maintainers if there is no interest for a solution in BlueZ.
> >
> > why on earth does Debian has to do everything different than any other
> > distribution. I am getting pretty sick of that :(
> >
> > The easiest way is to just disable any kind of unit testing when the
> > check support is not found. Simple as that. I am not bothering to make
> > this work on Debian.
>
> This is *not* a Debian issue, as it also happens on Ubuntu.
actually Ubuntu just copies from Debian. So they are both the same and
make the same mistakes.
> I believe it is more likely an X86-64 issue. And support for libcheck
> is checked (and is there), but for some reason fails in this instance.
So what does "pkg-config --libs check" actually tells you?
Regards
Marcel
Hi Marcel,
On 11/14/2011 6:25 PM, Marcel Holtmann wrote:
> Hi Antonio,
>> I think using a ?libcheck_pic aware? m4 macro is the way to go, ideally
>> this should be provided in the check package itself, I'll try asking the
>> Debian maintainers if there is no interest for a solution in BlueZ.
>
> why on earth does Debian has to do everything different than any other
> distribution. I am getting pretty sick of that :(
>
> The easiest way is to just disable any kind of unit testing when the
> check support is not found. Simple as that. I am not bothering to make
> this work on Debian.
This is *not* a Debian issue, as it also happens on Ubuntu.
I believe it is more likely an X86-64 issue. And support for libcheck
is checked (and is there), but for some reason fails in this instance.
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Antonio,
> > > The workaround I use for now is:
> > > - run "make" and let the build system fail
> > > - show the failing command with "make V=1"
> > > - change -lcheck to -lcheck_pic and rerun the command
> > > - "make" will now proceed with the build
> >
> >
> > This same solution works for me: After running ./bootstrap-configure, I
> > change the unit_test_eir_LDADD line in the Makefile to:
> >
> > unit_test_eir_LDADD = lib/libbluetooth-private.la -lglib-2.0 -lcheck_pic
> >
>
> Eh Brian, this is surely a little prettier than what I am doing :)
>
> > There is probably a way to make this happen automatically, but I don't
> > know enough about the configure mechanism to know how to do this.
> >
>
> I think using a “libcheck_pic aware” m4 macro is the way to go, ideally
> this should be provided in the check package itself, I'll try asking the
> Debian maintainers if there is no interest for a solution in BlueZ.
why on earth does Debian has to do everything different than any other
distribution. I am getting pretty sick of that :(
The easiest way is to just disable any kind of unit testing when the
check support is not found. Simple as that. I am not bothering to make
this work on Debian.
Regards
Marcel
On Mon, 14 Nov 2011 10:12:55 -0800
Brian Gix <[email protected]> wrote:
> Hi Antonio,
>
> On 11/14/2011 6:56 AM, Antonio Ospite wrote:
> > Hi,
> >
> > building the master branch (a267bc2) on Debian systems fails when
> > linking the unit tests to the "check" library with this error:
> >
[...]
> >
> > The workaround I use for now is:
> > - run "make" and let the build system fail
> > - show the failing command with "make V=1"
> > - change -lcheck to -lcheck_pic and rerun the command
> > - "make" will now proceed with the build
>
>
> This same solution works for me: After running ./bootstrap-configure, I
> change the unit_test_eir_LDADD line in the Makefile to:
>
> unit_test_eir_LDADD = lib/libbluetooth-private.la -lglib-2.0 -lcheck_pic
>
Eh Brian, this is surely a little prettier than what I am doing :)
> There is probably a way to make this happen automatically, but I don't
> know enough about the configure mechanism to know how to do this.
>
I think using a “libcheck_pic aware” m4 macro is the way to go, ideally
this should be provided in the check package itself, I'll try asking the
Debian maintainers if there is no interest for a solution in BlueZ.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Hi Antonio,
On 11/14/2011 6:56 AM, Antonio Ospite wrote:
> Hi,
>
> building the master branch (a267bc2) on Debian systems fails when
> linking the unit tests to the "check" library with this error:
>
> CCLD unit/test-eir
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libcheck.a
> (check.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be
> used when making a shared object; recompile with
> -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libcheck.a:
> could not read symbols: Bad value collect2: ld returned 1 exit status
> make[1]: *** [unit/test-eir] Error 1 make: *** [all] Error 2
>
> [...]
I run into the same problem with an ubuntu-10.10 installation running in
a VM.
>
> The workaround I use for now is:
> - run "make" and let the build system fail
> - show the failing command with "make V=1"
> - change -lcheck to -lcheck_pic and rerun the command
> - "make" will now proceed with the build
This same solution works for me: After running ./bootstrap-configure, I
change the unit_test_eir_LDADD line in the Makefile to:
unit_test_eir_LDADD = lib/libbluetooth-private.la -lglib-2.0 -lcheck_pic
There is probably a way to make this happen automatically, but I don't
know enough about the configure mechanism to know how to do this.
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum