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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
