[PATCH] build: Add PROGRAM_PREFIX option

Wed Aug 9 08:51:21 UTC 2023

On 09.08.23 03:26, Chris Johns wrote:
> On 8/8/2023 11:14 pm, Sebastian Huber wrote:
>> On 08.08.23 08:06, Chris Johns wrote:
>>> n 7/8/2023 4:06 pm, Sebastian Huber wrote:
>>>> On 07.08.23 00:25, Chris Johns wrote:
>>>>> On 4/8/2023 4:39 pm, Sebastian Huber wrote:
>>>>>> On 04.08.23 08:22, Chris Johns wrote:
>>>>>>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>>>>>>> On 04.08.23 00:27, Chris Johns wrote:
>>>>>>>>> On 2/8/2023 6:49 pm, Chris Johns wrote:
>>>>>>>>>       > I am concerned about the compatibility to the ecosystem we have.
>>>>>>>>> Have you
>>>>>>>>> built
>>>>>>>>>> all the tests in the testsuite with this value set to something that is
>>>>>>>>>> not
>>>>>>>>>> RTEMS default? I think a few things will break because of hard coding in
>>>>>>>>>> them.
>>>>>>>>> I have asked for test results and I have not seen any yet the patch has
>>>>>>>>> been
>>>>>>>>> merged? The change was not approved my me and is still not approved.
>>>>>>>> Sorry I thought it was fine after answering your questions.
>>>>>>> All good, I would like to finish the discusion. 🙂
>>>>>>>
>>>>>>>> Yes, I have tested this with the rtems7 tools. It was possible to build with
>>>>>>>> the rtems7 tools
>>>>>>>> before, however, the PROGRAM_PREFIX approach is better, since it allows
>>>>>>>> also the
>>>>>>>> build using vendor tools. We had some fixes for this recently:
>>>>>>>>
>>>>>>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>>>>>>
>>>>>>>> This is something the user need.
>>>>>>> What if a user adds or uses a prefix that does not conform to the standard
>>>>>>> format? I am assuming this is possible to do this, eg Gaisler's special
>>>>>>> prefix?
>>>>>>>
>>>>>>> Possible breakage is
>>>>>>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457   ?
>>>>>>>
>>>>>>> Do we need to document any constraints around this option?
>>>>>> There will be always problems left to fix.
>>>>> I do not see this as a problem, I see an incomplete change pushed without the
>>>>> review being completed.
>>>> Sometimes it is not 100% clear when a review is finished.
>>> Yes it is all a bit fragile and there is lots of guess work.
>>>
>>>>>> A basic build and the normal tests
>>>>>> work fine with non-standard tools. For the Gaisler tools, you would need:
>>>>>>
>>>>>> PROGRAM_PREFIX = sparc-gaisler-rtems5-
>>>>>>
>>>>>> I guess the rld-cc.cpp will also have issues with a clang build.
>>>>> Yes it would and libdl is a part of RTEMS and breaking it again is something I
>>>>> would like to avoid. I consider the change incomplete because one part says use
>>>>> PROGRAM_PREFIX to change the tools prefix however doing so may break other
>>>>> parts. There is nothing to warn the user PROGRAM_PREFIX may not work as
>>>>> expected.
>>>> I don't use vendor tool chains, but it seems that some users would like to use
>>>> them. They were supported by the old build system, so a lacking support in the
>>>> new build system would be a regression. But if you don't like this change, then
>>>> we can also revert the patch.
>>> I think the change is fine and I am not suggesting it is reverted. It is not
>>> clear to me if more work is needed to complete what this has started because I
>>> do not know where we stand with vendor tools.
>>>
>>> I think supporting vendor tools is something we should consider and either
>>> accept it and sort out what is needed or we clearly state vendors are on their
>>> own.
>>>
>>> Supporting vendor tools add something else we need to test and handle but it
>>> lets vendors own the tools they create and it is clear to us when a user raises
>>> a problem when using them.
>>
>> The vendor tools support works now as good or bad as in RTEMS 5. If someone
>> wants better support, then he/she should work on it. We can't make everything
>> perfect, there are other things left to do for the RTEMS 6 release.
> 
> Should we document the extent of what we do support and what is missing?

We could add some text to the option description:

# Defines the program prefix of tools (compiler, assembler, linker).
# This option may be used to build RTEMS with a vendor tool suite.
# Please note that using tool suites not provided by the RTEMS Project
# may not work as expected.
PROGRAM_PREFIX = ${ARCH}-rtems${__RTEMS_MAJOR__}-

> 
> And yes I agree with your comments however users are often not aware of this and
> we end up fielding support related questions. I also do not think we need to do
> much to make it work but I am not sure. How do you build gcc with a different
> tools prefix?

The Gaisler tools were configured like this:

Configured with: 
/scratch/jenkins/workspace/RCC_master-KM5WEZV2QBPWA3KWTLID2LONMQ6KHXQSKK2LENARD3XKNAOB5V6Q/toolchain/gcc/configure 
--target=sparc-gaisler-rtems5 --host= --disable-shared --with-newlib 
--enable-threads --enable-languages=c,c++ --disable-nls --disable-plugin 
--enable-lto --enable-libgomp --prefix=/opt/rcc-1.3.1-gcc 
--with-cpu=leon3 --enable-version-specific-runtime-libs --disable-libcc1 
--disable-libstdcxx-pch --disable-win32-registry --disable-decimal-float 
--disable-install-libiberty --disable-fixed-point --with-gnu-as 
--with-sysroot=/opt/rcc-1.3.1-gcc/sparc-gaisler-rtems5 
--without-included-gettext --enable-newlib-io-c99-formats 
--enable-newlib-iconv 
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 
--with-debug-prefix-map='/scratch/jenkins/workspace/RCC_master-KM5WEZV2QBPWA3KWTLID2LONMQ6KHXQSKK2LENARD3XKNAOB5V6Q/toolchain/build-gcc-linux64/gcc=/opt/rcc-1.3.1-gcc/src/misc 
/scratch/jenkins/workspace/RCC_master-KM5WEZV2QBPWA3KWTLID2LONMQ6KHXQSKK2LENARD3XKNAOB5V6Q/toolchain/gcc=/opt/rcc-1.3.1-gcc/src/gcc 
/scratch/jenkins/workspace/RCC_master-KM5WEZV2QBPWA3KWTLID2LONMQ6KHXQSKK2LENARD3XKNAOB5V6Q/toolchain/newlib=/opt/rcc-1.3.1-gcc/src/newlib' 
--with-pkgversion='Cobham Gaisler RCC 1.3.1'

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/