On 25/4/2023 12:20 am, Sebastian Huber wrote:
> On 24.04.23 16:17, Kinsey Moore wrote:
>> I think we've been moving away from in-file comments in the YAML and toward
>> actual labels in the data, anyway. If it's important information, it should
>> be
>> kept properly.
>
> Yes, there should be no
Looks good and thanks for sorting this out.
Chris
On 24/4/2023 11:00 pm, Sebastian Huber wrote:
> There was a cyclic dependency: For RTEMS_STATIC_ANALYSIS we needed
> basedefs.h in assert.h. For RTEMS_UNREACHABLE() we needed _Assert() from
> assert.h in basedefs.h.
>
> Fix this by introducing
On 25/4/2023 7:05 am, Joel Sherrill wrote:
>
>
> On Mon, Apr 24, 2023 at 3:11 PM Karel Gardas wrote:
>
> On 4/24/23 21:33, Joel Sherrill wrote:
> >
> >
> > On Mon, Apr 24, 2023, 2:11 PM Karel Gardas
> wrote:
> >
> >
> > What have you done to this poor FBSD?
On Mon, Apr 24, 2023 at 3:11 PM Karel Gardas
wrote:
> On 4/24/23 21:33, Joel Sherrill wrote:
> >
> >
> > On Mon, Apr 24, 2023, 2:11 PM Karel Gardas
> wrote:
> >
> >
> > What have you done to this poor FBSD? ;-)
>
Nothing. :)
I wonder when we started installing dynamic libraries with qemu.
On 4/24/23 21:33, Joel Sherrill wrote:
On Mon, Apr 24, 2023, 2:11 PM Karel Gardas wrote:
What have you done to this poor FBSD? ;-)
Anyway, I've just pkg update; pkg upgrade and result is:
karel@rtems:/usr/local/lib $ ls -la libglib-2.0.*
-rw-r--r-- 1 root wheel 2434866
On Mon, Apr 24, 2023, 2:11 PM Karel Gardas wrote:
>
> What have you done to this poor FBSD? ;-)
>
> Anyway, I've just pkg update; pkg upgrade and result is:
>
> karel@rtems:/usr/local/lib $ ls -la libglib-2.0.*
> -rw-r--r-- 1 root wheel 2434866 Apr 2 03:18 libglib-2.0.a
> lrwxr-xr-x 1 root
What have you done to this poor FBSD? ;-)
Anyway, I've just pkg update; pkg upgrade and result is:
karel@rtems:/usr/local/lib $ ls -la libglib-2.0.*
-rw-r--r-- 1 root wheel 2434866 Apr 2 03:18 libglib-2.0.a
lrwxr-xr-x 1 root wheel 16 Apr 2 03:19 libglib-2.0.so ->
Hi
It looks like something has broken recently with building qemu via the RSB
and dynamic libraries. All invocations of qemu are failing
https://lists.rtems.org/pipermail/build/2023-April/044792.html
Not sure what to do. Maybe LD_LIBRARY_PATH but that wasn't needed before
--joel
On 24.04.23 16:17, Kinsey Moore wrote:
I think we've been moving away from in-file comments in the YAML and
toward actual labels in the data, anyway. If it's important information,
it should be kept properly.
Yes, there should be no comments in the build specification files. They
would be
I think we've been moving away from in-file comments in the YAML and toward
actual labels in the data, anyway. If it's important information, it should
be kept properly.
Kinsey
On Mon, Apr 24, 2023 at 8:55 AM Sam Price wrote:
> Yaml files can have comments, json files can’t. So you would lose
Yaml files can have comments, json files can’t. So you would lose some
documentation…
--
Sincerely,
Sam Price
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
There was a cyclic dependency: For RTEMS_STATIC_ANALYSIS we needed
basedefs.h in assert.h. For RTEMS_UNREACHABLE() we needed _Assert() from
assert.h in basedefs.h.
Fix this by introducing _Debug_Unreachable() in basedefs.h.
Add RTEMS_FUNCTION_NAME to basedefs.h and use it in basedefs.h and
Hello Andrew,
On 24.04.23 11:56, Andrew Butterfield wrote:
would this also affect the specification item YAML files in RTEMS Central?
no, I already added support to load specification items from JSON files.
JSON files are a bit harder to write manually than YAML files. For the
build items
Hi Sebastian,
would this also affect the specification item YAML files in RTEMS Central?
I have no strong opinions about this either way.
Regards,
Andrew
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Hello,
I would like to change the build specification files from YAML to JSON
to get rid of the complicated caching mechanism. Python has a built in
JSON loader which is quite fast compared to the YAML loader. For the
configure/build steps we have to load all items currently due to the
item
On 24/4/2023 7:14 pm, Sebastian Huber wrote:
> Looks good, thanks.
Thanks for the review, pushed. Sorry about forgetting to post the fix.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Looks good, thanks.
--
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
From: Chris Johns
---
bsps/powerpc/gen83xx/start/bsprestart.c | 2 +-
bsps/powerpc/gen83xx/start/cpuinit.c | 2 +-
bsps/powerpc/mpc55xxevb/start/bspstart.c | 2 +-
bsps/powerpc/mpc55xxevb/start/flash_support.c | 10 +-
bsps/powerpc/qoriq/irq/irq.c
On 24/4/2023 6:42 pm, Sebastian Huber wrote:
> On 12.04.23 03:56, chr...@rtems.org wrote:
>> From: Chris Johns
>>
>> - This change avoids the GCC extension of blocks in expressions that
>> ISO forbids and is warned about with the pedantic warnings option.
>
> This change is an API change and
On 12.04.23 03:56, chr...@rtems.org wrote:
From: Chris Johns
- This change avoids the GCC extension of blocks in expressions that
ISO forbids and is warned about with the pedantic warnings option.
This change is an API change and broke the build of some BSPs and maybe
also applications.
20 matches
Mail list logo
