Local Building - does not compile with warnings?

I dont get the_sbrk error when I remove the const in the below function, but then I get a different error

const char* convMonth(byte value) { // converts 1-12 to the correstponding month
  switch (value) {
   
  case 1: return "January";
  case 2: return "February";
  case 3: return "March";
  case 4: return "April";
  case 5: return "May";
  case 6: return "June";
  case 7: return "July";
  case 8: return "August";
  case 9: return "September";
  case 10: return "October";
  case 11: return "November";
  case 12: return "December";
  }

}

Try this:


static const char _months[12][10] = {"January","February","March","April","May","June","July","August","September","October","November","December"};

const char* convMonth(byte value) {
  return _months(value-1);
}

@bko, also tried you other example. Is this what I’m looking for?

@bko, I completely removed that function and I get the same _sbrk error.

@lami, below is my app code:

***Remove code

Well, I should always remember to read the end of the thread:

The current Photon time functions have this bug. It was added the bug backlog with high priority, but I have not seen the fix go by yet.

1 Like

Wow, that is amazing piece of code! I was expecting something simpler, where would be easier to try disabling parts of code until a culpri can be foundt. But it seems @bko discovered something! I can’t really help much when some internal working is involved as I am - let’s say - too scared to dive into the firmware code. Sorry :smile:

@bko, @lami, thanks, I’ll try disabling the time functions next.

Folks, it turns out that _sbrk() is called by functions in the Time class which are calling malloc_r instead of malloc. When @mdma gets back, he should be able to fix this quickly. This only affects the develop branch.

1 Like

Thanks, I removed all time related code and now it is compiling. :smile:

1 Like

@peekay123, do you know when mdma will get back?

I am currently on hold for doing any local compiling as my code has to have time functions. Do you know what files I would have to edit in the develop branch to change mallocr to malloc? Just so I can start testing my code?

Thanks for any help,

Yup… next week :smile:

Thanks

@peekay123, Do you know what files I would have to edit in the develop branch to change mallocr to malloc? Just so I can start testing my code I cant really wait a week or 2.

@wesner0019, nope. I am waiting for Mat also :disappointed:

@peekay123, do you think this would work from BKO from MDMA?

"
Hi @wesner0019

here are @mdma’s instructions for tracking down your linker problem:

Here’s how to find out which function is causing the problem:

add a function extern “C” void* _sbrk() { return NULL; } to your
program. This is only temporary and will fill in the missing function so
the code links.open the user-part.lst file that is produced alongside your compiled application codesearch for sbrk to find which function is calling that. (It’s usually _mallocr)then search for mallocr and see which function is calling that. That will tell you which function is trying to allocate memory directly via mallocr rather than via malloc()
"

@wesner0019, the _sbrk source is well known to be in the Time class. The Time functions call malloc_r() instead of malloc(). If you don’t use any Time functions then you won’t get the error. In my case, I am using Time so I will want Mat to fix this correctly.

@peekay123, thanks, after a quick search I quickly realized I had no idea what I was even looking for. :expressionless: guess I’ll hurry up and wait.

1 Like

Just git pulled today on the latest branch and found that the sbrk bug now afflicting the latest branch today as well, but only for photon, not core. Strange.

@bpr, latest is actually 0.4.4rc2 which has inherited the _sbrk issue. If you clone photon_043 that will get you the 0.4.3 working version. :smile:

@peekay123, Ah that explains the photon/core disparity. Thanks!

1 Like