Hi all,
I'm cross compiling bluez-util to my platform, so I use something like
--prefix=/path/to/my/platform/root/filesystem/usr. Everything builds
and installs perfectly.
But, in my platform, bluez now thinks that all the files are located
in the path /path/to/my/platform/root/filesystem/usr (it is hard coded
in the binaries), which doesn't really exists on the platform - it was
just on my host, where I built my root fs for the platform. I need to
install everything on my host to that path, but on the platform I need
bluez to ignore it...
Any suggestions ? I can always use --prefix=/usr and then manually
copy all the files to /path/to/my/platform/root/filesystem/usr but
that is too hard... there must be a better way..
Thank you!
Voni
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Mon, Jun 30, 2008 at 3:06 PM, Voni Hakau <[email protected]> wrote:
> Hi !
>
> On Tue, Jun 17, 2008 at 1:41 AM, Mumia W..
> <[email protected]> wrote:
>> But DESTDIR is used during "make install," and as you figured, you can use
>> the platform's prefix.
>>
>> Note that some programs don't use the DESTDIR variable, but almost all do.
>>
>
> I have successfully built expat,dbus and bluez-libs with this idea, but it seems
> that bluez-utils doesn't like it..
>
> Here is my configure command:
> BLUEZ_CFLAGS=-I/path/to/my/platform/root/usr/include
> BLUEZ_LIBS="-L/path/to/my/platform/root/usr/lib -lbluetooth"
> DBUS_LIBS="-L/path/to/my/platform/root/usr/lib -ldbus-1"
> DBUS_CFLAGS="-I/path/to/my/platform/root/usr/include/dbus-1.0
> -I/path/to/my/platform/root/usr/include/dbus-1.0/include"
> CPPFLAGS=-I/path/to/my/platform/root/usr/include
> LDFLAGS=-L/path/to/my/platform/root/usr/lib ./configure --prefix=/usr
> --host=arm-linux --mandir=/usr/share/man --sysconfdir=/etc
> --localstatedir=/var --libexecdir=/lib
>
> configure runs ok, and then make runs a little until it is doing this:
> arm-linux-gcc -I/path/to/my/platform/root/usr/include
> -I/path/to/my/platform/root/usr/include/dbus-1.0
> -I/path/to/my/platform/root/usr/include/dbus-1.0/include -I../eglib
> -I../gdbus -DPLUGINDIR=\"/usr/lib/bluetooth/plugins\" -Wall -O2
> -D_FORTIFY_SOURCE=2 -o hcid main.o -rdynamic
> -L/path/to/my/platform/root/usr/lib libhciserver.a
> ../sdpd/libsdpserver.a ../common/libhelper.a ../gdbus/.libs/libgdbus.a
> ../eglib/.libs/libeglib.a -ldl /usr/lib/libdbus-1.so
> /path/to/my/platform/root/usr/lib/libbluetooth.so -Wl,--rpath
> -Wl,/path/to/my/platform/root/usr/lib -Wl,--rpath
> -Wl,/path/to/my/platform/root/usr/lib
> /usr/lib/libdbus-1.so: file not recognized: File format not recognized
> collect2: ld returned 1 exit status
>
> we can see that it tried to use my host libdbus-1.so, and it ignores
> the DBUS_LIBS variable..
>
> did i do something wrong ?
> maybe it is a bug in bluez ? do you know how to fix it or bypass it ?
> I tried to look in the Makefiles themselves to change this behavior
> but didn't find it..
>
> Thank you again for this wonderful assistance !
> Voni
>
> (btw, I even tried to set up
> PKG_CONFIG_PATH=/path/to/my/platform/root/usr/lib/pkgconfig
> but it didn't help...)
btw, I can also see another problem:
-DPLUGINDIR=\"/usr/lib/bluetooth/plugins\"
i don't know if it is severe..
>
>>
>>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi !
On Tue, Jun 17, 2008 at 1:41 AM, Mumia W..
<[email protected]> wrote:
> But DESTDIR is used during "make install," and as you figured, you can use
> the platform's prefix.
>
> Note that some programs don't use the DESTDIR variable, but almost all do.
>
I have successfully built expat,dbus and bluez-libs with this idea, but it seems
that bluez-utils doesn't like it..
Here is my configure command:
BLUEZ_CFLAGS=-I/path/to/my/platform/root/usr/include
BLUEZ_LIBS="-L/path/to/my/platform/root/usr/lib -lbluetooth"
DBUS_LIBS="-L/path/to/my/platform/root/usr/lib -ldbus-1"
DBUS_CFLAGS="-I/path/to/my/platform/root/usr/include/dbus-1.0
-I/path/to/my/platform/root/usr/include/dbus-1.0/include"
CPPFLAGS=-I/path/to/my/platform/root/usr/include
LDFLAGS=-L/path/to/my/platform/root/usr/lib ./configure --prefix=/usr
--host=arm-linux --mandir=/usr/share/man --sysconfdir=/etc
--localstatedir=/var --libexecdir=/lib
configure runs ok, and then make runs a little until it is doing this:
arm-linux-gcc -I/path/to/my/platform/root/usr/include
-I/path/to/my/platform/root/usr/include/dbus-1.0
-I/path/to/my/platform/root/usr/include/dbus-1.0/include -I../eglib
-I../gdbus -DPLUGINDIR=\"/usr/lib/bluetooth/plugins\" -Wall -O2
-D_FORTIFY_SOURCE=2 -o hcid main.o -rdynamic
-L/path/to/my/platform/root/usr/lib libhciserver.a
../sdpd/libsdpserver.a ../common/libhelper.a ../gdbus/.libs/libgdbus.a
../eglib/.libs/libeglib.a -ldl /usr/lib/libdbus-1.so
/path/to/my/platform/root/usr/lib/libbluetooth.so -Wl,--rpath
-Wl,/path/to/my/platform/root/usr/lib -Wl,--rpath
-Wl,/path/to/my/platform/root/usr/lib
/usr/lib/libdbus-1.so: file not recognized: File format not recognized
collect2: ld returned 1 exit status
we can see that it tried to use my host libdbus-1.so, and it ignores
the DBUS_LIBS variable..
did i do something wrong ?
maybe it is a bug in bluez ? do you know how to fix it or bypass it ?
I tried to look in the Makefiles themselves to change this behavior
but didn't find it..
Thank you again for this wonderful assistance !
Voni
(btw, I even tried to set up
PKG_CONFIG_PATH=/path/to/my/platform/root/usr/lib/pkgconfig
but it didn't help...)
>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On 06/16/2008 07:05 AM, Voni Hakau wrote:
> On Fri, Jun 13, 2008 at 6:25 PM, Mumia W..
> <[email protected]> wrote:
>> [...]
>> make --prefix=/usr
>>
>> When you "install" the package, you'll use this command:
>>
>> make install DESTDIR=/tmp/buildplace
>> [...]
>
> Wow this is an amazing idea !! Thank you so much !!
>
> I didn't know I can give --prefix to make. Or did you mean to ./configure ?
>
> and I didn't know there is DESTDIR for make install. great great tip !!!
>
> So I can just do make install DESTDIR with the prefix of my platform
> root filesystem,
> right ? I don't have to do the package, right ?
>
> Thank you so much for this!! it's a really great idea..
>
> Voni
>
You're welcome Voni.
Yes, I meant "./configure --prefix=/usr"
But DESTDIR is used during "make install," and as you figured, you can
use the platform's prefix.
Note that some programs don't use the DESTDIR variable, but almost all do.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, Jun 13, 2008 at 6:25 PM, Mumia W..
<[email protected]> wrote:
> On 06/13/2008 07:07 AM, Voni Hakau wrote:
>> I'm cross compiling bluez-util to my platform, so I use something like
>> --prefix=/path/to/my/platform/root/filesystem/usr.
> Try to create a package instead. Use --prefix=/usr when you configure,
> but use DESTDIR=/tmp/buildplace when you install.
>
> That should install the files to /tmp/buildplace. Use tar(1) to create a
> tarball of the files in /tmp/buildplace, or even better, use a packager
> for your preferred platform.
>
> During configuration, your command line might look like this:
>
> make --prefix=/usr
>
> When you "install" the package, you'll use this command:
>
> make install DESTDIR=/tmp/buildplace
>
> Obviously, the files won't be installed to the right place. No problem,
> use tar(1).
>
> cd /tmp/buildplace
> tar czf /tmp/bluez-x.xx-i386.tar.gz *
>
> Now you have a tarball that you can install wherever you wish, including
> the correct place for your platform,
> /path/to/my/platform/root/filesystem/usr.
Wow this is an amazing idea !! Thank you so much !!
I didn't know I can give --prefix to make. Or did you mean to ./configure ?
and I didn't know there is DESTDIR for make install. great great tip !!!
So I can just do make install DESTDIR with the prefix of my platform
root filesystem,
right ? I don't have to do the package, right ?
Thank you so much for this!! it's a really great idea..
Voni
>
> Good luck.
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On 06/13/2008 07:07 AM, Voni Hakau wrote:
> Hi all,
>
> I'm cross compiling bluez-util to my platform, so I use something like
> --prefix=/path/to/my/platform/root/filesystem/usr. Everything builds
> and installs perfectly.
>
> But, in my platform, bluez now thinks that all the files are located
> in the path /path/to/my/platform/root/filesystem/usr (it is hard coded
> in the binaries), which doesn't really exists on the platform - it was
> just on my host, where I built my root fs for the platform. I need to
> install everything on my host to that path, but on the platform I need
> bluez to ignore it...
>
> Any suggestions ? I can always use --prefix=/usr and then manually
> copy all the files to /path/to/my/platform/root/filesystem/usr but
> that is too hard... there must be a better way..
>
> Thank you!
> Voni
>
Hi Voni.
Try to create a package instead. Use --prefix=/usr when you configure,
but use DESTDIR=/tmp/buildplace when you install.
That should install the files to /tmp/buildplace. Use tar(1) to create a
tarball of the files in /tmp/buildplace, or even better, use a packager
for your preferred platform.
During configuration, your command line might look like this:
make --prefix=/usr
When you "install" the package, you'll use this command:
make install DESTDIR=/tmp/buildplace
Obviously, the files won't be installed to the right place. No problem,
use tar(1).
cd /tmp/buildplace
tar czf /tmp/bluez-x.xx-i386.tar.gz *
Now you have a tarball that you can install wherever you wish, including
the correct place for your platform,
/path/to/my/platform/root/filesystem/usr.
Good luck.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Wed, 2 Jul 2008, Voni Hakau wrote:
-> > Perhaps the library is mentioned in a libtool (.la) file? You should be able
-> > to change the Makefiles if needed. Looking in 3.34 utils, I see your libdbus-1
-> > is mentioned in lots of places (found with `rgrep -r 'dbus-1' . | most ` while
-> > cwd was /tmp/bluez-utils-3.34):
->
-> So you think too that there is a bug in bluez-utils ? That it ignores
-> the DBUS_LIBS environment variable ?
Honestly, I'm not sure. Note that vars like DBUS_LIBS can be set in many
places, and there is an order in which they take preference. You might be
setting it, only to have to cancelled by a higher-preference assignment some
place else. If that is how it is designed to be, it's not a bug; it's hard to
tell without the actual problem in front of me. It built OK here, but then I'm
not cross compiling, which is a bit trickier.
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tue, Jul 1, 2008 at 6:09 PM, jayjwa <[email protected]> wrote:
> -> > we can see that it tried to use my host's libdbus-1.so, and it ignores
> -> > the DBUS_LIBS variable..
> Perhaps the library is mentioned in a libtool (.la) file? You should be able
> to change the Makefiles if needed. Looking in 3.34 utils, I see your libdbus-1
> is mentioned in lots of places (found with `rgrep -r 'dbus-1' . | most ` while
> cwd was /tmp/bluez-utils-3.34):
So you think too that there is a bug in bluez-utils ? That it ignores
the DBUS_LIBS environment variable ?
Thank you
Voni
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Mon, 30 Jun 2008, Voni Hakau wrote:
-> > I have successfully built expat,dbus and bluez-libs with this idea, but it seems
-> > that bluez-utils doesn't like it..
-> >
-> > Here is my configure command:
-> > BLUEZ_CFLAGS=-I/path/to/my/platform/root/usr/include
-> > BLUEZ_LIBS="-L/path/to/my/platform/root/usr/lib -lbluetooth"
-> > DBUS_LIBS="-L/path/to/my/platform/root/usr/lib -ldbus-1"
-> > DBUS_CFLAGS="-I/path/to/my/platform/root/usr/include/dbus-1.0
-> > -I/path/to/my/platform/root/usr/include/dbus-1.0/include"
-> > CPPFLAGS=-I/path/to/my/platform/root/usr/include
-> > LDFLAGS=-L/path/to/my/platform/root/usr/lib ./configure --prefix=/usr
-> > --host=arm-linux --mandir=/usr/share/man --sysconfdir=/etc
-> > --localstatedir=/var --libexecdir=/lib
-> >
-> > configure runs ok, and then make runs a little until it is doing this:
-> > arm-linux-gcc -I/path/to/my/platform/root/usr/include
-> > -I/path/to/my/platform/root/usr/include/dbus-1.0
-> > -I/path/to/my/platform/root/usr/include/dbus-1.0/include -I../eglib
-> > -I../gdbus -DPLUGINDIR=\"/usr/lib/bluetooth/plugins\" -Wall -O2
-> > -D_FORTIFY_SOURCE=2 -o hcid main.o -rdynamic
-> > -L/path/to/my/platform/root/usr/lib libhciserver.a
-> > ../sdpd/libsdpserver.a ../common/libhelper.a ../gdbus/.libs/libgdbus.a
-> > ../eglib/.libs/libeglib.a -ldl /usr/lib/libdbus-1.so
-> > /path/to/my/platform/root/usr/lib/libbluetooth.so -Wl,--rpath
-> > -Wl,/path/to/my/platform/root/usr/lib -Wl,--rpath
-> > -Wl,/path/to/my/platform/root/usr/lib
-> > /usr/lib/libdbus-1.so: file not recognized: File format not recognized
-> > collect2: ld returned 1 exit status
-> >
-> > we can see that it tried to use my host libdbus-1.so, and it ignores
-> > the DBUS_LIBS variable..
-> >
-> > did i do something wrong ?
-> > maybe it is a bug in bluez ? do you know how to fix it or bypass it ?
-> > I tried to look in the Makefiles themselves to change this behavior
-> > but didn't find it..
Perhaps the library is mentioned in a libtool (.la) file? You should be able
to change the Makefiles if needed. Looking in 3.34 utils, I see your libdbus-1
is mentioned in lots of places (found with `rgrep -r 'dbus-1' . | most ` while
cwd was /tmp/bluez-utils-3.34):
./sdpd/Makefile:DBUS_CFLAGS = -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
./sdpd/Makefile:DBUS_LIBS = -ldbus-1
./hcid/Makefile:DBUS_CFLAGS = -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
./hcid/Makefile:DBUS_LIBS = -ldbus-1
./hcid/Makefile:#dbusdir = $(sysconfdir)/dbus-1/system.d
./hcid/Makefile: $(top_builddir)/gdbus/libgdbus.la -Wl,--export-dynamic
-lgmodule-2.0 -ldl -lglib-2.0 -lglib-2.0 -ldbus-1
You could try giving the full path names.
/path/to/my/platform/root/usr/lib/libdbus-1.so
DBUS_LIBS="/path/to/my/platform/root/usr/lib/libdbus-1.so "
If it still gives errors, start grepping through .la files to see if one is
listing a -ldbus-1.
-> btw, I can also see another problem:
->
-> -DPLUGINDIR=\"/usr/lib/bluetooth/plugins\"
->
-> i don't know if it is severe..
I think yes, if that path doesn't exist on the target you are compiling for,
because the daemons will need to load their plugins while they run on the
target machine. If the target actually has a /usr/lib/bluetooth/plugins dir,
then it should be OK.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users