Re: rtems-libbsd fails for gr740
Yup that did the trick. Thanks!
Regards,
Niko
On Mon, Aug 27, 2018 at 8:35 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Nicolas,
>
> I tried it on a VM with the steps below and can reproduce your problem.
> The waf configure checks a header file:
>
> Configure variant: : sparc-rtems5-gr740-default
> Checking for header rtems/rtems-debugger.h : yes
> 'configure' finished successfully (0.953s)
>
> This is later used in:
>
> self.addTest(mm.generator['test-if-header']('debugger01',
> 'rtems/rtems-debugger.h',
> ['test_main'],
> runTest = False, netTest = True,
> extraLibs =
> ['debugger']))
>
> I have no idea why this works on my main development machine. We should
> check that the libdebugger.a is present and not the header file. For
> now, please remove the lines above from libbsd.py.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd fails for gr740
Hm that's weird cause I downloaded and built everything from scratch yesterday. I'll try again and report back. Thanks, Niko On Fri, Aug 24, 2018 at 2:57 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 24/08/18 11:32, Nicolas Tsiogkas wrote: > > I'm getting this error from repositories cloned yesterday (rtems > > commit: a36aa8628f11385ab0d9061d6b37d179879322e7, libbsd commit: > > 1d99262f59e5b7427e926ed045610a1c049be337) > > It works for me with the master versions of today. Please try to remove > the BSP installation and try to build it again. Maybe there is some > obsolete header file in the installation tree. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd fails for gr740
Hi Sebastian, I'm getting this error from repositories cloned yesterday (rtems commit: a36aa8628f11385ab0d9061d6b37d179879322e7, libbsd commit: 1d99262f59e5b7427e926ed045610a1c049be337) Ok that would explain that it is that different. Thanks, Niko On Fri, Aug 24, 2018 at 11:23 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Nicolas, > > On 24/08/18 10:59, Nicolas Tsiogkas wrote: > > Hi, > > > > I am trying to build the libbsd for a gr740 target. It fails while > > building debugger01.exe with error: > > > > Waf: Entering directory > > > `/home/niko/rtems/rtems-src/rtems-libbsd/build/sparc-rtems5-gr740-default' > > [1906/2014] Linking build/sparc-rtems5-gr740-default/debugger01.exe > > > /home/niko/rtems/5/lib/gcc/sparc-rtems5/7.3.0/../../../../sparc-rtems5/bin/ld: > > > cannot find -ldebugger > > collect2: error: ld returned 1 exit status > > > > Waf: Leaving directory > > > `/home/niko/rtems/rtems-src/rtems-libbsd/build/sparc-rtems5-gr740-default' > > Build failed > > -> task in 'debugger01.exe' failed with exit status 1 (run with -v to > > display more information) > > > > as far as I understand debugger was moved out of libbsd but it is not > > built for the gr740 for some reason. Is this a known normal behaviour? > > do you have this error with the latest master versions of RTEMS and libbsd? > > > > > In addition which networking stack version is used in the rtems kernel > > (when I build with --enable-networking)? Is it from FreeBSD9.3 or even > > older? as the bpf provided there is not on par with the rtems-libbsd one. > > The network stack included in the RTEMS sources is about 20 years old. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
rtems-libbsd fails for gr740
Hi, I am trying to build the libbsd for a gr740 target. It fails while building debugger01.exe with error: Waf: Entering directory `/home/niko/rtems/rtems-src/rtems-libbsd/build/sparc-rtems5-gr740-default' [1906/2014] Linking build/sparc-rtems5-gr740-default/debugger01.exe /home/niko/rtems/5/lib/gcc/sparc-rtems5/7.3.0/../../../../sparc-rtems5/bin/ld: cannot find -ldebugger collect2: error: ld returned 1 exit status Waf: Leaving directory `/home/niko/rtems/rtems-src/rtems-libbsd/build/sparc-rtems5-gr740-default' Build failed -> task in 'debugger01.exe' failed with exit status 1 (run with -v to display more information) as far as I understand debugger was moved out of libbsd but it is not built for the gr740 for some reason. Is this a known normal behaviour? In addition which networking stack version is used in the rtems kernel (when I build with --enable-networking)? Is it from FreeBSD9.3 or even older? as the bpf provided there is not on par with the rtems-libbsd one. Thanks in advance for your time. Kind regards, Niko ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
Hi,
So I have done some debugging.
there were 2 issues.
First issue regarding the timer is the way the timeout is calculated. It
requires at least 11 milliseconds of timeout to be able to handle it.
Second issue that I faced is that flags were not passed correctly to the
bpfopen function so the bpf was not opened in read/write mode. That's why
packets were not received.
Attaching a patch.
Thanks for the help!
Cheers,
Niko
On Fri, Jun 29, 2018 at 9:40 AM Nicolas Tsiogkas wrote:
> Thanks!
>
> Shouldn't net have some device though since I want to debug the networking
> stack?
>
> For now I run it with -nographic -serial stdio -serial
> mon:tcp:localhost:12456 -M xilinx-zynq-a9 -net
> nic,model=cadence_gem,macaddr=0e:b0:ba:5e:ba:11 -net
> tap,ifname=tap0,script=no,downscript=no -m 256M -kernel slaveinfo.exe
>
> I'll check soon and report back. Thanks again!
>
> Cheers,
> Niko
>
> On Fri, Jun 29, 2018 at 9:32 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 29/06/18 09:14, Nicolas Tsiogkas wrote:
>> > I see thanks.
>> >
>> > Any idea or documentation on how to do that on qemu? I'm afraid that
>> > my experience is rather limited.
>> >
>> > I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp.
>>
>> You can run the xilinx_zynq_a9_qemu with
>>
>> QEMU_AUDIO_DRV=none qemu-system-arm -serial null -serial mon:stdio -net
>> none -nographic -M xilinx-zynq-a9 -m 256M -kernel app.exe -s -S
>>
>> It waits for a GDB client connection on localhost:1234.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>>
diff --git a/freebsd/sys/net/bpf.c b/freebsd/sys/net/bpf.c
index 259a253..520712b 100644
--- a/freebsd/sys/net/bpf.c
+++ b/freebsd/sys/net/bpf.c
@@ -2907,7 +2907,7 @@ bpf_imfs_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
{
struct bpf_d *d;
- d = bpfopen(NULL, 0, 0, NULL);
+ d = bpfopen(NULL, oflag+1, 0, NULL);
iop->data1 = d;
if (d != NULL) {
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
Thanks! Shouldn't net have some device though since I want to debug the networking stack? For now I run it with -nographic -serial stdio -serial mon:tcp:localhost:12456 -M xilinx-zynq-a9 -net nic,model=cadence_gem,macaddr=0e:b0:ba:5e:ba:11 -net tap,ifname=tap0,script=no,downscript=no -m 256M -kernel slaveinfo.exe I'll check soon and report back. Thanks again! Cheers, Niko On Fri, Jun 29, 2018 at 9:32 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/06/18 09:14, Nicolas Tsiogkas wrote: > > I see thanks. > > > > Any idea or documentation on how to do that on qemu? I'm afraid that > > my experience is rather limited. > > > > I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp. > > You can run the xilinx_zynq_a9_qemu with > > QEMU_AUDIO_DRV=none qemu-system-arm -serial null -serial mon:stdio -net > none -nographic -M xilinx-zynq-a9 -m 256M -kernel app.exe -s -S > > It waits for a GDB client connection on localhost:1234. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
I see thanks.
Any idea or documentation on how to do that on qemu? I'm afraid that my
experience is rather limited.
I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp.
Thank you for your time.
Kind regards,
Niko
On Fri, Jun 29, 2018 at 7:01 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 28/06/18 14:09, Nicolas Tsiogkas wrote:
> > Hi,
> >
> > I have observed a weird behaviour while setting the BIOCSRTIMEOUT for
> > a bpf.
> >
> > When setting it to low values (less than a second) as it can be seen
> > below the bpf is actually blocking instead of waiting and continuing.
> >
> > struct timeval timeout;
> > timeout.tv_sec = 0;
> > timeout.tv_usec = 1;
> > if (ioctl(*bpf, BIOCSRTIMEOUT, ) == -1) {
> > perror("BIOCSRTIMEOUT");
> > return 0;
> > }
> >
> > This was working with the libbsd 4.11 branch. Is this a known bug?
>
> No, we use the bpf with libpcap on the master. You have to debug this.
>
> >
> > In addition the bpf is not receiving/reading anything incoming while
> > with wireshark I can confirm that there are things on the wire and the
> > bpf is in promiscuous mode. Still this was working on the 4.11 branch.
> > Any idea on how to debug this?
>
> I would set a break point to the network interface receive function and
> then follow the path of the Ethernet frame.
>
> >
> > Thanks in advance.
> >
> > Cheers,
> > Niko
> >
> >
> > ___
> > users mailing list
> > users@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Error building libbsd
Hi, some later report. I compiled the examples and some private project with waf and all was smoothly. I suspect that there must be something with the libbsd scripts. Cheers, Niko On Mon, Jun 25, 2018 at 10:20 AM Nicolas Tsiogkas wrote: > Hi Christian, > > I will go with python3 indeed as I have to finally close a patch for > Ethercat SOEM working with RTEMS 5. In parallel I will try to investigate > with the waf examples and report back. > > Thanks for the prompt reply and effort. :) > > Regards, > Niko > > On Mon, Jun 25, 2018 at 10:15 AM Christian Mauderer < > christian.maude...@embedded-brains.de> wrote: > >> Hello Niko, >> >> if the patch didn't do anything to your output, the error has to happen >> quite early. The first one should have been printed when the build() >> function of the wscript has been reached. So I would assume that it >> already happens before that. >> >> If you have time and desire to find the bug, you might could try to >> build some other tools that use waf as a build system (for example the >> waf examples from the waf website). Otherwise I would suggest to go with >> python3 for now. >> >> Note that it shouldn't really be a problem with python2 in general: My >> OpenSUSE machine is using python2 too and has no problems with the >> current libbsd. As far as I know most distributions still use python2 as >> the default case. I only know Arch Linux that does use python3. >> >> Best regards >> >> Christian Mauderer >> >> Am 25.06.2018 um 10:08 schrieb Nicolas Tsiogkas: >> > Hi, >> > >> > sorry for the late reply. >> > >> > So, the patch didn't do a thing. Got the same print. >> > >> > But I tried to run waf with python3 >> > >> > python3 /home/niko/.local/bin/waf-2.0.8 >> > >> > and >> > >> > python3 /home/niko/.local/bin/waf-2.0.8 install >> > >> > That was successful. From that I can assume that there is some issue >> > with the python2 shipped with ubuntu? I can try at home as well in case >> > there is something specific with the python configuration on my current >> > pc and report back. >> > >> > Thanks for the help. >> > >> > Regards, >> > Niko >> > >> > On Fri, Jun 22, 2018 at 9:56 PM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote: >> > >> > Hello Niko, >> > >> > Am 22.06.2018 um 13:23 schrieb Nicolas Tsiogkas: >> > > Hi, >> > > >> > > waf was downloaded by the website (waf.io <http://waf.io> >> > <http://waf.io>) >> > > >> > > niko@im-desktop-021:~/sandbox/rtems-libbsd$ which waf-2.0.8 >> > > /home/niko/.local/bin/waf-2.0.8 >> > >> > Should be OK. >> > >> > > >> > > running also with waf-2.0.4 which used to work gives the same >> error >> > > >> > > ~/sandbox/rtems-libbsd$ waf-2.0.8 -v >> > > Could not create the directory ///h >> > > >> > > ~/sandbox/rtems-libbsd$ waf-2.0.4 -v >> > > Could not create the directory ///h >> > > >> > > that's pretty weird. >> > >> > Yes it is. The build scripts do a lot of stuff in preparation for >> the >> > real build. But as far as I know nothing of it should create a >> > directory. The first operation that creates a directory should >> print the >> > following line: >> > >> > [ 1/99] Compiling >> > testsuite/include/rtems/bsd/test/network-config.h.in >> > <http://network-config.h.in> >> > >> > Anyway: To find out how far you get into the build scripts, I added >> a >> > few debug messages. Could you try to apply the attached patch and >> see >> > whether it prints some messages. Note that the messages are not >> really >> > clean and it seems that there is a bug that prints them two times. >> But >> > they should give a hint when the build process breaks. >> > >> > Best Regards >> > >> > Christian Mauderer >> > >> > > >> > > Regards, >> > > Niko >> > > >> > > On Fri, Jun 22, 2018 at 12:23 PM Christian Mauderer >> > > > > <mailto:christian.maude...@embedded-brains.de> >
rtems-libbsd bpf BIOCSRTIMEOUT behaviour
Hi,
I have observed a weird behaviour while setting the BIOCSRTIMEOUT for a
bpf.
When setting it to low values (less than a second) as it can be seen below
the bpf is actually blocking instead of waiting and continuing.
struct timeval timeout;
timeout.tv_sec = 0;
timeout.tv_usec = 1;
if (ioctl(*bpf, BIOCSRTIMEOUT, ) == -1) {
perror("BIOCSRTIMEOUT");
return 0;
}
This was working with the libbsd 4.11 branch. Is this a known bug?
In addition the bpf is not receiving/reading anything incoming while with
wireshark I can confirm that there are things on the wire and the bpf is
in promiscuous mode. Still this was working on the 4.11 branch. Any idea on
how to debug this?
Thanks in advance.
Cheers,
Niko
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Error building libbsd
Hi Christian, I will go with python3 indeed as I have to finally close a patch for Ethercat SOEM working with RTEMS 5. In parallel I will try to investigate with the waf examples and report back. Thanks for the prompt reply and effort. :) Regards, Niko On Mon, Jun 25, 2018 at 10:15 AM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niko, > > if the patch didn't do anything to your output, the error has to happen > quite early. The first one should have been printed when the build() > function of the wscript has been reached. So I would assume that it > already happens before that. > > If you have time and desire to find the bug, you might could try to > build some other tools that use waf as a build system (for example the > waf examples from the waf website). Otherwise I would suggest to go with > python3 for now. > > Note that it shouldn't really be a problem with python2 in general: My > OpenSUSE machine is using python2 too and has no problems with the > current libbsd. As far as I know most distributions still use python2 as > the default case. I only know Arch Linux that does use python3. > > Best regards > > Christian Mauderer > > Am 25.06.2018 um 10:08 schrieb Nicolas Tsiogkas: > > Hi, > > > > sorry for the late reply. > > > > So, the patch didn't do a thing. Got the same print. > > > > But I tried to run waf with python3 > > > > python3 /home/niko/.local/bin/waf-2.0.8 > > > > and > > > > python3 /home/niko/.local/bin/waf-2.0.8 install > > > > That was successful. From that I can assume that there is some issue > > with the python2 shipped with ubuntu? I can try at home as well in case > > there is something specific with the python configuration on my current > > pc and report back. > > > > Thanks for the help. > > > > Regards, > > Niko > > > > On Fri, Jun 22, 2018 at 9:56 PM Christian Mauderer > <mailto:l...@c-mauderer.de>> wrote: > > > > Hello Niko, > > > > Am 22.06.2018 um 13:23 schrieb Nicolas Tsiogkas: > > > Hi, > > > > > > waf was downloaded by the website (waf.io <http://waf.io> > > <http://waf.io>) > > > > > > niko@im-desktop-021:~/sandbox/rtems-libbsd$ which waf-2.0.8 > > > /home/niko/.local/bin/waf-2.0.8 > > > > Should be OK. > > > > > > > > running also with waf-2.0.4 which used to work gives the same error > > > > > > ~/sandbox/rtems-libbsd$ waf-2.0.8 -v > > > Could not create the directory ///h > > > > > > ~/sandbox/rtems-libbsd$ waf-2.0.4 -v > > > Could not create the directory ///h > > > > > > that's pretty weird. > > > > Yes it is. The build scripts do a lot of stuff in preparation for the > > real build. But as far as I know nothing of it should create a > > directory. The first operation that creates a directory should print > the > > following line: > > > > [ 1/99] Compiling > > testsuite/include/rtems/bsd/test/network-config.h.in > > <http://network-config.h.in> > > > > Anyway: To find out how far you get into the build scripts, I added a > > few debug messages. Could you try to apply the attached patch and see > > whether it prints some messages. Note that the messages are not > really > > clean and it seems that there is a bug that prints them two times. > But > > they should give a hint when the build process breaks. > > > > Best Regards > > > > Christian Mauderer > > > > > > > > Regards, > > > Niko > > > > > > On Fri, Jun 22, 2018 at 12:23 PM Christian Mauderer > > > > <mailto:christian.maude...@embedded-brains.de> > > > <mailto:christian.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de>>> wrote: > > > > > > Hello Niko, > > > > > > from a quick glance, everything till the waf call looks good. > > What is > > > really odd is the output of the last waf-2.0.8 call. There > > should be a > > > lot more output starting with something like > > > > > > > > > Waf: Entering directory > > > > > > > `/home/EB/christian_m/Projekte/some-project/rtems-libbsd/build/arm-rtems5-atsamv-everything' > >
Re: Error building libbsd
Hi, sorry for the late reply. So, the patch didn't do a thing. Got the same print. But I tried to run waf with python3 python3 /home/niko/.local/bin/waf-2.0.8 and python3 /home/niko/.local/bin/waf-2.0.8 install That was successful. From that I can assume that there is some issue with the python2 shipped with ubuntu? I can try at home as well in case there is something specific with the python configuration on my current pc and report back. Thanks for the help. Regards, Niko On Fri, Jun 22, 2018 at 9:56 PM Christian Mauderer wrote: > Hello Niko, > > Am 22.06.2018 um 13:23 schrieb Nicolas Tsiogkas: > > Hi, > > > > waf was downloaded by the website (waf.io <http://waf.io>) > > > > niko@im-desktop-021:~/sandbox/rtems-libbsd$ which waf-2.0.8 > > /home/niko/.local/bin/waf-2.0.8 > > Should be OK. > > > > > running also with waf-2.0.4 which used to work gives the same error > > > > ~/sandbox/rtems-libbsd$ waf-2.0.8 -v > > Could not create the directory ///h > > > > ~/sandbox/rtems-libbsd$ waf-2.0.4 -v > > Could not create the directory ///h > > > > that's pretty weird. > > Yes it is. The build scripts do a lot of stuff in preparation for the > real build. But as far as I know nothing of it should create a > directory. The first operation that creates a directory should print the > following line: > > [ 1/99] Compiling testsuite/include/rtems/bsd/test/network-config.h.in > > Anyway: To find out how far you get into the build scripts, I added a > few debug messages. Could you try to apply the attached patch and see > whether it prints some messages. Note that the messages are not really > clean and it seems that there is a bug that prints them two times. But > they should give a hint when the build process breaks. > > Best Regards > > Christian Mauderer > > > > > Regards, > > Niko > > > > On Fri, Jun 22, 2018 at 12:23 PM Christian Mauderer > > > <mailto:christian.maude...@embedded-brains.de>> wrote: > > > > Hello Niko, > > > > from a quick glance, everything till the waf call looks good. What is > > really odd is the output of the last waf-2.0.8 call. There should be > a > > lot more output starting with something like > > > > > > Waf: Entering directory > > > > `/home/EB/christian_m/Projekte/some-project/rtems-libbsd/build/arm-rtems5-atsamv-everything' > > [ 1/122] Creating > > build/arm-rtems5-atsamv-everything/build-include/rtems/bsd/modules.h > > [ 2/122] Compiling rtemsbsd/rtems/generate_kvm_symbols > > [ 3/122] Compiling > > testsuite/include/rtems/bsd/test/network-config.h.in > > <http://network-config.h.in> > > [ 4/122] Compiling freebsd/sys/crypto/blowfish/bf_locl.h > > [ 5/122] Compiling freebsd/sys/crypto/blowfish/bf_pi.h > > ... > > > > > > You are even missing the "Waf: Entering directory". So that seems > like a > > quite early bug. > > > > You can try whether a `waf -v` provides more output. Beneath that: > Where > > does your waf come from? You call it with a version number. > > > > Best regards > > > > Christian Mauderer > > > > Am 22.06.2018 um 11:21 schrieb Nicolas Tsiogkas: > > > Hi, > > > > > > I did the process again with no luck. I am attaching a zip with > > command > > > outputs/logs. > > > > > > Regards, > > > Niko > > > > > > On Fri, Jun 22, 2018 at 9:44 AM Nicolas Tsiogkas > > mailto:lou.n...@gmail.com> > > > <mailto:lou.n...@gmail.com <mailto:lou.n...@gmail.com>>> wrote: > > > > > > Hi Christian, > > > > > > it is a fresh clone. Although I had a previous build with 4.11 > I > > > decided try from scratch given the changes. > > > > > > Error is during the build. I'm configuring normally and when I > try > > > to waf it then it fails. > > > > > > Is there any way to increase the verbosity? I will repeat all > the > > > process from scratch keeping logs so I can send them and try > > to find > > > the issue. > > > > > > Thanks for your time! > > > > > > Regards, > > > Niko > > > > > > On Thu, Jun 21, 2018 at 6:49 PM Christian Mauderer > > >
Re: Error building libbsd
Hi, I did the process again with no luck. I am attaching a zip with command outputs/logs. Regards, Niko On Fri, Jun 22, 2018 at 9:44 AM Nicolas Tsiogkas wrote: > Hi Christian, > > it is a fresh clone. Although I had a previous build with 4.11 I decided > try from scratch given the changes. > > Error is during the build. I'm configuring normally and when I try to waf > it then it fails. > > Is there any way to increase the verbosity? I will repeat all the process > from scratch keeping logs so I can send them and try to find the issue. > > Thanks for your time! > > Regards, > Niko > > On Thu, Jun 21, 2018 at 6:49 PM Christian Mauderer > wrote: > >> Am 21.06.2018 um 16:26 schrieb Nicolas Tsiogkas: >> > And apparently I forgot the host. >> > >> > It is ubuntu 16.04: >> > Linux im-desktop-021 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 >> > 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux >> > gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) >> > >> > N. >> > >> > >> > On Thu, Jun 21, 2018 at 4:19 PM Nicolas Tsiogkas > > <mailto:lou.n...@gmail.com>> wrote: >> > >> > Hi Joel, >> > >> > waf-2.0.8 configure --prefix="$sandbox/5" >> > --rtems-bsps=arm/xilinx_zynq_a9_qemu >> > >> > has the following output: >> > >> > Setting top to : >> > /home/niko/sandbox/rtems-libbsd >> > Setting out to : >> > /home/niko/sandbox/rtems-libbsd/build >> > RTEMS Version: 5 >> > Architectures: arm-rtems5 >> > Board Support Package: >> > arm-rtems5-xilinx_zynq_a9_qemu >> > Show commands: no >> > Long commands: no >> > Checking for program 'arm-rtems5-gcc': >> > /home/niko/sandbox/5/bin/arm-rtems5-gcc >> > Checking for program 'arm-rtems5-g++': >> > /home/niko/sandbox/5/bin/arm-rtems5-g++ >> > Checking for program 'arm-rtems5-gcc': >> > /home/niko/sandbox/5/bin/arm-rtems5-gcc >> > Checking for program 'arm-rtems5-ld' : >> > /home/niko/sandbox/5/bin/arm-rtems5-ld >> > Checking for program 'arm-rtems5-ar' : >> > /home/niko/sandbox/5/bin/arm-rtems5-ar >> > Checking for program 'arm-rtems5-nm' : >> > /home/niko/sandbox/5/bin/arm-rtems5-nm >> > Checking for program 'arm-rtems5-objdump' : >> > /home/niko/sandbox/5/bin/arm-rtems5-objdump >> > Checking for program 'arm-rtems5-objcopy' : >> > /home/niko/sandbox/5/bin/arm-rtems5-objcopy >> > Checking for program 'arm-rtems5-readelf' : >> > /home/niko/sandbox/5/bin/arm-rtems5-readelf >> > Checking for program 'arm-rtems5-strip' : >> > /home/niko/sandbox/5/bin/arm-rtems5-strip >> > Checking for program 'rtems-ld' : >> > /home/niko/sandbox/5/bin/rtems-ld >> > Checking for program 'rtems-tld' : >> > /home/niko/sandbox/5/bin/rtems-tld >> > Checking for program 'rtems-bin2c': >> > /home/niko/sandbox/5/bin/rtems-bin2c >> > Checking for program 'tar': /bin/tar >> > Checking for program 'gcc, cc': >> > /home/niko/sandbox/5/bin/arm-rtems5-gcc >> > Checking for program 'ar' : >> > /home/niko/sandbox/5/bin/arm-rtems5-ar >> > Checking for program 'g++, c++' : >> > /home/niko/sandbox/5/bin/arm-rtems5-g++ >> > Checking for program 'ar' : >> > /home/niko/sandbox/5/bin/arm-rtems5-ar >> > Checking for program 'gas, gcc' : >> > /home/niko/sandbox/5/bin/arm-rtems5-gcc >> > Checking for program 'ar' : >> > /home/niko/sandbox/5/bin/arm-rtems5-ar >> > Compiler version (arm-rtems5-gcc) : 7.3.0 20180125 (RTEMS 5, >> > RSB 8ee4e8cd557c25fca59bb9751751ad4172530958, Newlib 3.0.0) >> > Checking for RTEMS CPU options header : started >> > -> processing test results: all ok >> > Checking for RTEMS_DEBUG : no >> > Checking for RTEMS_MULTIPROCESSING: no >> > Checking for RTEMS_NEWLIB : yes >> > Checking
Re: Error building libbsd
Hi Christian, it is a fresh clone. Although I had a previous build with 4.11 I decided try from scratch given the changes. Error is during the build. I'm configuring normally and when I try to waf it then it fails. Is there any way to increase the verbosity? I will repeat all the process from scratch keeping logs so I can send them and try to find the issue. Thanks for your time! Regards, Niko On Thu, Jun 21, 2018 at 6:49 PM Christian Mauderer wrote: > Am 21.06.2018 um 16:26 schrieb Nicolas Tsiogkas: > > And apparently I forgot the host. > > > > It is ubuntu 16.04: > > Linux im-desktop-021 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 > > 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) > > > > N. > > > > > > On Thu, Jun 21, 2018 at 4:19 PM Nicolas Tsiogkas > <mailto:lou.n...@gmail.com>> wrote: > > > > Hi Joel, > > > > waf-2.0.8 configure --prefix="$sandbox/5" > > --rtems-bsps=arm/xilinx_zynq_a9_qemu > > > > has the following output: > > > > Setting top to : > > /home/niko/sandbox/rtems-libbsd > > Setting out to : > > /home/niko/sandbox/rtems-libbsd/build > > RTEMS Version: 5 > > Architectures: arm-rtems5 > > Board Support Package: > > arm-rtems5-xilinx_zynq_a9_qemu > > Show commands: no > > Long commands: no > > Checking for program 'arm-rtems5-gcc': > > /home/niko/sandbox/5/bin/arm-rtems5-gcc > > Checking for program 'arm-rtems5-g++': > > /home/niko/sandbox/5/bin/arm-rtems5-g++ > > Checking for program 'arm-rtems5-gcc': > > /home/niko/sandbox/5/bin/arm-rtems5-gcc > > Checking for program 'arm-rtems5-ld' : > > /home/niko/sandbox/5/bin/arm-rtems5-ld > > Checking for program 'arm-rtems5-ar' : > > /home/niko/sandbox/5/bin/arm-rtems5-ar > > Checking for program 'arm-rtems5-nm' : > > /home/niko/sandbox/5/bin/arm-rtems5-nm > > Checking for program 'arm-rtems5-objdump' : > > /home/niko/sandbox/5/bin/arm-rtems5-objdump > > Checking for program 'arm-rtems5-objcopy' : > > /home/niko/sandbox/5/bin/arm-rtems5-objcopy > > Checking for program 'arm-rtems5-readelf' : > > /home/niko/sandbox/5/bin/arm-rtems5-readelf > > Checking for program 'arm-rtems5-strip' : > > /home/niko/sandbox/5/bin/arm-rtems5-strip > > Checking for program 'rtems-ld' : > > /home/niko/sandbox/5/bin/rtems-ld > > Checking for program 'rtems-tld' : > > /home/niko/sandbox/5/bin/rtems-tld > > Checking for program 'rtems-bin2c': > > /home/niko/sandbox/5/bin/rtems-bin2c > > Checking for program 'tar': /bin/tar > > Checking for program 'gcc, cc': > > /home/niko/sandbox/5/bin/arm-rtems5-gcc > > Checking for program 'ar' : > > /home/niko/sandbox/5/bin/arm-rtems5-ar > > Checking for program 'g++, c++' : > > /home/niko/sandbox/5/bin/arm-rtems5-g++ > > Checking for program 'ar' : > > /home/niko/sandbox/5/bin/arm-rtems5-ar > > Checking for program 'gas, gcc' : > > /home/niko/sandbox/5/bin/arm-rtems5-gcc > > Checking for program 'ar' : > > /home/niko/sandbox/5/bin/arm-rtems5-ar > > Compiler version (arm-rtems5-gcc) : 7.3.0 20180125 (RTEMS 5, > > RSB 8ee4e8cd557c25fca59bb9751751ad4172530958, Newlib 3.0.0) > > Checking for RTEMS CPU options header : started > > -> processing test results: all ok > > Checking for RTEMS_DEBUG : no > > Checking for RTEMS_MULTIPROCESSING: no > > Checking for RTEMS_NEWLIB : yes > > Checking for RTEMS_POSIX_API : yes > > Checking for RTEMS_SMP: no > > Checking for RTEMS_NETWORKING : no > > Checking for RTEMS header : started > > -> processing test results: all ok > > Checking for header dlfcn.h : yes > > Checking for header rtems/pci.h : yes > > Configure variant:: > > arm-rtems5-xilinx_zynq_a9_qemu-default > > Checking for header rtems/
Re: Error building libbsd
And apparently I forgot the host. It is ubuntu 16.04: Linux im-desktop-021 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) N. On Thu, Jun 21, 2018 at 4:19 PM Nicolas Tsiogkas wrote: > Hi Joel, > > waf-2.0.8 configure --prefix="$sandbox/5" > --rtems-bsps=arm/xilinx_zynq_a9_qemu > > has the following output: > > Setting top to : /home/niko/sandbox/rtems-libbsd > Setting out to : > /home/niko/sandbox/rtems-libbsd/build > RTEMS Version: 5 > Architectures: arm-rtems5 > Board Support Package: arm-rtems5-xilinx_zynq_a9_qemu > Show commands: no > Long commands: no > Checking for program 'arm-rtems5-gcc': > /home/niko/sandbox/5/bin/arm-rtems5-gcc > Checking for program 'arm-rtems5-g++': > /home/niko/sandbox/5/bin/arm-rtems5-g++ > Checking for program 'arm-rtems5-gcc': > /home/niko/sandbox/5/bin/arm-rtems5-gcc > Checking for program 'arm-rtems5-ld' : > /home/niko/sandbox/5/bin/arm-rtems5-ld > Checking for program 'arm-rtems5-ar' : > /home/niko/sandbox/5/bin/arm-rtems5-ar > Checking for program 'arm-rtems5-nm' : > /home/niko/sandbox/5/bin/arm-rtems5-nm > Checking for program 'arm-rtems5-objdump' : > /home/niko/sandbox/5/bin/arm-rtems5-objdump > Checking for program 'arm-rtems5-objcopy' : > /home/niko/sandbox/5/bin/arm-rtems5-objcopy > Checking for program 'arm-rtems5-readelf' : > /home/niko/sandbox/5/bin/arm-rtems5-readelf > Checking for program 'arm-rtems5-strip' : > /home/niko/sandbox/5/bin/arm-rtems5-strip > Checking for program 'rtems-ld' : > /home/niko/sandbox/5/bin/rtems-ld > Checking for program 'rtems-tld' : > /home/niko/sandbox/5/bin/rtems-tld > Checking for program 'rtems-bin2c': > /home/niko/sandbox/5/bin/rtems-bin2c > Checking for program 'tar': /bin/tar > Checking for program 'gcc, cc': > /home/niko/sandbox/5/bin/arm-rtems5-gcc > Checking for program 'ar' : > /home/niko/sandbox/5/bin/arm-rtems5-ar > Checking for program 'g++, c++' : > /home/niko/sandbox/5/bin/arm-rtems5-g++ > Checking for program 'ar' : > /home/niko/sandbox/5/bin/arm-rtems5-ar > Checking for program 'gas, gcc' : > /home/niko/sandbox/5/bin/arm-rtems5-gcc > Checking for program 'ar' : > /home/niko/sandbox/5/bin/arm-rtems5-ar > Compiler version (arm-rtems5-gcc) : 7.3.0 20180125 (RTEMS 5, RSB > 8ee4e8cd557c25fca59bb9751751ad4172530958, Newlib 3.0.0) > Checking for RTEMS CPU options header : started > -> processing test results: all ok > Checking for RTEMS_DEBUG : no > Checking for RTEMS_MULTIPROCESSING: no > Checking for RTEMS_NEWLIB : yes > Checking for RTEMS_POSIX_API : yes > Checking for RTEMS_SMP: no > Checking for RTEMS_NETWORKING : no > Checking for RTEMS header : started > -> processing test results: all ok > Checking for header dlfcn.h : yes > Checking for header rtems/pci.h : yes > Configure variant:: > arm-rtems5-xilinx_zynq_a9_qemu-default > Checking for header rtems/rtems-debugger.h : yes > 'configure' finished successfully (0.744s) > > Cheers, > Niko > > On Thu, Jun 21, 2018 at 4:09 PM Joel Sherrill wrote: > >> >> >> On Thu, Jun 21, 2018 at 8:52 AM, Nicolas Tsiogkas >> wrote: >> >>> Hi, >>> >>> following the steps described in https://github.com/RTEMS/rtems-libbsd >>> I get an error >>> >>> "Could not create the directory ///h" while trying to build with waf >>> 2.0.8 >>> >>> Is it a known problem? >>> >> >> Not to me. >> >> What's your configure command and host? >> >>> >>> I have seen that the installation procedure has changed since 4.11 and >>> now the tools and the bsps are installed in the same prefix, but that >>> shouldn't matter I suppose. >>> >>> Thank you in advance. >>> >>> Regards, >>> Niko >>> >>> ___ >>> users mailing list >>> users@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >>> >> >> ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Error building libbsd
Hi Joel, waf-2.0.8 configure --prefix="$sandbox/5" --rtems-bsps=arm/xilinx_zynq_a9_qemu has the following output: Setting top to : /home/niko/sandbox/rtems-libbsd Setting out to : /home/niko/sandbox/rtems-libbsd/build RTEMS Version: 5 Architectures: arm-rtems5 Board Support Package: arm-rtems5-xilinx_zynq_a9_qemu Show commands: no Long commands: no Checking for program 'arm-rtems5-gcc': /home/niko/sandbox/5/bin/arm-rtems5-gcc Checking for program 'arm-rtems5-g++': /home/niko/sandbox/5/bin/arm-rtems5-g++ Checking for program 'arm-rtems5-gcc': /home/niko/sandbox/5/bin/arm-rtems5-gcc Checking for program 'arm-rtems5-ld' : /home/niko/sandbox/5/bin/arm-rtems5-ld Checking for program 'arm-rtems5-ar' : /home/niko/sandbox/5/bin/arm-rtems5-ar Checking for program 'arm-rtems5-nm' : /home/niko/sandbox/5/bin/arm-rtems5-nm Checking for program 'arm-rtems5-objdump' : /home/niko/sandbox/5/bin/arm-rtems5-objdump Checking for program 'arm-rtems5-objcopy' : /home/niko/sandbox/5/bin/arm-rtems5-objcopy Checking for program 'arm-rtems5-readelf' : /home/niko/sandbox/5/bin/arm-rtems5-readelf Checking for program 'arm-rtems5-strip' : /home/niko/sandbox/5/bin/arm-rtems5-strip Checking for program 'rtems-ld' : /home/niko/sandbox/5/bin/rtems-ld Checking for program 'rtems-tld' : /home/niko/sandbox/5/bin/rtems-tld Checking for program 'rtems-bin2c': /home/niko/sandbox/5/bin/rtems-bin2c Checking for program 'tar': /bin/tar Checking for program 'gcc, cc': /home/niko/sandbox/5/bin/arm-rtems5-gcc Checking for program 'ar' : /home/niko/sandbox/5/bin/arm-rtems5-ar Checking for program 'g++, c++' : /home/niko/sandbox/5/bin/arm-rtems5-g++ Checking for program 'ar' : /home/niko/sandbox/5/bin/arm-rtems5-ar Checking for program 'gas, gcc' : /home/niko/sandbox/5/bin/arm-rtems5-gcc Checking for program 'ar' : /home/niko/sandbox/5/bin/arm-rtems5-ar Compiler version (arm-rtems5-gcc) : 7.3.0 20180125 (RTEMS 5, RSB 8ee4e8cd557c25fca59bb9751751ad4172530958, Newlib 3.0.0) Checking for RTEMS CPU options header : started -> processing test results: all ok Checking for RTEMS_DEBUG : no Checking for RTEMS_MULTIPROCESSING: no Checking for RTEMS_NEWLIB : yes Checking for RTEMS_POSIX_API : yes Checking for RTEMS_SMP: no Checking for RTEMS_NETWORKING : no Checking for RTEMS header : started -> processing test results: all ok Checking for header dlfcn.h : yes Checking for header rtems/pci.h : yes Configure variant:: arm-rtems5-xilinx_zynq_a9_qemu-default Checking for header rtems/rtems-debugger.h : yes 'configure' finished successfully (0.744s) Cheers, Niko On Thu, Jun 21, 2018 at 4:09 PM Joel Sherrill wrote: > > > On Thu, Jun 21, 2018 at 8:52 AM, Nicolas Tsiogkas > wrote: > >> Hi, >> >> following the steps described in https://github.com/RTEMS/rtems-libbsd I >> get an error >> >> "Could not create the directory ///h" while trying to build with waf 2.0.8 >> >> Is it a known problem? >> > > Not to me. > > What's your configure command and host? > >> >> I have seen that the installation procedure has changed since 4.11 and >> now the tools and the bsps are installed in the same prefix, but that >> shouldn't matter I suppose. >> >> Thank you in advance. >> >> Regards, >> Niko >> >> ___ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users >> > > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Error building libbsd
Hi, following the steps described in https://github.com/RTEMS/rtems-libbsd I get an error "Could not create the directory ///h" while trying to build with waf 2.0.8 Is it a known problem? I have seen that the installation procedure has changed since 4.11 and now the tools and the bsps are installed in the same prefix, but that shouldn't matter I suppose. Thank you in advance. Regards, Niko ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
