This fixes the following build error for --host=x86_64-w64-mingw32:
rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
rtemstoolkit/libiberty/pex-win32.c:643: undefined reference to `writeargv'
Update #4969.
---
rtemstoolkit/libiberty/argv.c | 568
This makes the build reproducible.
---
spec/build/bsps/opto0.yml | 1 +
spec/build/bsps/opto1.yml | 1 +
spec/build/bsps/opto2.yml | 1 +
spec/build/bsps/optog.yml | 1 +
spec/build/bsps/optos.yml | 1 +
5 files changed, 5 insertions(+)
diff --git a/spec/build/bsps/opto0.yml b/spec/build/bsps/opt
Update #4272.
---
wscript | 12
1 file changed, 12 insertions(+)
diff --git a/wscript b/wscript
index 6c81083b2c..e43ae8ba3e 100755
--- a/wscript
+++ b/wscript
@@ -976,6 +976,17 @@ class OptionItem(Item):
def _find_program(self, conf, cic, value, arg):
return conf.find_
Update #4272.
---
spec/build/bsps/arm/xilinx-zynq/grp.yml | 6
spec/build/bsps/arm/xilinx-zynq/mkimage.yml | 39 +
2 files changed, 45 insertions(+)
create mode 100644 spec/build/bsps/arm/xilinx-zynq/mkimage.yml
diff --git a/spec/build/bsps/arm/xilinx-zynq/grp.yml
Add a new build item type to provide optional BSP-specific tools to make
bootloader images. The tools are installed as Python scripts in:
${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
Application build systems can query the tool using the RTEMS_MKIMAGE package
configuration varible, for e
Sebastian Huber (6):
build: Fix script action
build: Add "find-optional-program" action
build: Make OBJCOPY optional
build: Add support to make bootloader images
build: Add mkimage support for powerpc/qoriq
build: Add mkimage support for arm/xilinx-zynq
spec/build/bsps/arm/xilinx-zynq
We have to use a custom dictorary to be able to set the "value" argument
in the exec() context.
Update #4272.
---
wscript | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/wscript b/wscript
index a71e0d3f10..6c81083b2c 100755
--- a/wscript
+++ b/wscript
@@ -1026,8 +10
Update #4272.
---
spec/build/bsps/i386/pc386/objsmpstart.yml | 4 +++-
spec/build/bsps/optobjcopy.yml | 14 +-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/spec/build/bsps/i386/pc386/objsmpstart.yml
b/spec/build/bsps/i386/pc386/objsmpstart.yml
index a08
Update #4272.
---
spec/build/bsps/optpython.yml | 14
spec/build/bsps/optubootmkimage.yml | 20
spec/build/bsps/powerpc/qoriq/grp.yml | 6
spec/build/bsps/powerpc/qoriq/mkimage.yml | 39 +++
4 files changed, 79 insertions(+)
cr
Prefer macros with a proper namespace.
---
cpukit/score/cpu/powerpc/include/rtems/asm.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/cpukit/score/cpu/powerpc/include/rtems/asm.h
b/cpukit/score/cpu/powerpc/include/rtems/asm.h
index 27af64e724..94f54245b4 100644
--
Hello Sebastian,
On 2/27/24 16:15, Sebastian Huber wrote:
Add a new build item type to provide optional BSP-specific tools to make
bootloader images. The tools are installed as Python scripts in:
${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
Application build systems can query the too
I'm a little confused by this patch set. I think I saw Frank makes a
similar kind of comment. Basically, I don't understand why we generate
these tools with the RTEMS build system, inside of rtems.git, rather
than inside of rtems-tools.
On Tue, Feb 27, 2024 at 8:15 AM Sebastian Huber
wrote:
>
> S
On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa wrote:
>
> Dear RTEMS community, the core developers team,
>
> Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under my
> supervision. The project has reached a phase where we will be very grateful
> for the review and pointing to requir
joel said:
+#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> defined(CONFIGURE_TICKS_PER_TIMESLICE)
> + #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +#endif
> +
>
>
> This is modifying the right file but I think it is safer to check that
> it is defined
> befor
On 24/2/2024 7:04 am, Joel Sherrill wrote:
=> rtems 6.1rc2 has a lot of tool build failures because I didn't have gmp-devel
> installed.
>
> hecking for gmp.h... no
> configure: error: gmp.h header not found
>
> This is reported as part of building gcc-newlib. Should the RSB account for
> this
>
OK
Thanks
Chris
On 28/2/2024 2:20 am, Sebastian Huber wrote:
> Prefer macros with a proper namespace.
> ---
> cpukit/score/cpu/powerpc/include/rtems/asm.h | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/score/cpu/powerpc/include/rtems/asm.h
> b/cpukit
Hi,
The manual says:
The string can either be a number (decimal, octal or hex) or
an arbitrary string (in which case it’s converted to a number by
computing CRC32).
The string should be different for every file you compile.
I take this to mean the option `-frandom-seed=0` uses `0` as a
On 28/2/2024 2:15 am, Sebastian Huber wrote:
> We have to use a custom dictorary to be able to set the "value" argument
Spelling. :)
Chris
> in the exec() context.
>
> Update #4272.
> ---
> wscript | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/wscript b/w
Hi,
Is this to allow BSP ready output to be created from the build system?
If it is will the details be exported in the pkgconfig file and made available
for users building applications in a consistent and easy to use way?
Is this output created along side the ELF file?
Does this approach handl
OK and thanks
Chris
On 27/2/2024 9:56 pm, Sebastian Huber wrote:
> This fixes the following build error for --host=x86_64-w64-mingw32:
>
> rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
> rtemstoolkit/libiberty/pex-win32.c:643: undefined reference to `writeargv'
>
> Upda
OK and thanks
Chris
On 27/2/2024 9:56 pm, Sebastian Huber wrote:
> This fixes the following build error for --host=x86_64-w64-mingw32:
>
> rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
> rtemstoolkit/libiberty/pex-win32.c:643: undefined reference to `writeargv'
>
> Upda
The patch close #4974.
On 2024/2/28 15:11, Chris Johns wrote:
OK and thanks
Chris
On 27/2/2024 9:56 pm, Sebastian Huber wrote:
This fixes the following build error for --host=x86_64-w64-mingw32:
rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
rtemstoolkit/libiberty/pe
On 28.02.24 06:34, Chris Johns wrote:
The manual says:
The string can either be a number (decimal, octal or hex) or
an arbitrary string (in which case it’s converted to a number by
computing CRC32).
The string should be different for every file you compile.
I take this to mean the
On 28.02.24 06:36, Chris Johns wrote:
Why do we need this? The tool objcopy is always built when the tools are built?
I am not sure if objcopy is provided by clang and under which name.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.
On 27.02.24 21:39, Gedare Bloom wrote:
I'm a little confused by this patch set. I think I saw Frank makes a
similar kind of comment. Basically, I don't understand why we generate
these tools with the RTEMS build system, inside of rtems.git, rather
than inside of rtems-tools.
The BSP build knows
On 28.02.24 06:48, Chris Johns wrote:
Hi,
Is this to allow BSP ready output to be created from the build system?
Yes, this is the goal.
If it is will the details be exported in the pkgconfig file and made available
for users building applications in a consistent and easy to use way?
Appli
26 matches
Mail list logo