LLVM on openSUSE 15.1

[Sebastian Huber]

On 18/09/2019 10:29, Chris Johns wrote:
> On 18/9/19 4:09 pm, Sebastian Huber wrote:
>> On 18/09/2019 07:40, Chris Johns wrote:
>>> On 18/9/19 3:36 pm, Sebastian Huber wrote:
>>>> On 17/09/2019 08:07, Sebastian Huber wrote:
>>>>>
>>>>>
>>>>> On 17/09/2019 08:07, Chris Johns wrote:
>>>>>> On 17/9/19 3:32 pm, Sebastian Huber wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I didn't get far:
>>>>>>>
>>>>>>> config.status: creating t/wrap/automake-1.12
>>>>>>> + make -j 12 all
>>>>>>>      GEN      automake
>>>>>>>      GEN      aclocal
>>>>>>>      GEN      t/ax/shell-no-trail-bslash
>>>>>>>      GEN      doc/aclocal.1
>>>>>>>      GEN      doc/automake.1
>>>>>>>      GEN      runtest
>>>>>>>      GEN      t/ax/test-defs.sh
>>>>>>>      GEN      lib/Automake/Config.pm
>>>>>>>      GEN      doc/aclocal-1.12.1
>>>>>>>      GEN      doc/automake-1.12.1
>>>>>>> help2man: can't get `--help' info from automake-1.12
>>>>>>> Try `--no-discard-stderr' if option outputs to stderr
>>>>>>> make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
>>>>>> That is weird because this is what we build for gcc as we need autoconf to
>>>>>> boot
>>>>>> strap RTEMS.
>>>>>
>>>>> This is indeed quite weird, I never had problems building automake before. I
>>>>> will try to figure out what went wrong here.
>>>>
>>>> We have configuration files for Automake 1.12.6. I fixed it like this:
>>>>
>>>> https://git.rtems.org/rtems-source-builder/commit/?id=bf7b4ad68f0faa9a35e52ca1baafb6f72c0fb673
>>>>
>>
>> This change breaks the build of the RTEMS toolchain on FreeBSD 12.
>>
> 
> I do not understand ...
> https://lists.rtems.org/pipermail/build/2019-September/003517.html ?

Building the unstable RTEMS 6 toolchain results in an endless build of 
automake with this patch on FreeBSD 12.

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.