Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How can we compile libvchan
#1
Hello guys,

I have a problem when cross-compiling the libvchan tools to be launched on Dom0 (or DomU) on ZCU102 .
First, I cloned the buildroot from https://github.com/dornerworks/buildroot.git and I got error in the host-python3 3.4.2 building.
Then, I thought that maybe the repo is not up-to-date, so I searched another repo and I cloned git://git.busybox.net/buildroot.
This repo works and I was able to perform make till the end. I followed the steps in the guide Section 5.3 with a little modification as I didn't use the same buildroot :
Quote:./configure --host=aarch64-buildroot-linux-uclibc --enable-tools
$ make dist-tools CROSS_COMPILE=aarch64-buildroot-linux-uclibc- XEN_TARGET_ARCH=arm64 CONFIG_EARLY_PRINTK=zynqmp

However, when I tried to execute the command ./vchan-node1 server read 0 data/vchan, I only got -sh: ./vchan-node1: No such file or directory Sad

I followed the Petalinux flow to generate the xen, dom0 and domU. I don't have gcc on the board. That's why I tried to cross-compile libvchan.
Has anybody tried this before? If my method is wrong, would you tell me how can I do the cross-compilation and which tools should I use?
Or at least, would you tell me which tool support libxen in order to compile libvchan?

Thank you so much.
Reply
#2
(01-08-2018, 09:51 AM)ariefgrand Wrote: Hello guys,

I have a problem when cross-compiling the libvchan tools to be launched on Dom0 (or DomU) on ZCU102 .
First, I cloned the buildroot from https://github.com/dornerworks/buildroot.git and I got error in the host-python3 3.4.2 building.
 
What's the error?

(01-08-2018, 09:51 AM)ariefgrand Wrote: However, when I tried to execute the command ./vchan-node1 server read 0 data/vchan, I only got -sh: ./vchan-node1: No such file or directory Sad

Did you follow the instructions in 6.4.2 and copy the libvchan files to the SD card or loopback image?

     Nate
Reply
#3
Thank you for the reply.
I used gcc-4.9 as apparently my gcc-6.0 generated this error
Quote:cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
After I changed the gcc version, I was able to advanced until another error in python building.
So here is the error message:
Quote:
Code:
>>> host-python3 3.4.2 Building
.......
./python: error while loading shared libraries: libpython3.4m.so.1.0: cannot open shared object file: No such file or directory
Makefile:589: recipe for target 'sharedmods' failed
make[1]: *** [sharedmods] Error 127
.......

And yes, I copied the entire /xen/xen-src/tools/ to rootfs of my Dom0 that I built from Petalinux-v2017.3.

Regards,
Arief
Reply
#4
(01-08-2018, 04:05 PM)ariefgrand Wrote: And yes, I copied the entire /xen/xen-src/tools/ to rootfs of my Dom0 that I built from Petalinux-v2017.3.

Regards,
Arief

What directory did you copy it to and what directory are you trying to run that command from?  Assuming you followed the steps the answer to both should be "/root/libvchan-example".

     Nate
Reply
#5
(01-08-2018, 04:05 PM)ariefgrand Wrote: Thank you for the reply.
I used gcc-4.9 as apparently my gcc-6.0 generated this error
Quote:cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
After I changed the gcc version, I was able to advanced until another error in python building.
So here is the error message:
Quote:
Code:
>>> host-python3 3.4.2 Building
.......
./python: error while loading shared libraries: libpython3.4m.so.1.0: cannot open shared object file: No such file or directory
Makefile:589: recipe for target 'sharedmods' failed
make[1]: *** [sharedmods] Error 127
.......

Regards,
Arief

Which Petalinux toolchain are you using to build buildroot?  2016.X includes gcc 5.2 and 2017.X includes a 6.2, neither of which match the version numbers you listed.

I did a quick test and it built for me without any errors.

     Nate
Reply
#6
(01-10-2018, 02:57 PM)Nathan.Studer Wrote:
(01-08-2018, 04:05 PM)ariefgrand Wrote: Thank you for the reply.
I used gcc-4.9 as apparently my gcc-6.0 generated this error
Quote:cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
After I changed the gcc version, I was able to advanced until another error in python building.
So here is the error message:
Quote:
Code:
>>> host-python3 3.4.2 Building
.......
./python: error while loading shared libraries: libpython3.4m.so.1.0: cannot open shared object file: No such file or directory
Makefile:589: recipe for target 'sharedmods' failed
make[1]: *** [sharedmods] Error 127
.......

Regards,
Arief

Which Petalinux toolchain are you using to build buildroot?  2016.X includes gcc 5.2 and 2017.X includes a 6.2, neither of which match the version numbers you listed.

I did a quick test and it built for me without any errors.

     Nate

I used Petalinux 2017.3. Sorry, you are correct. The gcc version was 6.2.1.
It generated the error below for me
Code:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here


Arief
Reply
#7
Which buildroot branch are you on?  I've done a test build with several versions of Petalinux as well as the Xilinx SDK and unfortunately I can't replicate this error using the "xen-guest-fs" branch.

If it's an option, you could update to the 2017.1 version of XZD, which includes libvchan in the release image and uses Yocto instead of buildroot for the root file system.

     Nate
Reply
#8
I used xen-guest-fs branch, just like you. Okay, I'll try your suggestion using Yocto for the rootfs.
Thank you.

Regards,
Arief
Reply
#9
What are the advantages of using Yocto? I've heard it mentioned a couple of times but I'm kind of unclear on that.
Reply
#10
(01-21-2018, 11:51 AM)StanfordBry Wrote: What are the advantages of using Yocto? I've heard it mentioned a couple of times but I'm kind of unclear on that.

I wrote a blog post awhile ago about why we made the switch.  The major reason being that most embedded SoC vendors are now using Yocto, so a Yocto based distribution is easier to support than a buildroot based one.

http://dornerworks.com/blog/jumping-yocto-bandwagon

A general comparison of Yocto vs. Buildroot isn't something I can easily cover in a forum post, but here is a link that at least gives an overview:

https://lwn.net/Articles/682540/

     Nate
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)