LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 03-03-2017, 02:36 AM   #1
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Rep: Reputation: 43
problem cross compiling usbutils


I'm using something very much derived from the usbutils.SlackBuild to cross compile.
I get different results when cross compiling usbutils on 2 different hosts although the xtoolchain is the exact same on both systems I get an issue only when building on an older slackware 14.1 host:

Code:
configure: error: Package requirements (libudev >= 196) were not met:

Package dependency requirement 'libudev >= 196' could not be satisfied.
Package 'libudev' has version '182', required version is '>= 196'

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables UDEV_CFLAGS
and UDEV_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
On the newer slackware 14.2 host machine I don't get the issue.

I'm not sure why but the configure script is looking at the host's (x86_64) libudev and not at the xtoolchain's.

I'm thinking that maybe the best way to work around this issue is to get usbutils configure to look at the libudev that I previously cross compiled (while putting together all the bits and pieces I need) ... but in this case I'm unsure how to go about it.

Anyone have any suggestion on how to work around this issue ?

Adding
Code:
PKG_CONFIG_PATH="/tmp/build/libusb-1.0.21:/tmp/build/eudev-3.2"
to the configure options get's me a little further but it's probably not the right thing to do
Code:
make[4]: Entering directory `/tmp/build/usbutils-008/usbhid-dump/lib'
/bin/sh ../libtool  --tag=CC   --mode=compile arm-linux-gcc -DHAVE_CONFIG_H -I. -I..   -I/tmp/build/usbutils-008/usbhid-dump -I/tmp/build/usbutils-008/usbhid-dump/include -DNDEBUG   -Os -Wall  -I/usr/src/buildroot-2016.11.2/output/host/usr/arm-clashNG-linux-uclibcgnueabi/sysroot/usr/include/libusb-1.0   -MT dev.lo -MD -MP -MF .deps/dev.Tpo -c -o dev.lo dev.c
libtool: compile:  arm-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I/tmp/build/usbutils-008/usbhid-dump -I/tmp/build/usbutils-008/usbhid-dump/include -DNDEBUG -Os -Wall -I/usr/src/buildroot-2016.11.2/output/host/usr/arm-clashNG-linux-uclibcgnueabi/sysroot/usr/include/libusb-1.0 -MT dev.lo -MD -MP -MF .deps/dev.Tpo -c dev.c  -fPIC -DPIC -o .libs/dev.o
In file included from /tmp/build/usbutils-008/usbhid-dump/include/uhd/dev.h:31:0,
                 from dev.c:29:
/tmp/build/usbutils-008/usbhid-dump/include/uhd/libusb.h:30:20: fatal error: libusb.h: No such file or directory
compilation terminated.

Last edited by louigi600; 03-07-2017 at 08:22 AM.
 
Old 03-03-2017, 04:04 AM   #2
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 556

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
The x-toolchain stuff I put on the FTP site is not a full toolchain, but _only_ enough to build natively on ARM and farm out the compilation of C/C++ to distcc on x86.

alienBOB made a full toolchain but it'll be out of date -- you can find it somewhere linked from his blog.
 
Old 03-03-2017, 04:36 AM   #3
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
I wanted to use uclibc to further minimize the footprint so I'm using uclibc xtoolchain built with their buildroot. I've used it to build the most of the other stuff I'll be needing (have not yet gone thought the whole list yet as I'm still making recipes). Sorry I should have mentioned that in the first place I guess.
 
Old 03-03-2017, 10:25 PM   #4
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
I was hoping that if I started out with x-compilinh from the start I could avoid some such issues but I'm now having similar issues to what I was hitting when, knowing not about armedsack (later renamed to slackwareARM), I was fiddling with the zaurus attempting to get a slackware like environment on it (which I called slackurus at the time). That horrible experience with x-toolchains made me skeptical about x-compilation and up until this attempt to revive clashNG I used to do all stuff natively.

Should I continue on the native route like this:
x-compile the bare essentials for a native clashNG machine
x-compile the basic native development environment for the clashNG machine
and from there on pursuit native development ?

Using uclibc's buildroot to make the entire target architecture root image would be much easier but I'm trying not avoid that for the moment as I want finer control over what goes in there.

Alternatively could I use the uclibc's buildroot made target root image purely for native developement ?

This last approach was what I had in mind when I restarted out, but I got tempted by the greater computing power offered by x-compilation.
 
Old 03-06-2017, 08:35 PM   #5
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
I can't say this enough, use printenv in your build environment in order to see what if something is leaking through from the host platform.

As to your problem... The second error says libusb.h is missing, that's not libudev, it's libusb. Don't forget that solving one problem sometimes reveals another. In fact, it often does...

Last edited by Luridis; 03-06-2017 at 08:36 PM.
 
Old 03-07-2017, 02:14 AM   #6
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
Quote:
Originally Posted by Luridis View Post
I can't say this enough, use printenv in your build environment in order to see what if something is leaking through from the host platform.

As to your problem... The second error says libusb.h is missing, that's not libudev, it's libusb. Don't forget that solving one problem sometimes reveals another. In fact, it often does...
You're referring to the error I get when I set
Code:
PKG_CONFIG_PATH="/tmp/build/libusb-1.0.21:/tmp/build/eudev-3.2"
and the first part of that is libusb.
Pointing PKG_CONFIG_PATH to where I built the other packages was a dirty trick that did not work.

Maybe I should install all the includes and libraries all in a place where the toolchain can find the correct libs and includes ?

Last edited by louigi600; 03-07-2017 at 02:26 AM.
 
Old 03-07-2017, 04:20 AM   #7
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by louigi600 View Post
You're referring to the error I get when I set
Code:
PKG_CONFIG_PATH="/tmp/build/libusb-1.0.21:/tmp/build/eudev-3.2"
and the first part of that is libusb.
Pointing PKG_CONFIG_PATH to where I built the other packages was a dirty trick that did not work.

Maybe I should install all the includes and libraries all in a place where the toolchain can find the correct libs and includes ?
I think you're misunderstanding PKG_CONFIG_PATH. That should be pointed at where the PC files are stored for your toolchain. Not the libs themselves and not the header files, those two would be the LD_LIBRARY_PATH and /usr/include typically.
 
Old 03-07-2017, 04:46 AM   #8
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
So what happened is that in setting PKG_CONFIG_PATH to where I built the packages it user the libusb-1.0.pc file it found in there that in turn sets stuff like libdir which differs from mu host machine (/usr/lib whereas on the build machine /usr/lib64) and that's why it's braking a little further down the line ? as is can find the required packages (because the .pc files are in the build directories).

Ok I can set the LD_LIBRARY_PATH to where it will find the correct libs bit ho do I tell the toolchain to look for includes in a non standard place ?

If these 2 are the right place
CFLAGS=-I<somepath>/include
LDFLAGS=-L<somepath>/lib

Is it possible to have a list of places to look in ? (like the colon separated list in $PATH)
Just keep adding like this:
CFLAGS="-I<somepath>/include -I<someotherpath>/include" ?
 
Old 03-07-2017, 06:02 AM   #9
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by louigi600 View Post
So what happened is that in setting PKG_CONFIG_PATH to where I built the packages it user the libusb-1.0.pc file it found in there that in turn sets stuff like libdir which differs from mu host machine (/usr/lib whereas on the build machine /usr/lib64) and that's why it's braking a little further down the line ? as is can find the required packages (because the .pc files are in the build directories).

Ok I can set the LD_LIBRARY_PATH to where it will find the correct libs bit ho do I tell the toolchain to look for includes in a non standard place ?

If these 2 are the right place
CFLAGS=-I<somepath>/include
LDFLAGS=-L<somepath>/lib

Is it possible to have a list of places to look in ? (like the colon separated list in $PATH)
Just keep adding like this:
CFLAGS="-I<somepath>/include -I<someotherpath>/include" ?
Or, you could edit the PC file and point it to the correct place. They get generated or edited fairly frequently during the build. IIRC there are several that need to be edited during LFS Chapter 6 to keep host references out of them.

https://people.freedesktop.org/~dbn/...fig-guide.html
 
Old 03-07-2017, 06:16 AM   #10
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
Quote:
Originally Posted by Luridis View Post
Or, you could edit the PC file and point it to the correct place. They get generated or edited fairly frequently during the build. IIRC there are several that need to be edited during LFS Chapter 6 to keep host references out of them.

https://people.freedesktop.org/~dbn/...fig-guide.html
If I do that I'll probably have-to put the pc file back to a sane state (for the target machine) before installing and packaging.
If the target machine will never compile stuff I suppose can I leave it in a mess ?
in that case maybe would it not be better not packaging it rather then have it inconsistent with what will be on the target machine ?
 
Old 03-07-2017, 06:59 AM   #11
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
Are you using the LFS book or the CLFS book?
 
Old 03-07-2017, 07:05 AM   #12
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
Nope I'm using knowledge from my head but since I'm building from scratch I still refer to what I'm doing as LFS
... maybe I should give it a thorough reading.
 
Old 03-07-2017, 07:30 AM   #13
Luridis
Member
 
Registered: Mar 2014
Location: Texas
Distribution: LFS 8.0 Custom, Merged Usr, Linux 4.9.35
Posts: 472

Rep: Reputation: 114Reputation: 114
If you're cross compiling architectures... use CLFS.
 
Old 03-07-2017, 07:42 AM   #14
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
Did not build myself the xtoolchain, ok it was compiled on my machine but I had hardly any control over how it was done ... I'm using uclibc's buildroot to do that for me.
I've got too much work to read CLFS now but I'll give that a read asap.
 
Old 03-10-2017, 10:09 AM   #15
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 480
Blog Entries: 13

Original Poster
Rep: Reputation: 43
I found at least part of the issue: silly me had x86 kernel headers in the arm xtoolchain includes.
Now some packages that were failing are now xcompiling ... but it has not fixed usbutils.

Code:
In file included from /tmp/build/usbutils-008/usbhid-dump/include/uhd/dev.h:31:0,
                 from dev.c:29:
/tmp/build/usbutils-008/usbhid-dump/include/uhd/libusb.h:30:20: fatal error: libusb.h: No such file or directory
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Cross compiling - Static linking problem s.a.pishvaie Programming 7 01-18-2016 05:59 AM
Problem about cross-platiform compiling bfyviolin Programming 3 06-21-2011 09:48 AM
Problem while cross compiling dsouza_jack Linux - Embedded & Single-board computer 1 03-05-2008 08:58 AM
problem in configuring wxwidgets for cross compiling ra2000 Programming 5 12-13-2006 09:35 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 04:16 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration