Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-15 Thread Heinz Junkes 
If you want to get ahead, just make a version that already has a configure, then
you can save yourself the trouble with autoconf. I'd put that in the back.
Heinz 


> On 15. Jun 2020, at 20:46, Mritunjay Sharma  
> wrote:
> 
> Hello everyone, 
> 
> The latest update is that by changing a couple of things in 
> source-builder/config/ptpd-2-1.cfg which are:
> 
> "%source setup ptpd -q -n ptpd-%{ptpd_version}
> %patch setup ptpd -p1
> 
> +automake --add-missing 
> +autoreconf --install --force 
> cd ${build_top}
> 
> %build"
> 
> GitHub Link: 
> https://github.com/RTEMS/rtems-source-builder/commit/413ea684f1e8672f921ce80abbc59f1e352acbc2
> 
> The earlier configure: error: cannot find install-sh, install.sh, or shtool 
> in build-aux "../ptpd-master"/build-aux has gone
> but another error has come as follows:
> 
> "configure.ac:28: installing './compile'
> configure.ac:16: installing './install-sh'
> configure.ac:16: installing './missing'
> configure.ac:13: error: required file 'config.h.in' not found
> src/Makefile.am: installing './depcomp'
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
> 
> What can be the reason for this? Should I create another tar of this and set 
> it as the source?
> The trace and report are attached. The tutorial by Heinz has again helped me 
> a lot! 
> Thank you for that again!
> 
> Thanks,
> Mritunjay
> 
> 
> On Sun, Jun 14, 2020 at 3:07 AM Mritunjay Sharma 
>  wrote:
> First of all Heinz, I would like to thank you for such a wonderful guide 
> which really helped me fix a lot of errors. 
> After following your advice, I made certain changes to make PTPd work, 
> few errors came again but I managed to remove them with the use of Google. 
> 
> However, the recent most error has caught me in a fix and I am still trying 
> to figure it out where I went wrong. 
> 
> https://github.com/mritunjaysharma394/rtems-source-builder/tree/master/source-builder
> https://github.com/ptpd/ptpd/compare/master...mritunjaysharma394:master
> 
> The above two links will tell what changes I have made and the error that I 
> am receiving now is: 
> "configure: WARNING: unrecognized options: --disable-shared
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
> "../ptpd-master"/build-aux
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
> 
> 
> I have attached the trace log file and error report. 
> I tried to google and made few more changes in ptpd Makefile.am but it didn't 
> help.
> 
> It will be very kind of you all to help me figure out on how to tackle this 
> bug.
> 
> Thanks
> Mritunjay
> 
> On Sun, Jun 7, 2020 at 10:19 AM junkes  wrote:
> This is an unusually long text for the mailing list. I tried to write a kind 
> of tutorial using an example for a GSOC student. I'm looking forward to the 
> comments from the pros and can write it down completely. 
> 
> Hello, Mritunjay
> 
> if I understood it correctly, one idea of the rtems source builder is to make 
> existing 
> software packages usable for RTEMS. Most existing software packages do not 
> work without 
> changes in the RTEMS environment. You have already noticed this with ptpd ;-) 
> 
> The most common auto-tools and configure have trouble making the correct 
> assumptions for the rtems environment. Here you have to intervene. This can 
> be done with the builder-cfg files. 
> 
> This is a bit of hard work and you have to approach it with small steps. 
> You also have to use not so clean tricks in different places. When you have 
> achieved the integration you can/must then try to optimize it so that it 
> becomes 
> generally valid. 
> 
> That's my policy. Maybe the others here in the maillist have more ideas, also 
> for me. 
> 
> I have now tried to implement what I mean using a similar example (openntp). 
> Unfortunately, I haven't finished yet, but I hope to clear a few hurdles for 
> you. 
> 
> I was doing some digging around and I came across this: 
> https://github.com/openntpd-portable/openntpd-portable 
> 
> Here I was then confronted with the same problems as you with autoreconf etc. 
> Here it 
> didn't work, just run autoreconf twice and generate a tar-file for 
> installation like 
> I did with the ptpd from github. 
> Then I found this: 
> https://artfiles.org/openbsd/OpenNTPD/openntpd-6.2p3.tar.gz 
> 
> Now I have made a "standard" config file for rsb: 
> 
> # 
> # OpenNTPd 6.2p3 Version 1. 
> # 
> # This configuration file configure's, make's and install's OpenNTPd. 
> # 
> 
> %if %{release} == %{nil} 
> %define release 1 
> %endif 
> 
> Name:  openntpd-%{openntpd_version}-%{_host}-%{release} 
> Summary:   NTP is the Network Time Protocol. 
> Version:   %{openntpd_version} 
> Release:   %{release} 
> URL:   https://github.com/openntpd-portable 
> 
> # 
> #

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-14 Thread Heinz Junkes 
I can't find configure in the zip-file (master.zip) which you are loading..
ptpd-master still needs to be reconfigured (autoreconf -vi)
This reconfigure is missing in the cfg file.

It only works the second time and therefore cannot really be used at the 
moment. 
Unfortunately I don't know why it only works every second time.

So you have to do the reconfigure by hand once (2 times) and then save the 
result as tgz 
and load it every time you run the build.

You should also compare the %source with the right so that you do not get 
confused.

Heinz

E.g.
in rtems-source-builder/rtems

 cd sources/
unzip master.zip
cd ptpd-master/
autoreconf -vi -> fails
autoreconf -vi -> ok
cd ..
tar cvzf master.tgz ptpd-master
mv master.tgz $HOME
echo $HOME -> /home/h1
cd ..
vi ../source-builder/config/ptpd-2-1.cfg -> add the new source
sha512sum /home/h1/master.tgz
vi ../source-builder/config/ptpd-2-1.cfg -> add the hash line
../source-builder/sb-set-builder --log log.ptpd.txt 
--with-rtems-bsp=xilinx_zynq_a9_qemu --host=arm-rtems5 --prefix 
/home/h1/GSOC/RTEMS/5.0.0-m2003 net/ptpd

tail -200 rsb-report-ptpd-master-arm-rtems5-1.txt -> now on a real error ;-)

the ptpd-2-1.cfg

#
# PTPD 2.x.x Version 1.
#
# This configuration file configure's, make's and install's PTPD.
#

%if %{release} == %{nil}
%define release 1
%endif

Name:  ptpd-%{ptpd_version}-%{_host}-%{release}
Summary:   PTPD is Precision Time Protocol Daemon.
Version:   %{ptpd_version}
Release:   %{release}
URL:   http://ptpd.sourceforge.net/

#
# PTPD Source
#
#%source set ptpd https://github.com/mritunjaysharma394/ptpd/archive/master.zip
%source set ptpd file:///home/h1/master.tgz
%hash sha512 master.tgz 
9809119ddac8e98ba871f52a74230d3fc29f87ae7ffd7ece1550f196a13e83a71aaffb3ae94e6c7f334e06d612a6913d2fb070c4db05813b9aaccaa04ca91249


#
# Prepare the source code.
#
%prep
 build_top=$(pwd)

 source_dir_ptpd="ptpd-%{ptpd_version}"
…


> On 13. Jun 2020, at 23:37, Mritunjay Sharma  
> wrote:
> 
> First of all Heinz, I would like to thank you for such a wonderful guide 
> which really helped me fix a lot of errors. 
> After following your advice, I made certain changes to make PTPd work, 
> few errors came again but I managed to remove them with the use of Google. 
> 
> However, the recent most error has caught me in a fix and I am still trying 
> to figure it out where I went wrong. 
> 
> https://github.com/mritunjaysharma394/rtems-source-builder/tree/master/source-builder
> https://github.com/ptpd/ptpd/compare/master...mritunjaysharma394:master
> 
> The above two links will tell what changes I have made and the error that I 
> am receiving now is: 
> "configure: WARNING: unrecognized options: --disable-shared
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
> "../ptpd-master"/build-aux
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
> 
> 
> I have attached the trace log file and error report. 
> I tried to google and made few more changes in ptpd Makefile.am but it didn't 
> help.
> 
> It will be very kind of you all to help me figure out on how to tackle this 
> bug.
> 
> Thanks
> Mritunjay
> 
> On Sun, Jun 7, 2020 at 10:19 AM junkes  wrote:
> This is an unusually long text for the mailing list. I tried to write a kind 
> of tutorial using an example for a GSOC student. I'm looking forward to the 
> comments from the pros and can write it down completely. 
> 
> Hello, Mritunjay
> 
> if I understood it correctly, one idea of the rtems source builder is to make 
> existing 
> software packages usable for RTEMS. Most existing software packages do not 
> work without 
> changes in the RTEMS environment. You have already noticed this with ptpd ;-) 
> 
> The most common auto-tools and configure have trouble making the correct 
> assumptions for the rtems environment. Here you have to intervene. This can 
> be done with the builder-cfg files. 
> 
> This is a bit of hard work and you have to approach it with small steps. 
> You also have to use not so clean tricks in different places. When you have 
> achieved the integration you can/must then try to optimize it so that it 
> becomes 
> generally valid. 
> 
> That's my policy. Maybe the others here in the maillist have more ideas, also 
> for me. 
> 
> I have now tried to implement what I mean using a similar example (openntp). 
> Unfortunately, I haven't finished yet, but I hope to clear a few hurdles for 
> you. 
> 
> I was doing some digging around and I came across this: 
> https://github.com/openntpd-portable/openntpd-portable 
> 
> Here I was then confronted with the same problems as you with autoreconf etc. 
> Here it 
> didn't work, just run autoreconf twice and generate a tar-file for 
> installation like 
> I did with the ptpd from github. 
> Then I found this: 
> https://artfiles.org/openbsd/OpenNTPD/openntpd-6.2p3.tar.gz 
> 
> Now I have made a

RE: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-11 Thread Jan.Sommer 


> -Original Message-
> From: Chris Johns [mailto:chr...@rtems.org]
> Sent: Thursday, June 11, 2020 2:26 AM
> To: Sommer, Jan; mritunjaysharma...@gmail.com
> Cc: rtems-de...@rtems.org
> Subject: Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This
> time building for xilinx_zynq_a9_qemu
> 
> On 5/6/20 6:03 pm, jan.som...@dlr.de wrote:
> > We came across the PPSi library for PTP support some time ago:
> https://ohwr.org/project/ppsi
> > In their documentation its says they started with ptpd and then made an
> overhaul of the source code.
> 
> Interesting. Did you check the licenses and authors?
> 
> A search for "ptp v2.1.0" lists PTP v2.1.0 in SF and github. The github repo
> seems a more recent version of the SF repo but they seem similar. 

In the PPSi manual they write: 

"The algorithm and computation routines regarding the basic ieee 1588 are 
derived from the
PTPd project, v.2.1.0 (see AUTHORS for details about copyright); but as of 
March 2013 very
little remains of the original code base."

In their AUTHORS file they seem to have copied the information from here: 
https://sourceforge.net/p/ptpd/code/HEAD/tree/branches/ptpd-2.1.1/COPYRIGHT

>The PPSi code is GPLv2 and the SF and github code is 2C-BSD and the list of 
>copyright
> holders is different.
> 

Most of it seems to be LGPL with 2 exceptions according to the manual:

"The code is licensed according to the GNU LGPL, version 2.1 or later. Some 
files are individually
released to the public domain, when we think they are especially simple or 
generic.
Both the full and the partial printf code is distributed according to the 
GPL-2, as it comes from
the Linux kernel. This means that any code using our diagnostics fall under the 
GPL requirements; you may compile and use the diagnostic code internally with 
your own proprietary code
but you can’t distribute binaries with diagnostics without the complete source 
code and associated rights. You may avoid the GPL requirements by using 
different printf implementations; if
so we’d love to have them contributed back in the package.
The same issue about the GPL license applies to the div64_32 function. We need 
this implementation in our wrpc code base because the default libgcc division 
is very big, and we are always
tight with our in-FPGA memory space."

It would have been nice if this information would be more prominent in their 
repository and not hidden in the manual.

Cheers,

   Jan

> > They also claim portability as one of their goals. We haven't had time to
> look at it closer yet, but the projects looks a bit more active and seems to
> have the CERN behind it.
> 
> Then I hope the copyright is in order.
> 
> > Maybe it is worth checking out, if ptpd keeps making trouble.
> 
> It is GPL when the other code I have looked at it BSD.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-10 Thread Chris Johns 
On 5/6/20 6:03 pm, jan.som...@dlr.de wrote:
> We came across the PPSi library for PTP support some time ago: 
> https://ohwr.org/project/ppsi
> In their documentation its says they started with ptpd and then made an 
> overhaul of the source code.

Interesting. Did you check the licenses and authors?

A search for "ptp v2.1.0" lists PTP v2.1.0 in SF and github. The github repo
seems a more recent version of the SF repo but they seem similar. The PPSi code
is GPLv2 and the SF and github code is 2C-BSD and the list of copyright holders
is different.

> They also claim portability as one of their goals. We haven't had time to 
> look at it closer yet, but the projects looks a bit more active and seems to 
> have the CERN behind it.

Then I hope the copyright is in order.

> Maybe it is worth checking out, if ptpd keeps making trouble.

It is GPL when the other code I have looked at it BSD.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-06 Thread junkes 

This is an unusually long text for the mailing list. I tried to write a
kind 
of tutorial using an example for a GSOC student. I'm looking forward to
the 
comments from the pros and can write it down completely. 


Hello, Mritunjay

if I understood it correctly, one idea of the rtems source builder is to
make existing 
software packages usable for RTEMS. Most existing software packages do
not work without 
changes in the RTEMS environment. You have already noticed this with
ptpd ;-) 


The most common auto-tools and configure have trouble making the correct

assumptions for the rtems environment. Here you have to intervene. This
can 
be done with the builder-cfg files. 


This is a bit of hard work and you have to approach it with small steps.

You also have to use not so clean tricks in different places. When you
have 
achieved the integration you can/must then try to optimize it so that it
becomes 
generally valid. 


That's my policy. Maybe the others here in the maillist have more ideas,
also for me. 


I have now tried to implement what I mean using a similar example
(openntp). 
Unfortunately, I haven't finished yet, but I hope to clear a few hurdles
for you. 

I was doing some digging around and I came across this: 
https://github.com/openntpd-portable/openntpd-portable 


Here I was then confronted with the same problems as you with autoreconf
etc. Here it 
didn't work, just run autoreconf twice and generate a tar-file for
installation like 
I did with the ptpd from github. 
Then I found this:
https://artfiles.org/openbsd/OpenNTPD/openntpd-6.2p3.tar.gz 

Now I have made a "standard" config file for rsb: 

# 
# OpenNTPd 6.2p3 Version 1. 
# 
# This configuration file configure's, make's and install's OpenNTPd. 
# 

%if %{release} == %{nil} 
%define release 1 
%endif 

Name:  openntpd-%{openntpd_version}-%{_host}-%{release} 
Summary:   NTP is the Network Time Protocol. 
Version:   %{openntpd_version} 
Release:   %{release} 
URL:   https://github.com/openntpd-portable 

# 
# NTP Source 
# 
%source set openntpd

https://artfiles.org/openbsd/OpenNTPD/openntpd-%{openntpd_version}.tar.gz

%hash sha512 openntpd-%{openntpd_version}.tar.gz
56a04bfd8b161b365607673ac80086ff53ae943938fa49bf52edbc541432eca30730a46a4af581fe26ce3bbceb144cb25982a38959b7a3f9304c727fe60f9
f50 

# 
# Prepare the source code. 
# 
%prep
build_top=$(pwd) 

source_dir_openntpd="openntpd-%{openntpd_version}" 
%source setup openntpd -q -n openntpd-%{openntpd_version} 
%patch setup openntpd -p1 

cd ${build_top} 

%build 
build_top=$(pwd) 

%{build_directory} 

mkdir -p ${build_dir} 
cd ${build_dir} 

%{host_build_flags} 

../${source_dir_openntpd}/configure \ 
  --host=%{_host} \ 
  --prefix=%{_prefix} \ 
  --bindir=%{_bindir} \ 
  --exec_prefix=%{_exec_prefix} \ 
  --includedir=%{_includedir} \ 
  --libdir=%{_libdir} \ 
  --libexecdir=%{_libexecdir} \ 
  --mandir=%{_mandir} \ 
  --infodir=%{_infodir} \ 
  --datadir=%{_datadir} \ 
  --disable-shared \ 
  --enable-static \ 
  --with-gnu-ld \ 
  --disable-https-constraint 

%{__make} all 

cd ${build_top} 

%install 
build_top=$(pwd) 

%{__rmdir} $SB_BUILD_ROOT 

cd ${build_dir} 
%{__make} DESTDIR=$SB_BUILD_ROOT install 
cd ${build_top} 

Then I "executed" that. 
[h1@earth rtems (master *)]$ ../source-builder/sb-set-builder --log

log.ntpd.txt --with-rtems-bsp=xilinx_zynq_a9_qemu --host=arm-rtems5
--prefix /home/h1/GSOC/RTEMS/5.0.0-m20
03 net/ntpd 
RTEMS Source Builder - Set Builder, 5 (26e335ca159e modified) 
Build Set: net/ntpd 
config: net/openntpd-6.2p3-1.cfg 
package: openntpd-6.2p3-arm-rtems5-1 
building: openntpd-6.2p3-arm-rtems5-1 
error: building openntpd-6.2p3-arm-rtems5-1 
Build FAILED 
See error report: rsb-report-openntpd-6.2p3-arm-rtems5-1.txt 
error: building openntpd-6.2p3-arm-rtems5-1 
Build Set: Time 0:00:16.036623 
Build FAILED 

Error! I looked at that one: 
[h1@earth rtems (master *)]$ tail -20
rsb-report-openntpd-6.2p3-arm-rtems5-1.txt 
CC   setproctitle.lo 
CC   bsd-setresgid.lo 
CC   bsd-setresuid.lo 
CCLD libcompat.la 
arm-rtems5-ar: `u' modifier ignored since `D' is the default (see `U') 
CCLD libcompatnoopt.la 
arm-rtems5-ar: `u' modifier ignored since `D' is the default (see `U') 
make[1]: Leaving directory

'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/compat'

Making all in src 
make[1]: Entering directory

'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src'

CC   ntpd-client.o 
arm-rtems5-gcc: fatal error:

/home/h1/GSOC/RTEMS/5.0.0-m2003/arm-rtems5/xilinx_zynq_a9_qemu/lib/bsp_specs:
attempt to rename spec 'endfile' to already defined spec 'old_endfi
le' 
compilation terminated. 
Makefile:526: recipe for target 'ntpd-client.o' failed 
make[1]: *** [ntpd-client.o] Error 1 
make[1]: Leaving directory

'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src'

Makefile:401: recipe for target

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-05 Thread Gedare Bloom 
Is this the same error Heinz said he got every other time? Try it
twice, see what happens...

On Fri, Jun 5, 2020 at 5:31 PM Mritunjay Sharma
 wrote:
>
>
> Thank you so much Heinz for such a detailed response.
> It really helped me a lot.
>
> As advised by you and Heinz, I changed the source to 
> https://github.com/mritunjaysharma394/ptpd/archive/master.zip
> with suggested changes. However, I have encountered few bugs again related to 
> autoreconf.
> It looks somewhat like this:
>
> + autoreconf -i -v
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal -I m4
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: creating directory build-aux
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /home/mritunjay/development/rtems/5/bin/autoconf
> configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /home/mritunjay/development/rtems/5/bin/autoconf failed with exit 
> status: 1
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1
>
> I have attached the error report as well and changes in cfg files can be 
> found here:
> https://github.com/mritunjaysharma394/rtems-source-builder/commit/6b6bb2b3bd778ebe56e9a1bf3aec1747b078fd39
>
> Thanks,
> Mritunjay
>
>
> On Fri, Jun 5, 2020 at 2:53 AM Gedare Bloom  wrote:
>>
>> On Thu, Jun 4, 2020 at 1:38 PM junkes  wrote:
>> >
>> > Hallo Mritunjay,
>> >
>> > You can't just take the github ptpd sources and make them work in RTEMS. 
>> > You have to make some configuration
>> > and sources changes before you can build the with the rsb.
>> >
>> > Some things like the sys/cpuset.h seems not to be fully compatible yet and 
>> > so the configure simply makes
>> > "wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h 
>> > exists.I played a little bit with it and reset
>> > the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could 
>> > reduce the error messages because there is a query for
>> > this variable in the code (src/dep/sys.c):
>> >
>> > in ptpd.h after the include of the created configs :
>> >
>> > ...
>> > #ifdef HAVE_CONFIG_H
>> > # include 
>> > #endif /* HAVE_CONFIG_H */
>> >
>> > #undef HAVE_NTP_GETTIME
>> > #undef HAVE_SYS_CPUSET_H
>> >
>> > #ifdef linux
>> > ...
>> >
>> > in src/dep/sys.c
>> >
>> > ...
>> > #ifdef HAVE_SYS_CPUSET_H
>> >cpuset_t mask;
>> >CPU_ZERO();
>> >if(cpu >= 0) {
>> >CPU_SET(cpu,);
>> >} else {
>> >int i;
>> >for(i = 0;  i < CPU_SETSIZE; i++) {
>> >CPU_SET(i, );
>> >}
>> >}
>> >return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>> >  -1, sizeof(mask), ));
>> > #endif /* HAVE_SYS_CPUSET_H */
>> >
>> > In src/dep/constants_dep.h  one can find:
>> >
>> > * platform dependent */
>> >
>> > #if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) && \
>> > !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) && 
>> > !defined(__QNXNTO__)
>> > #error PTPD hasn't been ported to this OS - should be possible \
>> > if it's POSIX compatible, if you succeed, report it to 
>> > ptpd-de...@sourceforge.net
>> > #endif
>> >
>> > here I added "&& !defined(__rtems__)
>> >
>> > and here:
>> > ...
>> > #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) || 
>> > defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) || 
>> > defined(__rtems__)
>> > # include 
>> > # include 
>> > #ifdef HAVE_SYS_SOCKIO_H
>> > #include 
>> > #endif /* HAVE_SYS_SOCKIO_H */
>> > # include 
>> > # include 
>> > # include 
>> > # include 
>> > #ifdef HAVE_NET_IF_ETHER_H
>> > #  include 
>> > ...
>> >
>> > and so on... You'd have to bite through it once and then you will surely 
>> > get it compiled.
>> >
>> Great start Heinz! Mritunjay, I think this definitely the way forward.
>> Later, you might try to circle back and fix the hacks in nicer ways by
>> learning how to make the autoconf stuff work correctly, and contribute
>> those fixes back upstream to ptpd project.
>>
>> > HTH Heinz
>> >
>> >
>> >
>> > On 2020-06-04 20:29, Mritunjay Sharma wrote:
>> >
>> >
>> >
>> > On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber 
>> >  wrote:
>> >
>> > On 04/06/2020 16:22, Gedare Bloom wrote:
>> >
>> > >>> In the github version this code is conditional on sys/cpuset.h being 
>> > >>> present.
>> > >>>
>> > > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
>> > > definitions though. Probably either:
>> > > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
>> > > would mean adding cpuset_setaffinity support in rtems, I guess.
>> > > 2. Figure out how to disable the conditional code

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-05 Thread Mritunjay Sharma 
Thank you so much Heinz for such a detailed response.
It really helped me a lot.

As advised by you and Heinz, I changed the source to
https://github.com/mritunjaysharma394/ptpd/archive/master.zip
with suggested changes. However, I have encountered few bugs again related
to autoreconf.
It looks somewhat like this:

+ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/mritunjay/development/rtems/5/bin/autoconf
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /home/mritunjay/development/rtems/5/bin/autoconf failed with
exit status: 1
shell cmd failed: /bin/sh -ex
 
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
error: building ptpd-master-arm-rtems5-1

I have attached the error report as well and changes in cfg files can be
found here:
https://github.com/mritunjaysharma394/rtems-source-builder/commit/6b6bb2b3bd778ebe56e9a1bf3aec1747b078fd39

Thanks,
Mritunjay


On Fri, Jun 5, 2020 at 2:53 AM Gedare Bloom  wrote:

> On Thu, Jun 4, 2020 at 1:38 PM junkes  wrote:
> >
> > Hallo Mritunjay,
> >
> > You can't just take the github ptpd sources and make them work in RTEMS.
> You have to make some configuration
> > and sources changes before you can build the with the rsb.
> >
> > Some things like the sys/cpuset.h seems not to be fully compatible yet
> and so the configure simply makes
> > "wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h
> exists.I played a little bit with it and reset
> > the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could
> reduce the error messages because there is a query for
> > this variable in the code (src/dep/sys.c):
> >
> > in ptpd.h after the include of the created configs :
> >
> > ...
> > #ifdef HAVE_CONFIG_H
> > # include 
> > #endif /* HAVE_CONFIG_H */
> >
> > #undef HAVE_NTP_GETTIME
> > #undef HAVE_SYS_CPUSET_H
> >
> > #ifdef linux
> > ...
> >
> > in src/dep/sys.c
> >
> > ...
> > #ifdef HAVE_SYS_CPUSET_H
> >cpuset_t mask;
> >CPU_ZERO();
> >if(cpu >= 0) {
> >CPU_SET(cpu,);
> >} else {
> >int i;
> >for(i = 0;  i < CPU_SETSIZE; i++) {
> >CPU_SET(i, );
> >}
> >}
> >return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
> >  -1, sizeof(mask), ));
> > #endif /* HAVE_SYS_CPUSET_H */
> >
> > In src/dep/constants_dep.h  one can find:
> >
> > * platform dependent */
> >
> > #if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) && \
> > !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) &&
> !defined(__QNXNTO__)
> > #error PTPD hasn't been ported to this OS - should be possible \
> > if it's POSIX compatible, if you succeed, report it to
> ptpd-de...@sourceforge.net
> > #endif
> >
> > here I added "&& !defined(__rtems__)
> >
> > and here:
> > ...
> > #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) ||
> defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) ||
> defined(__rtems__)
> > # include 
> > # include 
> > #ifdef HAVE_SYS_SOCKIO_H
> > #include 
> > #endif /* HAVE_SYS_SOCKIO_H */
> > # include 
> > # include 
> > # include 
> > # include 
> > #ifdef HAVE_NET_IF_ETHER_H
> > #  include 
> > ...
> >
> > and so on... You'd have to bite through it once and then you will surely
> get it compiled.
> >
> Great start Heinz! Mritunjay, I think this definitely the way forward.
> Later, you might try to circle back and fix the hacks in nicer ways by
> learning how to make the autoconf stuff work correctly, and contribute
> those fixes back upstream to ptpd project.
>
> > HTH Heinz
> >
> >
> >
> > On 2020-06-04 20:29, Mritunjay Sharma wrote:
> >
> >
> >
> > On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > On 04/06/2020 16:22, Gedare Bloom wrote:
> >
> > >>> In the github version this code is conditional on sys/cpuset.h being
> present.
> > >>>
> > > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> > > definitions though. Probably either:
> > > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> > > would mean adding cpuset_setaffinity support in rtems, I guess.
> > > 2. Figure out how to disable the conditional code using the
> > > cpuset_setaffinity function.
> > The  is already as compatible as possible to glibc and
> > FreeBSD. There is always room for improvement, however, in this area it
> > will be difficult.
> >
> >
> > Please it would be kind of you all to guide on what is the best thing I
> can do next. It is looking
> > a little

RE: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-05 Thread Jan.Sommer 
Hello,

We came across the PPSi library for PTP support some time ago: 
https://ohwr.org/project/ppsi
In their documentation its says they started with ptpd and then made an 
overhaul of the source code.
They also claim portability as one of their goals. We haven't had time to look 
at it closer yet, but the projects looks a bit more active and seems to have 
the CERN behind it.
Maybe it is worth checking out, if ptpd keeps making trouble.

Cheers,

Jan


> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian
> Huber
> Sent: Friday, June 5, 2020 6:09 AM
> To: Mritunjay Sharma
> Cc: RTEMS Devel
> Subject: Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This
> time building for xilinx_zynq_a9_qemu
> 
> On 04/06/2020 20:29, Mritunjay Sharma wrote:
> 
> >
> >
> > On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber
> >  > <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> >
> > On 04/06/2020 16:22, Gedare Bloom wrote:
> >
> > >>> In the github version this code is conditional on sys/cpuset.h
> > being present.
> > >>>
> > > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> > > definitions though. Probably either:
> > > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> > > would mean adding cpuset_setaffinity support in rtems, I guess.
> > > 2. Figure out how to disable the conditional code using the
> > > cpuset_setaffinity function.
> > The  is already as compatible as possible to glibc and
> > FreeBSD. There is always room for improvement, however, in this
> > area it
> > will be difficult.
> >
> >
> > Please it would be kind of you all to guide on what is the best thing
> > I can do next. It is looking
> > a little difficult. If something similar has been done earlier,
> > sharing it can be a lot helpful to take a cue.
> 
> Configure scripts are sometimes confused that Newlib provides the glibc
> and FreeBSD CPU set APIs. In this case it seems a FreeBSD system was
> detected and it tries to use some proprietary system calls such as
> cpuset_setaffinity(). If you encounter things like this, I would look at
> the man page:
> 
> https://www.freebsd.org/cgi/man.cgi?query=cpuset_setaffinity=0
> =0=FreeBSD+12.1-RELEASE=default=html
> 
> Then you have to evaluate if this stuff makes sense on RTEMS. Is it
> really needed? Otherwise you can disable it via an #ifndef __rtems__ define.
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread Sebastian Huber 

On 04/06/2020 20:29, Mritunjay Sharma wrote:




On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber 
> wrote:


On 04/06/2020 16:22, Gedare Bloom wrote:

>>> In the github version this code is conditional on sys/cpuset.h
being present.
>>>
> Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> definitions though. Probably either:
> 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> would mean adding cpuset_setaffinity support in rtems, I guess.
> 2. Figure out how to disable the conditional code using the
> cpuset_setaffinity function.
The  is already as compatible as possible to glibc and
FreeBSD. There is always room for improvement, however, in this
area it
will be difficult.


Please it would be kind of you all to guide on what is the best thing 
I can do next. It is looking
a little difficult. If something similar has been done earlier, 
sharing it can be a lot helpful to take a cue.


Configure scripts are sometimes confused that Newlib provides the glibc 
and FreeBSD CPU set APIs. In this case it seems a FreeBSD system was 
detected and it tries to use some proprietary system calls such as 
cpuset_setaffinity(). If you encounter things like this, I would look at 
the man page:


https://www.freebsd.org/cgi/man.cgi?query=cpuset_setaffinity=0=0=FreeBSD+12.1-RELEASE=default=html

Then you have to evaluate if this stuff makes sense on RTEMS. Is it 
really needed? Otherwise you can disable it via an #ifndef __rtems__ define.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread Gedare Bloom 
On Thu, Jun 4, 2020 at 1:38 PM junkes  wrote:
>
> Hallo Mritunjay,
>
> You can't just take the github ptpd sources and make them work in RTEMS. You 
> have to make some configuration
> and sources changes before you can build the with the rsb.
>
> Some things like the sys/cpuset.h seems not to be fully compatible yet and so 
> the configure simply makes
> "wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h 
> exists.I played a little bit with it and reset
> the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could reduce 
> the error messages because there is a query for
> this variable in the code (src/dep/sys.c):
>
> in ptpd.h after the include of the created configs :
>
> ...
> #ifdef HAVE_CONFIG_H
> # include 
> #endif /* HAVE_CONFIG_H */
>
> #undef HAVE_NTP_GETTIME
> #undef HAVE_SYS_CPUSET_H
>
> #ifdef linux
> ...
>
> in src/dep/sys.c
>
> ...
> #ifdef HAVE_SYS_CPUSET_H
>cpuset_t mask;
>CPU_ZERO();
>if(cpu >= 0) {
>CPU_SET(cpu,);
>} else {
>int i;
>for(i = 0;  i < CPU_SETSIZE; i++) {
>CPU_SET(i, );
>}
>}
>return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>  -1, sizeof(mask), ));
> #endif /* HAVE_SYS_CPUSET_H */
>
> In src/dep/constants_dep.h  one can find:
>
> * platform dependent */
>
> #if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) && \
> !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) && 
> !defined(__QNXNTO__)
> #error PTPD hasn't been ported to this OS - should be possible \
> if it's POSIX compatible, if you succeed, report it to 
> ptpd-de...@sourceforge.net
> #endif
>
> here I added "&& !defined(__rtems__)
>
> and here:
> ...
> #if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) || 
> defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) || 
> defined(__rtems__)
> # include 
> # include 
> #ifdef HAVE_SYS_SOCKIO_H
> #include 
> #endif /* HAVE_SYS_SOCKIO_H */
> # include 
> # include 
> # include 
> # include 
> #ifdef HAVE_NET_IF_ETHER_H
> #  include 
> ...
>
> and so on... You'd have to bite through it once and then you will surely get 
> it compiled.
>
Great start Heinz! Mritunjay, I think this definitely the way forward.
Later, you might try to circle back and fix the hacks in nicer ways by
learning how to make the autoconf stuff work correctly, and contribute
those fixes back upstream to ptpd project.

> HTH Heinz
>
>
>
> On 2020-06-04 20:29, Mritunjay Sharma wrote:
>
>
>
> On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber 
>  wrote:
>
> On 04/06/2020 16:22, Gedare Bloom wrote:
>
> >>> In the github version this code is conditional on sys/cpuset.h being 
> >>> present.
> >>>
> > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> > definitions though. Probably either:
> > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> > would mean adding cpuset_setaffinity support in rtems, I guess.
> > 2. Figure out how to disable the conditional code using the
> > cpuset_setaffinity function.
> The  is already as compatible as possible to glibc and
> FreeBSD. There is always room for improvement, however, in this area it
> will be difficult.
>
>
> Please it would be kind of you all to guide on what is the best thing I can 
> do next. It is looking
> a little difficult. If something similar has been done earlier, sharing it 
> can be a lot helpful to take a cue.
>
> Mritunjay
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread junkes 
Hallo Mritunjay, 


You can't just take the github ptpd sources and make them work in RTEMS.
You have to make some configuration
and sources changes before you can build the with the rsb. 


Some things like the sys/cpuset.h seems not to be fully compatible yet
and so the configure simply makes
"wrong" decisions. E.g. defines HAVE_SYS_CPUSET_H = 1 as sys/cpuset.h
exists.I played a little bit with it and reset
the definition in ptpd-master/src/ptpd.h  (quick and dirty) and could
reduce the error messages because there is a query for
this variable in the code (src/dep/sys.c): 

in ptpd.h after the include of the created configs : 


...
#ifdef HAVE_CONFIG_H
# include 
#endif /* HAVE_CONFIG_H */ 


#undef HAVE_NTP_GETTIME
#undef HAVE_SYS_CPUSET_H 


#ifdef linux
... 

in src/dep/sys.c  


...
#ifdef HAVE_SYS_CPUSET_H
   
   
  cpuset_t mask;   
   
  
  CPU_ZERO(); 
   
  
  if(cpu >= 0) {   
   
  
  CPU_SET(cpu,);  
   
  
  } else { 
   
  
  int i;   
   
  
  for(i = 0;  i < CPU_SETSIZE; i++) {  
   
  
  CPU_SET(i, );   
   
  
  }
   
  
  }
   
  
  return(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
   
  
-1, sizeof(mask), )); 
   
  
#endif /* HAVE_SYS_CPUSET_H */   

In src/dep/constants_dep.h  one can find: 

* platform dependent */ 


#if !defined(linux) && !defined(__NetBSD__) && !defined(__FreeBSD__) &&
\
!defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun) &&
!defined(__QNXNTO__)
#error PTPD hasn't been ported to this OS - should be possible \
if it's POSIX compatible, if you succeed, report it to
ptpd-de...@sourceforge.net
#endif 

here I added "&& !defined(__rtems__)  


and here:
... 
   

#if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__APPLE__) ||

defined(__OpenBSD__) || defined(__sun) || defined(__QNXNTO__) ||
defined(__rtems__)  
# include  
   
   
# include 
   
   
#ifdef HAVE_SYS_SOCKIO_H
   
   
#include  
   
   
#endif /* HAVE_SYS_SOCKIO_H */  
   
   
# include 
   
   
# include 
   
   
# include

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread Mritunjay Sharma 
On Thu, Jun 4, 2020 at 11:07 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/06/2020 16:22, Gedare Bloom wrote:
>
> >>> In the github version this code is conditional on sys/cpuset.h being
> present.
> >>>
> > Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
> > definitions though. Probably either:
> > 1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
> > would mean adding cpuset_setaffinity support in rtems, I guess.
> > 2. Figure out how to disable the conditional code using the
> > cpuset_setaffinity function.
> The  is already as compatible as possible to glibc and
> FreeBSD. There is always room for improvement, however, in this area it
> will be difficult.
>

Please it would be kind of you all to guide on what is the best thing I can
do next. It is looking
a little difficult. If something similar has been done earlier, sharing it
can be a lot helpful to take a cue.

Mritunjay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread Sebastian Huber 

On 04/06/2020 16:22, Gedare Bloom wrote:


In the github version this code is conditional on sys/cpuset.h being present.


Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
definitions though. Probably either:
1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
would mean adding cpuset_setaffinity support in rtems, I guess.
2. Figure out how to disable the conditional code using the
cpuset_setaffinity function.
The  is already as compatible as possible to glibc and 
FreeBSD. There is always room for improvement, however, in this area it 
will be difficult.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread junkes 

On 2020-06-04 16:22, Gedare Bloom wrote:

On Thu, Jun 4, 2020 at 7:58 AM Mritunjay Sharma
 wrote:




On Thu, Jun 4, 2020 at 10:39 AM Chris Johns  wrote:


On 4/6/20 2:31 pm, Gedare Bloom wrote:
> On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
>  wrote:
>>
>> Hello everyone,
>>
>> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
>> with a little modification in ptp cfg file.
>>
>> The netinet is no longer a problem here but another problem has come as 
follows:
>>
>> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':

Is this from sourceforge?



Earlier I used from debian, today I tried with Sourceforge, but same 
error still :(



How does the ptpd-2.3.1 source code relate to the github repo
https://github.com/ptpd/ptpd ?

I have been referencing the github repo.



Yes, that's the repo that we are working with.

Mritunjay



>> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
undeclared (first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>  ^~~
>> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' undeclared 
(first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>   ^
>
> These are from BSD. This probably needs to be compiled with libbsd
> somehow? or picking up its header files...

In the github version this code is conditional on sys/cpuset.h being 
present.




Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
definitions though. Probably either:
1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
would mean adding cpuset_setaffinity support in rtems, I guess.
2. Figure out how to disable the conditional code using the
cpuset_setaffinity function.



Chris


I changed the reference now to the github.
wget https://github.com/ptpd/ptpd/archive/master.zip

But using autoreconf just every second call works???

h1@earth lall]$ cd ptpd-master/
[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
autoreconf: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf failed with 
exit status: 1

[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:29: installing 'build-aux/compile'
configure.ac:17: installing 'build-aux/install-sh'
configure.ac:17: installing 'build-aux/missing'
src/Makefile.am: installing 'build-aux/depcomp'
autoreconf: Leaving directory `.'
[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
configure.ac:28: error: possibly undefined macro: AC_PROG_LIBTOOL
  If this token and others are legitimate, please use 
m4_pattern_allow.

  See the Autoconf documentation.
autoreconf: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf failed with 
exit status: 1

[h1@earth ptpd-master]$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoconf
autoreconf: running: /home/h1/GSOC/RTEMS/5.0.0-m2003/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
autoreconf: Leaving directory `.'
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread Gedare Bloom 
On Thu, Jun 4, 2020 at 7:58 AM Mritunjay Sharma
 wrote:
>
>
>
> On Thu, Jun 4, 2020 at 10:39 AM Chris Johns  wrote:
>>
>> On 4/6/20 2:31 pm, Gedare Bloom wrote:
>> > On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
>> >  wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
>> >> with a little modification in ptp cfg file.
>> >>
>> >> The netinet is no longer a problem here but another problem has come as 
>> >> follows:
>> >>
>> >> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':
>>
>> Is this from sourceforge?
>
>
> Earlier I used from debian, today I tried with Sourceforge, but same error 
> still :(
>>
>>
>> How does the ptpd-2.3.1 source code relate to the github repo
>> https://github.com/ptpd/ptpd ?
>>
>> I have been referencing the github repo.
>
>
> Yes, that's the repo that we are working with.
>
> Mritunjay
>>
>>
>> >> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
>> >> undeclared (first use in this function)
>> >>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>> >>  ^~~
>> >> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' 
>> >> undeclared (first use in this function)
>> >>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>> >>   ^
>> >
>> > These are from BSD. This probably needs to be compiled with libbsd
>> > somehow? or picking up its header files...
>>
>> In the github version this code is conditional on sys/cpuset.h being present.
>>

Well, we do have a sys/cpuset.h in newlib. It doesn't have these BSD
definitions though. Probably either:
1. Add more stuff to sys/cpuset.h to make it support BSDisms. This
would mean adding cpuset_setaffinity support in rtems, I guess.
2. Figure out how to disable the conditional code using the
cpuset_setaffinity function.

>>
>> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-04 Thread Mritunjay Sharma 
On Thu, Jun 4, 2020 at 10:39 AM Chris Johns  wrote:

> On 4/6/20 2:31 pm, Gedare Bloom wrote:
> > On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
> >  wrote:
> >>
> >> Hello everyone,
> >>
> >> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
> >> with a little modification in ptp cfg file.
> >>
> >> The netinet is no longer a problem here but another problem has come as
> follows:
> >>
> >> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':
>
> Is this from sourceforge?
>

Earlier I used from debian, today I tried with Sourceforge, but same error
still :(

>
> How does the ptpd-2.3.1 source code relate to the github repo
> https://github.com/ptpd/ptpd ?
>
> I have been referencing the github repo.
>

Yes, that's the repo that we are working with.

Mritunjay

>
> >> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH'
> undeclared (first use in this function)
> >>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
> >>  ^~~
> >> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID'
> undeclared (first use in this function)
> >>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
> >>   ^
> >
> > These are from BSD. This probably needs to be compiled with libbsd
> > somehow? or picking up its header files...
>
> In the github version this code is conditional on sys/cpuset.h being
> present.


> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-03 Thread Chris Johns 
On 4/6/20 2:31 pm, Gedare Bloom wrote:
> On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
>  wrote:
>>
>> Hello everyone,
>>
>> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
>> with a little modification in ptp cfg file.
>>
>> The netinet is no longer a problem here but another problem has come as 
>> follows:
>>
>> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':

Is this from sourceforge?

How does the ptpd-2.3.1 source code relate to the github repo
https://github.com/ptpd/ptpd ?

I have been referencing the github repo.

>> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
>> undeclared (first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>  ^~~
>> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' undeclared 
>> (first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>   ^
> 
> These are from BSD. This probably needs to be compiled with libbsd
> somehow? or picking up its header files...

In the github version this code is conditional on sys/cpuset.h being present.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-03 Thread Gedare Bloom 
On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
 wrote:
>
> Hello everyone,
>
> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
> with a little modification in ptp cfg file.
>
> The netinet is no longer a problem here but another problem has come as 
> follows:
>
> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':
> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
> undeclared (first use in this function)
>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>  ^~~
> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' undeclared 
> (first use in this function)
>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>   ^

These are from BSD. This probably needs to be compiled with libbsd
somehow? or picking up its header files...

> Makefile:629: recipe for target 'dep/startup.o' failed
> make[2]: Leaving directory 
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc/src'
> make[2]: *** [dep/startup.o] Error 1
> Makefile:502: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory 
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc'
> Makefile:412: recipe for target 'all' failed
> make: *** [all] Error 2
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/do-build
> error: building ptpd-2.3.1-arm-rtems5-1
>   See error report: rsb-report-ptpd-2.3.1-arm-rtems5-1.txt
> Build Set: Time 0:00:21.081476
>
> I am also attaching the log file and trace report.
>
> Thanks,
> Mritunjay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-03 Thread Mritunjay Sharma 
Hello everyone,

As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
with a little modification in ptp cfg file.

The netinet is no longer a problem here but another problem has come as
follows:

../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':
../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH'
undeclared (first use in this function)
   if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
 ^~~
../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID'
undeclared (first use in this function)
   if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
  ^
Makefile:629: recipe for target 'dep/startup.o' failed
make[2]: Leaving directory
'/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc/src'
make[2]: *** [dep/startup.o] Error 1
Makefile:502: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc'
Makefile:412: recipe for target 'all' failed
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex
 
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/do-build
error: building ptpd-2.3.1-arm-rtems5-1
  See error report: rsb-report-ptpd-2.3.1-arm-rtems5-1.txt
Build Set: Time 0:00:21.081476

I am also attaching the log file and trace report.

Thanks,
Mritunjay
RTEMS Tools Project - Source Builder Error Report
 Build: error: building ptpd-2.3.1-arm-rtems5-1
 Command Line: ../source-builder/sb-set-builder --log=log 
--prefix=/home/mritunjay/development/rtems/5 
--with-tools=/home/mritunjay/development/rtems/5 --host=arm-rtems5 
--with-rtems-bsp=xilinx_zynq_a9_qemu net/ptpd
 Python: 2.7.17 (default, Apr 15 2020, 17:20:14) [GCC 7.5.0]
 
git://git.rtems.org/rtems-source-builder.git/origin/855818015a378a8333754625296f3b15ce52aadd-modified
 Linux mritunjay-XPS-15-9570 5.3.0-51-generic #44~18.04.2-Ubuntu SMP Thu Apr 23 
14:27:18 UTC 2020 x86_64
Tail of the build log:
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gawk... (cached) mawk
checking for arm-rtems5-gcc... arm-rtems5-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-rtems5-gcc accepts -g... yes
checking for arm-rtems5-gcc option to accept ISO C89... none needed
checking whether arm-rtems5-gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of arm-rtems5-gcc... gcc3
checking for arm-rtems5-gcc option to accept ISO C99... none needed
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-unknown-rtems5
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by arm-rtems5-gcc... 
/home/mritunjay/development/rtems/5/arm-rtems5/bin/ld
checking if the linker (/home/mritunjay/development/rtems/5/arm-rtems5/bin/ld) 
is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... 
/home/mritunjay/development/rtems/5/bin/arm-rtems5-nm -B
checking the name lister (/home/mritunjay/development/rtems/5/bin/arm-rtems5-nm 
-B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to 
arm-unknown-rtems5 format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain 
format... func_convert_file_noop
checking for /home/mritunjay/development/rtems/5/arm-rtems5/bin/ld option to 
reload object files... -r
checking for arm-rtems5-objdump... arm-rtems5-objdump
checking how to recognize dependent libraries... unknown
checking for arm-rtems5-dlltool... no
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for arm-rtems5-ar... arm-rtems5-ar
checking for archiver @FILE support... @
checking for arm-rtems5-strip... (cached) arm-rtems5-strip
checking for arm-rtems5-ranlib... arm-rtems5-ranlib
checking command to parse /home/mritunjay/development/rtems/5/bin/arm-rtems5-nm 
-B output from arm-rtems5-gcc object... failed
checking for sysroot... no
checking for arm-rtems5-mt... no
checking for mt... mt