Giters

rsta2 / circle

A C++ bare metal environment for Raspberry Pi with USB (32 and 64 bit)

Home Page:https://circle-rpi.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"Bring your own" STDLIB

toptensoftware opened this issue · comments

commented

I'm trying to resolve some conflicts between circle and my own minimal ANSI-C runtime library. The problem is my library's unit tests that normally pass are failing because it's linking circle's versions of some of these functions which behave slightly differently. (eg: circle's implementation of snprintf returns the wrong value when the output string is cropped to the target buffer, so my unit tests fail).

I know there's the STDLIB_SUPPORT define, but I don't think it quite covers what I need:

  • For <=1 it doesn't link in any other libraries, but provides implementations of functions circle needs.
  • For >=2 it links in other libraries and doesn't include its own implementation of functions.

What I'd like is a mode that doesn't link libraries nor include function implementations so I can "bring my own".

I'd be happy to implement this (it'd mostly be just #ifdef'ing stuff out) but wanted to check what you thought and if you had any ideas on how to declare to use this mode.

How would you feel about -DSTDLIB_SUPPORT=-1 to mean bring your own lib or would it be better as a separate define (eg: -DSTDLIB_NONE)?

commented

I had a closer look at this and it turned out to be pretty simple. Made a PR for it (#378), let me know what you think.

commented

Thanks, but I think, a new option value for STDLIB_SUPPORT is not necessary. That snprintf() is provided by Circle, when STDLIB_SUPPORT >= 2 is an issue in Circle, which can be corrected. I will do so. Please let me know, when you find more of these functions, which must be left out from compiling, when STDLIB_SUPPORT >= 2.

commented

First a correction: snprinf() is not included, if STDLIB_SUPPORT >= 2. There's no issue here in Circle.

Honestly I do not fully understand, what your goal is and why you can't use STDLIB_SUPPORT = 2. When I look at your PR, I can see only one difference between STDLIB_SUPPORT = 2 and your new option -1: libgcc.a is not included with it. Is this your goal? This library provides a number of compiler-specific stubs, which are necessary for successful build and operation.

STDLIB_SUPPORT >= 2 was introduced exactly for the purpose to provide your own standard library and this is working well with @smuehlst's circle-stdlib project. Generally I follow the rule to keep everything as simple as possible and I wouldn't be happy to introduce a new value for STDLIB_SUPPORT when I do not really understand, why it is necessary. The things are already complex enough here.

Perhaps I am missing something, and you can convince me by explaining in more detail, what you want? Which libraries, include files, and/or functions are disturbing your build/operation?

commented

You're right of course. I think what confused me was this line in the docs:

* STDLIB_SUPPORT=2 to build with C standard library (external newlib) too

which I assumed meant that it brought in dependencies on newlib which I don't want since I'm supplying my own lib.

commented

Fine. Perhaps this doc file needs some update later.