Waf + gccdeps on Mingw64/MSYS2?
Chris Johns
chrisj at rtems.org
Mon Dec 2 21:55:48 UTC 2019
On 2/12/19 5:27 pm, Sebastian Huber wrote:
> On 02/12/2019 01:24, Chris Johns wrote:
>> On 2/12/19 11:10 am, Chris Johns wrote:
>>> On 28/11/19 5:55 pm, Sebastian Huber wrote:
>>>> Hello,
>>>>
>>>> I encountered this error on a Mingw64 and MSYS2 system:
>>>>
>>>> Waf: Leaving directory `/c/rtems/home/rtems-5/build/powerpc/qoriq_e6500_32'
>>>> Build failed
>>>> Traceback (most recent call last):
>>>> File
>>>> "/c/rtems/home/rtems-5/.waf3-2.0.18-96675f149f50dab16c9e2e6aaf5e787b/waflib/Task.py",
>>>>
>>>> line 190, in process
>>>> self.post_run()
>>>> File "/c/rtems/home/rtems-5/gccdeps.py", line 144, in post_run
>>>> raise ValueError('could not find %r for %r' % (x, self))
>>>> ValueError: could not find
>>>> 'c:\\rtems\\home\\rtems-5\\bsps\\shared\\dev\\clock\\clockimpl.h' for
>>>> {task 7696547476648: c clock-config.c -> clock-config.c.13.o}
>>>
>>> Tried to build sparc/erc32 on Windows MSYS2 using the eng.pdf quick start guide
>>> and the build locked up with ...
>>>
>>> [1706/4038] Compiling build/sparc/erc32/testsuites/libtests/dl06/dl06-pre.exe
>>> [1707/4038] Compiling build/sparc/erc32/testsuites/libtests/dl07/dl07-pre.exe
>>> [1708/4038] Compiling build/sparc/erc32/testsuites/libtests/dl08/dl08-pre.exe
>>> [1709/4038] Compiling build/sparc/erc32/testsuites/libtests/dl09/dl09-pre.exe
>>> [1710/4038] Compiling build/sparc/erc32/testsuites/libtests/dl10/dl10-pre.exe
>>> Unhandled exception in thread started by <bound method Thread._bootstrap of
>>> <Consumer(Thread-1712, started daemon 25777509536)>>
>>> Traceback (most recent call last):
>>> File "/usr/lib/python3.7/threading.py", line 522, in set
>>> self._cond.notify_all()
>>> File "/usr/lib/python3.7/threading.py", line 365, in notify_all
>>> self.notify(len(self._waiters))
>>> File "/usr/lib/python3.7/threading.py", line 346, in notify
>>> raise RuntimeError("cannot notify on un-acquired lock")
>>> RuntimeError: cannot notify on un-acquired lock
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> Traceback (most recent call last):
>>> File "/usr/lib/python3.7/threading.py", line 890, in _bootstrap
>>> self._bootstrap_inner()
>>> File "/usr/lib/python3.7/threading.py", line 915, in _bootstrap_inner
>>> self._started.set()
>>> File "/usr/lib/python3.7/threading.py", line 522, in set
>>> self._cond.notify_all()
>>> File "/usr/lib/python3.7/threading.py", line 244, in __exit__
>>> return self._lock.__exit__(*args)
>>> RuntimeError: release unlocked lock
>>>
>>
>> I updated MSYS2 to the latest and this error did not appear however I am now
>> seeing ...
>>
>> [1867/4038] Processing testsuites/libtests/tar01/init.o:
>> testsuites/libtests/tar01/init.c
>> build/sparc/erc32/testsuites/libtests/tar01/tar01-tar.h
>> build/sparc/erc32/testsuites/libtests/tar01/tar01-tar-gz.h
>> build/sparc/erc32/testsuites/libtests/tar01/tar01-tar-xz.h ->
>> build/sparc/erc32/testsuites/libtests/tar01/init.o
>> In file included from
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:26:0:
>> testsuites/libtests/tar01/tar01-tar.h:7:12: warning: extra tokens at end of
>> #ifndef directive
>> #ifndef
>> __D:_opt_rtems_rtems_seb_build_sparc_erc32_testsuites_libtests_tar01_tar01_tar_h
>> ^
>> testsuites/libtests/tar01/tar01-tar.h:8:12: warning: ISO C99 requires whitespace
>> after the macro name
>> #define
>> __D:_opt_rtems_rtems_seb_build_sparc_erc32_testsuites_libtests_tar01_tar01_tar_h
>> ^
>> In file included from
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:27:0:
>> testsuites/libtests/tar01/tar01-tar-gz.h:7:12: warning: extra tokens at end of
>> #ifndef directive
>> #ifndef
>> __D:_opt_rtems_rtems_seb_build_sparc_erc32_testsuites_libtests_tar01_tar01_tar_gz_h
>>
>> ^
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c: In function
>> 'test_untar_unzip_tgz':
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:44:26: error:
>> 'tar01_tar_gz' undeclared (first use in this function); did you mean
>> 'tar01_tar_size'?
>> #define TARFILE_GZ_START tar01_tar_gz
>> ^
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:198:26: note: in
>> expansion of macro 'TARFILE_GZ_START'
>> char *buffer = (char *)TARFILE_GZ_START;
>> ^~~~~~~~~~~~~~~~
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:44:26: note: each
>> undeclared identifier is reported only once for each function it appears in
>> #define TARFILE_GZ_START tar01_tar_gz
>> ^
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:198:26: note: in
>> expansion of macro 'TARFILE_GZ_START'
>> char *buffer = (char *)TARFILE_GZ_START;
>> ^~~~~~~~~~~~~~~~
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:45:26: error:
>> 'tar01_tar_gz_size' undeclared (first use in this function); did you mean
>> 'tar01_tar_size'?
>> #define TARFILE_GZ_SIZE tar01_tar_gz_size
>> ^
>> D:/opt/rtems/rtems.seb/testsuites/libtests/tar01/init.c:199:19: note: in
>> expansion of macro 'TARFILE_GZ_SIZE'
>> size_t buflen = TARFILE_GZ_SIZE;
>> ^~~~~~~~~~~~~~~
>
> I think this revealed two issues.
>
> 1. The file name sanitation in bin2c was not really good. I fixed it like this:
>
> https://git.rtems.org/rtems-tools/commit/?id=83b8f1f2a5838a5d56e15c70d44348e3e393e3f7
>
>
> 2. The custom commands use a lot of node.abspath(). I have this pattern from the
> Waf book. However, the standard .c file to .o rule uses a mix of relative and
> absolute paths, e.g.:
>
> '../../../testsuites/samples/ticker/init.c'
>
> '-o/build/git-rtems-5/build/arm/xilinx_zynq_a9_qemu/testsuites/samples/ticker/init.c.87.o'
>
>
> Do you have a preference?
I think absolute paths are good to use if the path ends up in an object file's
DWARF data, ie source, include paths etc. This is something that bugs me with
newlib, it is built with relative paths. On the other hand relative paths avoid
any path depth issues, for example this can happen on Windows if the paths are
not forced into a unicode format and u'\\\\?' is prepended.
Chris
More information about the devel
mailing list